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 15:59, Ryan Johnson wrote:
> On 02/07/2011 1:21 PM, Earnie wrote:
> >Corinna Vinschen wrote:
> >>>[SNIP] 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)
> >When I was reading Yaakov's post I had the same idea.  It should ease
> >the pain for porting since there is no need for upstream packages to
> >have to make changes to accommodate the Cygwin specifics.
> In my ignorance I always figured that's what was happening all
> along. What happens instead?

See the dlopen and get_full_path_of_dll functions in dlfcn.cc.  It's not
complicated.

>  It seems the #ifdef idea also doesn't
> happen?

What #ifdef idea?

> BTW, we'd probably have to check the above list in reverse order, or
> risk opening the Windows-only libz.dll instead of cygz.dll.

That might make sense.


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]