Re: RFC: Cygwin 64 bit?

[Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>]

On 18/08/2011 8:57 AM, Corinna Vinschen wrote:
> On Aug 18 07:51, Ryan Johnson wrote:
> > On 18/08/2011 5:20 AM, Corinna Vinschen wrote:
> > > So, nobody except Earnie is interested in the way dlopen opens shared
> > > objects?  Nobody even replied to the idea of the pseudo algorithm below.
> > > Does really nobody care?
> > The below looks fine to me, but I really didn't feel qualified to
> > comment. I had been lurking on this thread because I really don't
> > know much about the ins and outs of the Windows loader...
> >
> > That said, it seemed from a different part of the thread that it
> > should be possible to wire in relative ../lib/ paths for dlls in
> > such a way that we'd no longer need to keep them in bin. It seems
> > like that would be a good avenue to pursue, because then the normal
> > ../lib and ../lib64 conventions would solve the problem of a mixed
> > 32/64-bit distribution pretty nicely. Maybe we could even
> Unfortunately, it doesn't seem to be really feasible to hardcode
> ../lib/my_beloved.dll in executables and other DLLs.  The problem is, at
> the time of building the DLL you don't really know if it will be
> installed in ../lib.  This is typically only known in the `make install'
> stage, which is a bit too late.  I don't see an easy way to automate
> this behaviour :(
What if you just allocated a 128-byte string (perhaps one containing a 
lot of leading or trailing whitespace) for each dll at link time, then 
clobbered it in place with the true dependency later? That wouldn't 
really waste much space and would give a lot of flexibility, since we 
wouldn't have to mess with the layout of sections or tables within sections.

Just brainstorming here... it's not necessarily a good idea.

Ryan