Web lists-archives.com

Re: [Mingw-users] Multiple definition of `vsnprintf' when building C++ programs




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/05/17 17:16, Eli Zaretskii wrote:
> As followup to the previous problem I reported when building GDB 8.0
> pretest, I upgraded to mingwrt-5.0, which fixed the issue with
> to_string, but introduced a new problem -- linking GDB failed thusly:
> 
>      d:/usr/lib/libmingwex.a(vsnprintf.o):(.text+0x0): multiple definition of `vsnprintf'
>      cli-script.o:d:/usr/include/stdio.h:427: first defined here
>      collect2.exe: error: ld returned 1 exit status

Ouch!

> This happens because the GDB build defines __USE_MINGW_ANSI_STDIO in
> its headers, and when a C++ program does that, including <stdio.h> and
> <string> in a source file will (a) define vsnprintf as an inline
> function, and (b) pull vsnprintf.o from libmingwex because it needs
> __mingw_vsnprintf.  But vsnprintf.c from libmingwex also defines (a
> non-inline version of) vsnprintf, and thus the above error.

Thanks for this analysis, Eli.

> (This doesn't happen in C programs because for C stdio.h defines
> vsnprintf as a static inline function.)
> 
> I attach below a small nonsense program, which I concocted from bits
> and pieces of GDB's cli-script.c; it can be used to reproduce this
> problem.  It builds OK with mingwrt-3.22.2, but not with mingwrt-5.0,
> using the same libstdc++ headers from the MinGW GCC 5.3.0
> distribution.

I guess that's a consequence of:
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/c0372a60e6918ffd944670ba8502a0d99fa69044/

which I committed, (against my better judgement), in response to:
https://sourceforge.net/p/mingw/mailman/mingw-users/thread/457e590fb9dd45de9302b300848a3a09%40UUSALE0M.utcmail.com/#msg35494845

> Any ideas for solutions are welcome.

See below.

> (I assume that undefining __USE_MINGW_ANSI_STDIO before including
> stdio.h is not a good idea, since it will cause a non-compliant
> vsnprintf from msvcrt to be used, which will subtly break the
> program.)

Possibly not.  Legacy MSVCRT.DLL exported Microsoft's (incompatible) 
_vsnprintf(), IIRC; it didn't export vsnprintf(), which should always 
be resolved to the entry in libmingwex.a, (or libmingwex.dll.a).

> Here's the test program:
> [... snip ts.c ...]

Thanks for this; I'll need to play with it, to come up with a robust 
solution, but, having saved it as ts.cpp (rather than as ts.c, since 
it is, strictly, a C++ program), my first compile-and-link experiment 
suggests an immediate work-around:

  $ mingw32-g++ -std=gnu++11 -O2 ts.cpp -o ts.exe
  <success -- no diagnostic output>

i.e. without doing anything, it appears that I am not reproducing the 
link failure you are reporting.  So, what is the difference between my 
link and yours?  Dynamic vs. static linking of libmingwex, perhaps?

  $ mv ~/mingw32/lib/libmingwex.dll.a{,.bak}

Et voilà:

  $ mingw32-g++ -std=gnu++11 -O2 ts.cpp -o ts.exe
  /home/keith/mingw32-gcc-5.3.0/lib/libmingwex.a(vsnprintf.o): In function `_mingw_vsnprintf':
  /home/keith/src/mingw/mingw-wsl-outgoing/build/mingwrt/../../mingwrt/mingwex/stdio/vsnprintf.c:35: multiple definition of `vsnprintf'
  /tmp/ccwoMr41.o:ts.cpp:(.text$vsnprintf[_vsnprintf]+0x0): first defined here
  collect2: error: ld returned 1 exit status

So, linking statically with libmingwex.a reproduces the issue; if you 
install the (optional) libmingwex-5.0-mingw32-dll-0.tar.xz package, 
and its accompanying dev package (for libmingwex.dll.a), your test 
program can, at least, be linked successfully.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZEjuwAAoJEMCtNsY0flo/fdQQAIm2N5y41BcLHZnCHb/OcAWJ
cGglbNxEbLwIoowbD4kCj3tNjK1AYD4XlYZpMwTxmWLaDzOgKpJ5M/xMuXQHw/JF
bPqm2Dc0o/LnYj51jdHo8bu1zDGRGNTJWuOzzk3l69C5zp13ducqZL58ywBgdHvf
ybF2IWNDWMtoSho/9WmOvhmkZCBJCtumDCSOCpYXuXv7mTXMnyrnf79W1NQuS5Uw
Thsa/Jy69l+Y8jcQ2MhHa0iwrlRw8ZtBpJhl2930XPQK456MVLwUUIl11OS+pLrY
0yutXUHx2S5WHtkiwl3hy0aVJLeqAyFR89l0tn/4SjvOTqgb1XuhZi5GBSM1/YcB
C3kD+Kp/pbtqlLR80WEv0jyP/eNlP2aHhXMhrG+zRvi4xtmxEZjrkINF2VSPHn3I
9eFyrrmGG6ZAty26spzcVCWsK5PcCeuJL4QRnhxMonHmh0SQzQV/j84fNveI/uTA
pJmDtBEntCeo1/Pbzchhjf0tIADiS7dSc3hTKSp/vzosy8twdSg7hlOU8JLND7za
+YaruH6S7YszPsFoDtAW9Q7nXXRlZ3NKi7AUAqFz6LwXZjmfW8HG5rXQac5DdEfs
JFMgbVrnVNbNXxzxmBjc+qOha2sYRrvTsuBiMYNmqAdGRjCOUnLVbgCnXqQoMq9E
3VwhMuAxp+bXU5N5opJO
=IJL4
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

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.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe