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 21:16, Christopher Faylor wrote:
>   What I wouldn't like to see is ld being changed to
> force every -lrary refererence to default to ../lib64/cygrary.dll .

Actually, I hadn't thought about this point yet.  I was just exploring
possibilities.

Without caring for implementation details (yet) the idea is that, if
it works, that ld or, perhaps better, gcc, or, let's say, libtool,
does the work in an intelligent manner.

On Jul  8 22:26, Christopher Faylor wrote:
> On Fri, Jul 08, 2011 at 10:30:41PM +0200, Corinna Vinschen wrote:
> >Of course, if a relative ..\lib64\cygfoo.dll path in executables works,
> >we can get DLLs in /usr/lib64 for free...
> 
> FYI, I binary edited ls.exe to use ..\lib\aa.dll instead of cygintl-8.dll.
> It still worked after copying cygintl-8.dll to /lib .  Amazing.

Indeed.  We might have here something.

> This was only on Windows 7 64-bit.  I don't know if it would work
> everywhere.

Chuck sent the link to the old article about how the loader works in
Windows 2000 which claims that the search algorithm is always the same,
whether called from LoadLibrary or CreateProcess.  I can test the
behaviour on all Windows versions since Windows 2000.  A quick test
shows that it works fine on XP 32 bit and W7 32 bit, too, for instance.

>  As I implied elsewhere, the only problem with this plan
> is that it locks you into always using /lib.  You wouldn't be able
> to use some other library path.

Well, if you *always* prepend ../lib or ../lib64, then you're right,
and that's definitely not what I was thinking of when I asked this
question.

If the distro executables always look for DLLs in ../lib or ../lib64,
then that's no problem for me.  After all, that's practically the same
on a Linux distro.
The potential downside is that third-party-providers have to maintain
the same directory layout, or rather, they can't just provide a 64 bit
Cygwin executable and stick the DLLs into the same directory.  Funnily,
I can sleep very well with this "problem".

As for building a package, that's something I haven't quite thought
about, yet.  In theory, if you use libtool, and the prefix is set
to /usr, then the DLLs built in your package should go to /usr/lib{64}
and the libfoo.la file created by libtool should like this:

  dlname='../lib64/cygfoo-42.dll'
  library_names='libfoo.dll.a'
  old_library='libfoo.a'

That adds a new problem to building with libtool.  After `make',
the executable stuff is usually in a subdirectory called .libs.
libtool would have to add another subdir called lib64, otherwise
the executable fails.  Is that fixable?

The next question is, how does ld know if it should maintain ../lib or
../lib64 in the executable or not?  strcmp?  I don't know.  Any idea
how this could be made conditional in a intelligent/useful way?


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]