Relocation patch for cygwin

Christopher Faylor
Sun Sep 25 14:28:00 GMT 2011

On Sat, Sep 24, 2011 at 05:10:00AM +0900, jojelino wrote:
>On 2011-01-29 AM 3:04, Charles Wilson wrote:
>> 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
>It fixed the relocation problem. but led performance issue :(
>$ time id > /dev/null
>real    0m0.141s
>user    0m0.000s
>sys     0m0.000s
>The attached is report gprof produced when invoked *id* . as you can 
>see, format_process_maps consumes 70% of the lifetime(0.5s with 
>profiling overhead). this is reproducible whenever we do 
>the problem is, the cost is too expensive. gnulib should care about 
>cygwin do sacrifice performance for compatibility.
>As a workaround, how about rebuild libintl without capacity of relocatable?
>because in cygwin libintl is expected to place in /bin so there's no use 
>of relocatable.

>Flat profile:

Please don't send this type of stuff here.  You've just spammed hundreds
of people with many kilobytes data that very few people care about.


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list