mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] Request for OSS support


From: LM
Subject: Re: [Mingw-cross-env-list] Request for OSS support
Date: Fri, 15 Feb 2013 14:43:24 -0500

Martin Lambers wrote:
>A while ago, I did not care much if MXE would link statically or
>dynamically as long as it was easy to use, but now I think linking
>statically is better on Windows, since that platform does not provide
>any of the advantages that dynamic libraries typically have. You save
>no disk space (everybody has to distribute their own DLLs anyway), and
>there are no automatic propagated security updates or bug fixes (for
>the same reason).

When I asked a while back on the MinGW list whether I would be better off using
shared libraries or static libraries for the Open Source applications I planned
to build, heard back from some of the MinGW and GTK library developers
that they
thought dlls were the better way to go.  No one recommended static
linking at the time
I asked.

You'd have to check the specific licensing involved, but there are
some libraries, you
can't legally statically link to certain types of applications without
violating the
licenses.  So, dynamic linking opens up some possibilities that static
linking can't
in those situations.

I do like the idea of static linking and think sta.li makes a good
argument for their use on
Linux ( http://sta.li/faq ).  However, some projects just aren't
designed for that, making it
difficult or possibly against copyright to build that way.

There are a few projects out there that try to offer package
management solutions for
Windows.  They do contend with issues like software updates and security fixes.

> That's because Windows uses PATH not only to find executables, but also to 
> find DLLs;
>there is no separate LD_LIBRARY_PATH. So if your binary directory is
>in PATH and contains DLLs, then these might override the DLLs that some
>other program expected to use, resulting in all sorts of problems.

I typically put my dlls and executables in the same directory and just
add that directory
to the path.  For portable applications, I can write a batch file that
figures out what
drive and directory the batch script was started from (even if it's a
flash drive) and I can
then add the same location to my path before starting the application.
 When the batch
file finishes, the path reverts to the way it was.  The path change
doesn't affect other
applications on the system.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]