This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: RFC: Cygwin 64 bit?
Corinna Vinschen wrote:
> On Jul 2 22:52, Charles Wilson wrote:
>> On 7/2/2011 2:53 AM, Corinna Vinschen wrote:
>>> On Jul 2 01:11, Charles Wilson wrote:
>>>> Hey, Yaakov -- what about this wild idea: What if,
>>>> cygwin64-1.dll's implementation of dlopen() -- and remember,
>>>> cygwin64-1.dll can only be linked/loaded by a 64bit process --
>>>> automatically translated all attempts to dlopen
>>>> .../path/to/cyg*.dll to FIRST attempt to open cyg64*dll, then
>>>> (if cyg*dll was actually 64bit, rather than the expected 32bit)
>>>> fall back to the specified name?
>>>
>>> I'm wondering why we didn't do this in the first place? In
>>> theory there's nothing which speaks against
>>> dlopen("/path/to/libfoo.so") to check for valid combinations:
>>>
>>> - /path/to/libfoo.so - /path/to/libfoo.dll - /path/to/cygfoo.dll
>>> (32 bit) or /path/to/cyg64foo.dll (64 bit)
>>>
>>> shouldn't that ease the pain?
>>
>> Well, I agree with a later post that IF the first two variants in
>> the list above are included, then we should try cyg[64]*.dll
>> *first*, not last.
>>
>> Also -- and this would need input from Yaakov, since he has the
>> most practical experience with this -- should "libfoo.dll" or even
>> "libfoo.so" be included in the list /at all/? At this point,
>> all(?)/most(?)/large-proportion(?) of projects have adapted, on
>> cygwin, to the 'cyg' prefix.
>
> Not sure about that. See /usr/lib/ruby/1.8/i386-cygwin. Right now
> there's no .so file in there which is called libXXX.so, but for the
> sake of argument let's say there will be a lib called "library.so" at
> one point. If dlopen does what you say, Cygwin would check for
>
> dlopen (name = "/path/to/library.so") { if (name starts with lib and
> the suffix is .so or .dll) name = "/path/to/cygrary.dll" [...] return
> ENOENT; }
>
> Or, what about perl vendor libraries which are named libfoo.dll, not
> because the lib is a prefix, but because libfoo is the name of the
> package.
>
> Bottom line is - You can't decide whether the filename in a call to
> dlopen starts with "lib" because it's the default lib prefix, or
> because it's part of the name. - You can't decide if .so is the real
> ending of the lib or just the default shared lib filename expected by
> an application. However, if the .so ending is given, the only
> filename accepted with the .so ending is the orginal filename. The
> lib->cyg stuff is not performed on it.
>
>> Anyway, that's why I suggested that we add, now, a "fix" to
>> cygwin64's dlopen to 'substitute' dlopen("cyg64*") for requests to
>> dlopen("cyg*")
>
> Good point.
>
> 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.
Earnie