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

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

Jump to the original submission

Sun 07 Oct 2018 11:15:34 AM UTC, comment #7: 


> libmingwex.a now provides opendir(), readdir(), closedir(), and friends, all as simple assembly language stubs, each comprising a jmp instruction with the corresponding "__mingw_" prefixed entry point name as destination, (in addition to each of the implementations, with associated prefixed entry point names). Thus, AC_CHECK_FUNCS should now detect the stub, and HAVE_CLOSEDIR should become defined again.


Yes, this improvement in libmingwex.a is surely the reason why the issue has not reappeared in the last 3 years.

> Right now, we probably need no further action


Yes, I agree.

Bruno Haible <haible>
Group administrator
Sun 07 Oct 2018 10:15:20 AM UTC, comment #6: 

Replying to Bruno Haible's comment #5

Thanks for the follow-up, Bruno.

I've neither the time, nor the inclination, to pursue this right now, but I'm wondering if the issue may not have resolved itself in the meantime — libmingwex.a now provides opendir(), readdir(), closedir(), and friends, all as simple assembly language stubs, each comprising a jmp instruction with the corresponding "__mingw_" prefixed entry point name as destination, (in addition to each of the implementations, with associated prefixed entry point names).  Thus, AC_CHECK_FUNCS should now detect the stub, and HAVE_CLOSEDIR should become defined again.

Sorry for the noise ... although discussion has been constructive.  Right now, we probably need no further action, (unless you want to pursue the potential gnulib weakness w.r.t. the likelihood that dirent.h, if it is present, probably doesn't provide a complete definition of the DIR type): I'll raise a new ticket, if the issue persists when I next get around to updating the MinGW.org build of gettext.

Keith Marshall <keithmarshall>
Sun 07 Oct 2018 09:16:20 AM UTC, comment #5: 

Hi Keith,

Sorry I had misunderstood your report, because of the unusual presentation (the first comment being an analysis with no explanation what the symptoms are). In this bug tracker, the attachments don't stand out, therefore I read the comments, and when the comments tell me that there is an attachment, I look at the attachment afterwards.

Reading the attachment first I see that HAVE_DIRENT_H was set to 1 but HAVE_CLOSEDIR was undefined. This is a situation for which the gnulib modules are not prepared.

> closedir() is provided as an inline wrapper, (which AC_CHECK_FUNCS is unable to detect)


This looks like the original cause of the problem. AC_CHECK_FUNCS is a handy macro, therefore Gnulib makes use of it wherever it can. Every time some platform defines a function as an inline function, it requires a specific test code, rather than merely an AC_CHECK_FUNCS invocation. I've gone through it for many <math.h> functions, which are provided as inline functions for speed on some platforms. For functions like opendir and closedir it comes unexpected.

Bruno Haible <haible>
Group administrator
Sat 06 Oct 2018 10:35:00 PM UTC, comment #4: 

Replying to Bruno Haible's comment #3.

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


> This points to a problem in that particular version of mingw.


I respectfully disagree.

>> error: dereferencing pointer to incomplete type


> If 'DIR' is not defined as a complete type, there must be something wrong in the mingw header files.


That's a naïvely invalid presumption.  Publicly, DIR is defined as an opaque type; that's as much as client code should ever require, (and indeed, POSIX.1 is explicit in stating that DIR may be declared, in <dirent.h>, as an incomplete type).

Privately, OTOH, the MinGW implementations of opendir(), readdir(), closedir(), and associated functions do see the full definition of the underlying aggregate data type, (as they obviously need to).

> With the build recipe documented in INSTALL.windows (earlier called README.windows), I haven't seen issues with opendir/closedir on mingw in 4 years.


Nor have I, in MinGW's own implementations of these functions — it's gnulib which seems to have the problem.

> => Not a bug in gettext nor gnulib.


Another (likely) incorrect presumption!  Gnulib's implementations of opendir(), readdir(), closedir(), etc. obviously do need to see a full definition of DIR, but you've no right to expect to find it in MinGW's public headers — there is no relevant standard that offers you that guarantee, (and POSIX.1 explicitly denies it to you) — so you need to furnish your own full definition, of DIR, to complement your gnulib implementations.

You may choose to sweep it under the carpet, but this does seem to be your bug; either gettext appears to be looking for gnulib's closedir() implementation, where it should probably just use MinGW's native version, or gnulib is using the incomplete declaration of DIR, from MinGW's dirent.h header, where it should be providing its own complete type definition.

Keith Marshall <keithmarshall>
Fri 05 Oct 2018 12:38:20 AM UTC, comment #3: 


>  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


This points to a problem in that particular version of mingw.

> error: dereferencing pointer to incomplete type


If 'DIR' is not defined as a complete type, there must be something wrong in the mingw header files.

With the build recipe documented in INSTALL.windows (earlier called README.windows), I haven't seen issues with opendir/closedir on mingw in 4 years.

=> Not a bug in gettext nor gnulib.

Bruno Haible <haible>
Group administrator
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>
Group 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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-10-05 haible StatusNone Not a Bug
        Assigned toNone haible
        Open/ClosedOpen Closed
    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.13-f8d8.
    Corresponding source code