2012/11/13 Earnie Boyd <ear...@users.sourceforge.net>
> On Tue, Nov 13, 2012 at 7:04 AM, Kai Tietz wrote:
> > 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.
>
> 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
>
Oh yes, let's impose a unnecessarily complicated, proprietary, non-portable
(across OS versions) scheme on the developers/users to account for a case
which virtually never happens (installing 32 and 64-bit executables
alongside each other)
Windows was never designed to be monolithic (wrt 32 and 64-bit)... Just
look at the system32 and sysWoW64 directory in C:\Windows. Install
differing architectures side by side, not mucked with manifests that
overcomplicate things.
To execute a binary in the scheme Kai suggests, either the relevant DLL
needs to be copied (which has to be done to install to an end-user's system
anyways) or you set the PATH on the development machine.
To be honest, this is the mess I completely avoid by having to seperate
build directories and toolchains for all my stuff, one per bitness. I know
this isn't very future-friendly, but hey, I don't want to muck with too
much muck ;-)
Ruben.
>
> --
> 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
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
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
