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 at 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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20200601/276f468a/attachment.sig>
Fork