Relocation patch for cygwin

[Charles Wilson]

On the cygwin list, Corinna Vinschen, one of the main cygwin developers
and project lead, noticed a problem with libiconv's behavior on cygwin
1.7.x (which I'll follow up on the appropriate list, in a few days).

However, while she was investigating it, she ran across some very
obsolete code in the relocation support employed by libintl.  In keeping
with cygwin's mantra of "more like unix, less like windows", she
suggested the following changes.  These basically make cygwin's
relocation support use the linux machanisms (/proc/self/maps,
/proc/self/exe) rather than relying on win32 mechanisms like
GetModuleFileName, DllMain(), and the like.

An added benefit of using the linux mechanisms on cygwin, is that the
paths are therefore already in cygwin/unix format, and there is no need
to convert them from/to win32 format.

Speaking of which, the old conversion code used functions which (a) are
now deprecated, and (b) do not support paths longer than 254 characters.

As modified by this patch, extremely long path names are now supported,
as well as those containing non-ascii characters.

The only remaining vestige of win32ness in the patched code is that, for
characters in the A-Za-z range, filename comparison is performed
case-insensitively.  (There might be an issue here if the filename(s)
contain UTF-8 encoded multibyte characters, leading to false
equivalence.  But the odds of that seem pretty low...and the effects if
it DID happen pretty minor, it appears to me.  The alternative is to use
some locale-sensitive case conversion function, and then compare the
results...but that belongs in a different patch IMO.)

Concerns about backwards compatibility: the mechanisms exploited by the
"linux" code have been supported by cygwin since March 1 2005, with
cygwin-1.5.13.  That's almost six years.  Plus, the cygwin project no
longer supports ANY cygwin older than 1.7.x -- and 1.7.1 dates back more
than a year.  So, while the "new" code won't work on EXTREMELY old
cygwin, I think it's quite reasonable to require >= 1.5.13.  The only
likely complaints might come from the MSYS project, since they are based
on cygwin-1.3.4, but...since they deliberately operate in a closed
garden [*] they -- by which I mean "me" [**] -- will just have to deal
with it.

[*] They choose NOT to even allow config.guess to recognize their
triple, and don't ship their '#ifdef __MSYS__' patches upstream for ANY
projects. They are an "unofficial" port in every sense of the word.

[**] I am the maintainer of libiconv and gettext on MSYS, so...I'll just
deal with any problems this change might create on that platform.  No
need to force code on the "real" cygwin to use outdated, and deprecated,
interfaces just to keep msys happy.



2011-01-27  Corinna Vinschen  <...>
            Charles Wilson  <...>

        On Cygwin, use unix mechanisms instead of win32
        * progreloc.c: Prefer linux code throughout, rather than
        win32 implementations.
        (find_executable): Eliminate Cygwin path conversion logic
        from WIN32 code, as Cygwin now uses linux implementation.
        * relocatable.c: Prefer linux code throughout, rather than
        win32 implementations.
        (DllMain): Eliminate Cygwin path conversion logic from WIN32
        code, as Cygwin now uses linux implementation and does not
        require a custom DllMain.
        (find_shared_library_fullname): Use linux implementation for
        Cygwin.
        (get_shared_library_fullname): Allow on-demand initialization
        for Cygwin, as DllMain is no longer used to pre-initialize.


--
Chuck

cygwin-reloc.patch
Description: Text Data