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  8 14:07, Yaakov (Cygwin/X) wrote:
> On Fri, 2011-07-08 at 11:56 +0200, Corinna Vinschen wrote:
> > Where did you get the mingw64 gpg-error stuff from?  It's not in the
> > Cygwin distro.
> 
> It's in Ports.

Uh, ok, thanks.

> > - if we stick to a single /bin directory, we have to use another prefix
> >   like "cyg64", or
> 
> Which means changing all build systems and library loaders.
> 
> I just realized another problem with this that even patching dlopen()
> won't solve: a module loading system may construct a file path, then
> check the module's existence before attempting to load it.
> 
> Unless we use "cyg64" only for non-module shared libraries, and leave
> "cyg" for modules (which would be under /usr/lib64 and loaded by fully
> qualified path anyway).  Then dlopen() could do the cyg -> cyg64 dance
> only if no absolute path is given.  I know, I was against this at first,
> but with a modified dlopen() it might work.

As far as I can see, most modules don't use a prefix at all.  Neither
python, nor perl, nor ruby modules have a "lib" or "cyg" prefix.
Ok, the openssl engines have a prefix, but it's "lib".

> > - we have to put the DLLs into a separate directory like /usr/lib64.
> >   Separate directory has the problem that it always has to be in $PATH,
> >   which is not such a good idea, IMHO.
> 
> I presume you mean because of all the other stuff (*.a, *.la) that
> resides there.  Is that really so bad though?  At least we have
> EXECIGNORE now.

No, that's not the reason.  THe reason is the old problem that the
start of a Cygwin application from a native Win32 process fails,
unless C:\cygwin\lib64 is in %Path%.  The first process of a Cygwin
process tree is obviously always called from a native process.
That means, you must either set $PATH in the Win32 environment, or
your shortcuts must have C:\cygwin\lib64 as start directory, or
you must start all Cygwin processes from a .BAT file which adds
C:\cygwin\lib64 to %Path% before starting bash, tcsh or whatever.

It also looks and feels wrong to have a lib path in $PATH.

Of course, if a relative ..\lib64\cygfoo.dll path in executables works,
we can get DLLs in /usr/lib64 for free...


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]