On Tue, Nov 13, 2012 at 7:04 AM, Kai Tietz wrote: > 2012/11/13 Václav Šmilauer <[email protected]>: >> >>> This is a small question with much more impact as you might expect. >>> Old style is to put Runtime-DLL files into bin/ directory. This had >>> some advantages as long as you just have one target to support, but in >>> general isn't the best solution IMHO. >>> More modern gcc installs its runtime-DLL files for >>> cross-compiler-scenario into <target>/lib (<target>/lib64/32) along >>> the the import-library. This has the advantage that even for multiple >>> targets each target has its private destination for runtime-DLLs. So >>> they don't collide. Of course by this solution you need to add this >>> directory to your PATH-environment. >> >>> I would prefer to install 32-bit and 64-bit DLL files into same >>> directories as their import-libraries are. This is by the way >>> additionally the same behavior as on *nix-setups. >> I just noticed that autoconf (glib, glut, gio, gettext) installs DLLs to >> bin/ by default, and so does CMAKE (vtk). >> >> If you were to support multiple targets (which is not my case), you will >> have clashes in bin/ anyways? Or is the idea to have only >> arch-independent scripts in bin/, the rest in <target>/bin, and add >> <target>/bin to $PATH depending on target? >> >> Cheers, Vaclav > > Right, the idea is to avoid those clashes. It can be achieved by > mimic *nix behavior for shared objects. Those are installed into > target-specific lib/ folder. Why we don't do that by default is > simply caused by that *old* behavior to install into bin/. I would > prefer to install DLL files - at least toolchain base ones - > intospecific lib/ folder as done already for cross-compilers for > mingw targets.
That doesn't address the side-by-side issue where we need a 32bit executable matching the 64bit executable. What do you propose for 32bit executable path versus the 64bit executable path? The reason to install the DLL into the bin/ directory is that the system will find it even if the directory isn't in PATH. Suppose I execute a binary via an absolute path, one expects it to work regardless of the PATH variable. There are methods (such as mucking with the KnownDLL registry entry, via a manifest, etc) that will allow you to move those DLL elsewhere but because we are on Windows, it is best to follow the default standard as recommended by the maker of the OS and it may be different for differing versions of the OS. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa376414(v=vs.85).aspx -- Earnie -- https://sites.google.com/site/earnieboyd ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
