Re: RFC: Cygwin 64 bit?

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

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.

Sure, it would have been nice if we'd made this cygwin behavior change
back in 2002 or so, BEFORE all of that effort, thus making the effort
unnecessary, but what is done is done.  Now, however, that these
adapatations DO exist in the upstream projects, and we have the nice
side benefit:

if I have cygwin-gtk AND mingw-gtk (think: official GIMP with its gtk
stack) installed, it doesn't matter what my path is, or anything.  The
GIMP stack dlopen's the libpixbufloader-gif.dll loader, while the
cygwin-gtk stack dlopen's cygpixbufloader-gif.dll. (dunno about the
internals; maybe the gtk stack uses explicit full paths, so there'd be
no conflict even if the names WERE the same). But the point is, I don't
need to know OR worry about that. It just works (thanks to Tor and Yaakov).

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*")
-- before falling back to the original request.  But nothing more
elaborate than that -- like Corinna's expanded proposal.

OTOH, if we DO go Corinna's way, then maybe those extant per-package
dlopen workarounds in all 2000 of Yaakov's projects can be removed.  Is
that a good thing, or is it just churn, and MORE work for Yaakov?  (In
this sceneario, his *build system* patches would still need to stay in
place, and maybe even been updated, because the modules/dlls would still
be named "cyg*" only now on 64bit they'd actually be named "cyg64*")

--
Chuck