2012/11/13 Václav Šmilauer <e...@doxos.eu>: > >> 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. Regards, Kai ------------------------------------------------------------------------------ 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
