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.
|
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).
|
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).
|