2012/11/13 Earnie Boyd <[email protected]>
> On Tue, Nov 13, 2012 at 8:23 AM, Ruben Van Boxem
> <[email protected]> wrote:
> > 2012/11/13 Earnie Boyd <[email protected]>
> >>
> >> On Tue, Nov 13, 2012 at 8:05 AM, Kai Tietz wrote:
> >> > As I said before ... "you need to add the target-lib/ folder to you
> >> > path".
> >> >
> >>
> >> That is unfriendly to the end-user. Note the discussion deals with
> >> more than just GCC it is a deployment of the client code using GCC
> >> that is in discussion. Businesses will not like your product very
> >> well if you have to go configure the client PC using it.
> >>
> >> > For the host-binaries in /bin it might be good to have "host" DLLs
> >> > used by it in the same directory. But this is just true for "host" ==
> >> > "target" and if you have just one "target".
> >>
> >> Again the segregation is needed for the executable if you supply both
> >> a 32bit and a 64bit version in the same deployment. So taking a clue
> >> from the Windows/ directory sysnative/ contains the binaries for the
> >> 64bit versions and syswow64 contains the 32bit versions that run under
> >> the emulator. So MyApp/bin contains the native 64bit version and
> >> MyApp/bin32 contains the 32bit versions and MyApp must provide a
> >> manifest so Windows OS knows which is which.
> >
> >
> > Why does this setup need a manifest at all? The way you describe it,
> Windows
> > will load the proper DLLs regardless...
>
> For the side-by-side assembly. Crossing boundaries of 32bit SysWOW64
> emulator into 64bit native space and vice versa will give you an
> error. The manifest will keep the two from butting heads.
>
Euh... You cannot load a 32-bit DLL in a 64-bit process, or vice versa. The
only side-by-side assembly I know of is the way winsxs handles all the
slight variations of msvcr*.dll versions, and that's not related to
architecture at all.
When the 32-bit executable is loaded, the OS looks in the exe's directory
for DLLs (along with everywhere else it normally looks), loads them (skips
the 64-bit ones), and moves on. Idem ditto for the 64-bit executable.
So even if PATH looked like this:
C:\bin64;C:\bin32
where a 64-bit libgcc_s_sjlj-1.dll is in bin64 and a 32-bit one (with the
same name) is in bin32, loading a 32-bit app depending on this DLL will
never cause a problem.
I must be misunderstanding what you're trying to say.
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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
