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


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]