Possible specs file error in MinGW GCC

Keith Marshall <[email protected]> Wed, 26 Feb 2020 19:56:28 +0000
Newsgroups	gmane.comp.gnu.mingw.user
Organization	MinGW.org Project
Message-ID	<[email protected]>
I encountered this anomalous behaviour, while preparing mingwrt-5.3, and
following up on https://osdn.net/projects/mingw/ticket/39687

The issue arises when I place any instance of thread local data storage
in an object module which is included in libmingwex.a; I can illustrate
it with a trivial example:

   $ cat foo.c
   static __thread int foo;
   void set_foo( int value ){ foo = value; }

   $ gcc foo.c
   $ mkdir -p ./foo.d
   $ cp $MINGW_ROOT/lib/libmingwex.a ./foo.d
   $ ar rcs ./foo.d/libmingwex.a foo.o

   $ cat fubar.c
   extern void set_foo( int );
   int main(){ set_foo( 123 ); return 0; }

   $ gcc fubar.c

This final compilation command produces an avalanche of "undefined
reference" errors.  All of the undefined symbol references *should* be
resolved from within the default system libraries, so this is indicative
of incorrect library order in the link command spec.  Running

   $ gcc -v fubar.c

shows that the default libraries are specified in the order:

   -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt
   -ladvapi32 -lshell32 -luser32 -lkernel32

followed by one more scan of:

   -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt

but not of:

   -ladvapi32 -lshell32 -luser32 -lkernel32

Explicitly specifying:

   $ gcc fubar.c -L ./foo.d -lmingwex

(which effectively forces an extra scan of -lmingwex, *before* any of
the default library scans), is sufficient to overcome the problem.  The
same effect may be achieved by modifying the GCC specs file, to move
-lmingwex before -lgcc; (it does not appear to be needed again, between
-lmoldname and -lmsvcrt); thus, the correct order would seem to be:

   -lmingw32 -lmingwex -lgcc -lgcc_eh -lmoldname -lmsvcrt
   -ladvapi32 -lshell32 -luser32 -lkernel32

followed by repeated:

   -lmingw32 -lmingwex -lgcc -lgcc_eh -lmoldname -lmsvcrt

I propose making this specs change, in the built-in specs for GCC-9.2,
and releasing this along with mingwrt-5.3.  Thus, mingwrt-5.3 will be
dependent on this (rebuilt) GCC-9.2, or users will need to either link
-lmingwex explicitly, or make the requisite specs file change, if they
wish to use mingwrt-5.3 with any earlier version of MinGW-GCC.

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

_______________________________________________
MinGW-Users mailing list
[email protected]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.osdn.me/mailman/listinfo/mingw-users
Also: mailto:[email protected]?subject=unsubscribe
signature.asc (application/pgp-signature, 833 B)