Re: Link problems

Keith Marshall <[email protected]> Mon, 1 Jun 2020 20:46:05 +0100
Newsgroups	gmane.comp.gnu.mingw.user
Organization	MinGW.org Project
Message-ID	<[email protected]>
For some reason, as yet undetermined, I am not receiving e-mails from
the list; I've abstracted this from the archive.  If replying, please
post to the list, but consider copying me in direct cc.

On 31/05/2020 17:52, Eli Zaretskii wrote:
>> From: Peter Williams <petes****@gmail*****>
>> Date: Sun, 31 May 2020 11:17:46 +0100
>>
>> gcc -c -I C:\plplot32\include\plplot x03.c
>> gcc -o x03.exe x03.o C:\plplot32\lib\libcsirocsa.a
>>   C:\plplot32\lib\libplplot.a C:\plplot32\lib\libqsastime.a
>>   -mconsole -mwindows -lm
> 
> Why are you using both -mconsole and -mwindows?  Don't they contradict
> each other?

Yes, they are mutually contradictory.  It makes no sense to combine
them, in a single compilation.

>> c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe:
>>   c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../libmingw32.a(mbrscan.o):(.text+0xb6):
>>   undefined reference to `SetLastError@4'
>> c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe:
>>   c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../libmingw32.a(wcharmap.o):(.text+0x208):
>>   undefined reference to `WideCharToMultiByte@32'
> 
> These look like either missing import libraries on the link command
> line, or maybe some snafu with including windows.h, which declares
> these functions.  The former problem could have been caused by the
> fact that you used both -mconsole and -mwindows.  I suggest to add -v
> to the GCC command line and see which libraries it scans.

No, it's a bug in mingwrt-5.3.2, due to a circular dependency between
-lmingw32 and -lmingwex, introduced in a flawed effort to correct a
defect in libmingwex-2.dll.  Right now, the possible workarounds are:

* Revert to mingwrt-5.3.1, and avoid libmingwex-2.dll like the plague.

* Stick with mingwrt-5.3.2, and explicitly specify -lmingw32 -lmingwex,
  in this order, on the command line, to force an extra scan of these
  two libraries, prior to their default scans; (I have not actually
  tested this, but it duplicates the effect of the following option,
  which I have tested).

* Run

    gcc -dumpspecs > c:\mingw\lib\gcc\mingw32\9.2.0\specs

  then edit the resulting specs file.  Locate the -lmingw32 -lmingwex
  reference, within the libgcc spec string, and extend it to read

    -lmingw32 -lmingwex -lmingw32 -lmingwex

  or alternatively

    -( -lmingw32 -lmingwex -)

Any of these should resolve the issue, until I can correct the
underlying defect; it will ultimately require one of:

* An unavoidable dynamic run-time dependency of libmingwex-N.dll on
  libgcc_s_dw2-1.dll, with the GPL licensing implications which that
  would incur.

* Leaving the circular dependency of -lmingwex on -lmingw32, as it
  now is in mingwrt-5.3.2, and rebuild GCC with modified specs.

* Add a third MinGW library, say -lmingwcx, to be statically linked
  _after_ -lmingwex, to break the dependency cycle, and replace it
  with a linear dependency chain.  This is, perhaps, the cleanest
  option, but it too will require a GCC rebuild with modified specs.

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