Add cygwin_internal CW_GET_MODULE_PATH_FOR_ADDR

[Charles Wilson]

On 10/14/2011 5:18 AM, Corinna Vinschen wrote:
> On Oct 14 02:09, Charles Wilson wrote:
>> [[ SIDE NOTE: even though our official libintl is built without
>> --enable-relocate, its Makefile is *hardcoded* to define
>> ENABLE_RELOCATABLE.  Therefore the libintl_relocate() function IS
>> present, and IS called -- but because the compile-time prefix (/usr) was
>> the same as the installed prefix, it very expensively did a no-op.  With
>> Bruno's recent change, it will do a cheap -- but not entirely free --
>> no-op. ]]
>> [...]
>
> First of all, the blatant bug which sets the locale depending on the
> Windows settings is much more important and *pressing* IMHO.  This is
> what's really necessary, the relocation stuff not so much.

I said the new version will be out this weekend; it's coming.

> I had a look into gettext-runtime/intl/setlocale.c and it drives me
> nuts.  I told Bruno back in January already not to use Windowisms on
> Cygwin.

Well, (a) it will take time to back out the existing windowsism (most of 
what you see dates from pre-cygwin-1.7), and (b) the cygwin 
implementation is not nearly as ugly as you might think, if you look at 
what is inactivated on __CYGWIN__.  I've attached the pre-processed 
version below (with all the header stuff deleted).  It does /some/ extra 
stuff, but not all that ickiness that native win32 requires.

> Cygwin's setlocale and nl_langinfo functions do everything
> libintl needs.  And it's especially annoying to use an encoding which
> doesn't match the rest of the system, because libintl fetches
> "ISO-8859-1" from Windows (strange enough), rather than using UTF-8 as
> requested by $LANG.
>
> Therefore, can we get an intermediate libintl8 which fixes this bug

Yes.

> and
> just disables ENABLE_RELOCATABLE in the Makefile, until the relocation
> problem is settled?

No.  Now that cygintl-8.dll has been published with an added interface 
(libintl_setlocale) I can't remove that new symbol without breaking any 
apps compiled in the meantime.

But cygintl-8.dll has LONG had the libintl_relocate() export -- it would 
be far worse to remove /that/ symbol now, after years of its presence. 
Changing the Makefile that way would remove the symbol, and break a lot 
of existing apps.  To "fix" the problem for 'standard' packages (where 
compile prefix = runtime prefix) and libintl_relocate is WAY slow, we 
just need to make it do a lot less [e.g. almost nothing] -- but we can't 
remove it via -UENABLE_RELOCATE.

And THAT's why I'm also simultaneously investigating the solution to the 
reloc problem.

However, I had already come to the conclusion that simply applying 
Bruno's "cheap vs. expensive" fix from CVS will do, for now.  This 
doesn't require any new cygwin APIs.  The new API is only an attempt to 
speed up "expensive" relocation (which cygwin's official packages will 
never need to do) while staying at least somewhat unixy/cygwiny, rather 
than calling the w32api.

>> But the key bit is that the libfoo_relocate() function needs to be able
>> to determine the current runtime path of
>> the-module-which-contains-'libfoo_relocate()' (well, technically, the
>> module which contains a specific static (private) copy of
>> find_shared_library_fullname).
>
> Well, if that's really necessary, then, for heaven's sake, let them use
> the code in gettext-runtime/gnulib-lib/relocatable.c, but with a good
> tweak:
>
> - Call GetModuleFileNameW instead of GetModuleFileName.

After we told Bruno to not use any windowsisms?  Sure, it's a lot 
simpler -- but it violates our recommendations for cygwin clients. 
(Worse, Bruno's idea is the gnulib relocate stuff, incl. relocatable.c, 
eventually expands beyond just libiconv and gettext.  If that ever does 
happen, it means *more* projects using windowisms in their cygwin port 
via relocatable.c).

But making "expensive" relocation less expensive doesn't have to be 
solved this very minute.

> - Call cygwin_create_path instead of cygwin_conv_to_posix_path.
>
> The reason is not so much the longer filenames, rather than the conversion
> of the path into the correct current encoding.  Here's an untested patch
> relative to the original sources from gettext-0.18.1.1.tar.gz:

Well, yeah, but that code -- DllMain -- isn't currently active in 
cygwin's gettext-0.18.1.1.  The relocate code in *our* distribution of 
gettext, all of it, was updated to contemporaneous gnulib (patch 
attached, not that it matters [**]) as part of the "don't do windowsism" 
effort.  You don't get much more windowsisms than implementing your own 
DllMain()!

[**] this patch is basically *your* patch from January, as committed to 
upstream gnulib.

--
Chuck
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setlocale.ii
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20111015/f439e854/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gettext-0.18.1.1.reloc.patch
Type: application/x-patch
Size: 36952 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20111015/f439e854/attachment.bin>