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?


Corinna Vinschen wrote:
> On Jul  6 15:00, Earnie wrote:
>> Corinna Vinschen wrote:
>>> IMHO the order should be something like this:
>>>
>>> Is suffix ".so"? Yes -> Does the file exist? Yes -> Done No  ->
>>> Replace ".so" with ".dll" #ifdef __X86_64__ Does the filename
>>> start with "cyg"? Yes -> Replace "cyg" with "cyg64" Does the file
>>> exist? No -> Revert back to "cyg" #endif Does the filename start
>>> with "lib"? Yes -> Replace "lib" with "cyg"/"cyg64" Does the file
>>> exist? No -> Revert back to "lib" Does the file exist? Yes ->
>>> Done return ENOENT
>>
>> It may be easier just to put the 64 bit dll in /lib64 and add
>> /lib64 to the PATH variable before the CreateProcess occurs.  Or
>> perhaps do both.
>
> This is *not* about fork or exec, it's about dlopen.  And the reason
> to do something like this is to be able to change the "cyg" prefix
> but maintain some kind of backward compatibility when loading DLLs
> dynamically.
>

I understand that.  I shouldn't have said "easier" perhaps.

> 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.  The dlopen implementation then
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.  The
unfortunate part is that today, the DLL lives with the binary in /bin. 
Since we cannot control by any known means the fact that Windows OS will
look in the directory from which the process binary starts for the DLL
first renaming the library from cyg to cyg64 seems like it should be the
case but only really needs to happen for those libraries not loaded with
dlopen.

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
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?  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.

Earnie


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