bugGNU gettext - Bugs: bug #42204, gettext-0.18.3.2: weird build...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #42204: gettext-0.18.3.2: weird build anomaly with MinGW

Submitted by:  Keith Marshall <keithmarshall>
Submitted on:  Sat 26 Apr 2014 08:42:51 PM UTC  
 
Category:  Build Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

Thu 01 May 2014 01:14:27 PM UTC, comment #2:

Right now, it seems to be in my local sandbox, awaiting pushing to the 4.1 development branch, as discussed on

https://sourceforge.net/p/mingw/bugs/2098/
https://sourceforge.net/p/mingw/bugs/2106/

I've been holding off on pushing the patches attached to those tickets, while Earnie remains too heavily tied up with his day job; there are a number of other issues which may impact the integration of these changes ... notably build system regressions which need to be resolved, to facilitate implementation of the entry point stubs I've alluded to, on ticket #2098. Since Earnie has assumed the role of lead developer for WSL, I'm reluctant to press ahead with these, without his input.

Ultimately, libmingwex.a will continue to provide opendir(), readdir(), closedir(), and friends, but as stubs redirecting to the "__mingw_" prefixed implementations, while the start-up code will call those prefixed implementations directly, so giving Eli his "fire escape" from namespace pollution. I've brought this to your attention, not so much because of the absence of the standard entry point names in my current MinGW sandbox, but because, in their absence, the GnuLib alternatives provided with gettext don't seem to want to compile.

Keith Marshall <keithmarshall>
Thu 01 May 2014 07:19:25 AM UTC, comment #1:

Could you point me to the places where "__mingw_" is prefixed to those symbols and the inline wrappers are defined?

I looked at the mingw-org-wsl module at:
http://sourceforge.net/p/mingw/_list/git
All I found is that there is __mingw_alias macro and some other functions (printf, fprintf, ...) are renamed using it.

Also, config.log might be helpful (unfortunately only mingw-w64 toolchain is packaged on my Fedora desktop).

Daiki Ueno <ueno>
Project Administrator
Sat 26 Apr 2014 08:42:51 PM UTC, original submission:

Hmm. Superficially, it seems weird. With my mingw32-gcc-4.8.1 cross-compiler, it compiles okay, but with mingw32-gcc-4.8.2, it fails trying to compile gnulib's closedir.o; (see attachment).

While there certainly is a difference between the two MinGW tool chains[*], you may wish to follow up on this, for the newer MinGW tools seem to be exposing a bug in the gnulib dirent component which you ship with gettext-0.18.3.2, (and indeed, the same issue is apparent in gettext-0.18.3.1).

[*] The difference lies in the releases of MinGW runtime libraries I have installed with the two versions of the cross-compiler. With mingw32-gcc-4.8.1, I have an earlier build of libmingwex.a which exposes its own closedir() function; in the newer build, installed with mingw32-gcc-4.8.2, that has been renamed to __mingw_closedir(), (to avoid namespace pollution in the runtime initialization module), and closedir() is provided as an inline wrapper, (which AC_CHECK_FUNCS is unable to detect). Thus, when compiling with mingw32-gcc-4.8.1, MinGW's closedir() is detected, and used, whereas with mingw32-gcc-4.8.2 it is not detected, so gettext elects to use the gnulib alternative, which then fails to build.

I guess opendir(), and readdir(), will be similarly compromised; the newer libmingwex.a also renames these to __mingw_opendir() and __mingw_readdir() respectively, (as it also does for the related rewinddir(), telldir(), and seekdir() functions, each of which have become __mingw_rewinddir(), __mingw_telldir(), and __mingw_seekdir() respectively).

Keith Marshall <keithmarshall>

 

Attached Files
file #31257:  gettext-build-bug.txt added by keithmarshall (2KiB - text/plain - make's error report for failing mingw32-gcc-4.8.2 build)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by haible (Updated the item)
  • -email is unavailable- added by ueno (Posted a comment)
  • -email is unavailable- added by keithmarshall (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-27 haible CategoryNone => Build
    2014-04-26 keithmarshall Attached File- => Added gettext-build-bug.txt, #31257

    Back to the top


    Powered by Savane 3.3