This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Cygwin 64 bit?


On Jul  7 09:22, Earnie wrote:
> Corinna Vinschen wrote:
> > Also, moving 64 bit DLLs to /lib64 and add /lib64 to $PATH doesn't
> > really help, if the 64 bit DLLs have the same name as their 32 bit
> > counterparts.  Either the 64 bit DLLs or the 32 bit DLLs are prior
> > in the Windows DLL search path.  Either 32 bit applications will
> > break, or 64 bit applications, dependent on the order.
> 
> True but if the full path to the DLL is supplied in LoadLibrary then
> only that directory will be searched. 

That's what we do in dlopen anyway.

> can control its own search path even using LD_LIBRARY_PATH.  Prefixing
> the /lib64 directory to PATH before the CreateProcess ensures that the
> DLL can be found by the Windows OS for the starting application.

No, that does not help.  See the DLL search order in
http://msdn.microsoft.com/en-us/library/ms682586%28v=VS.85%29.aspx

The path from which the application started is always first.  The
current working directory is always prior to the paths from $PATH.
Whatever you do, if you're in the wrong dir it goes boom.

> Also, the DLL (in today's Windows world) loaded by LoadLibrary doesn't
> require a .dll extension and could be named .so just as easily.  How

And we already have .so libs in Cygwin, see the ruby package.

> could we stop LOAD TIME dll linking and start using RUN TIME dll
> linking?  Could Cygwin GCC be made to instead of creating a link
> reference library a bridge to RUN TIME dll linking and actually calling
> LoadLibrary and GetProcAddress?

This has already been discussed.  It is possible, but requires gcc
and binutils support.

> I'm dreaming here trying to get past
> this issue for cyg128.  If every use of a library were RUN TIME instead
> of LOAD TIME then you can segregate easier the library bitness into
> differing directories such as lib64.

I still don't see the problem t use a cyg64 prefix.  It fixes almost
all problems, and the potential problems with dynamic loading can be
handled within dlopen.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]