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


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