Discussion:
[Mingw-users] Multiple definition of `vsnprintf' when building C++ programs
Eli Zaretskii
2017-05-09 16:16:24 UTC
Permalink
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

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.

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

Any ideas for solutions are welcome. (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.)

Here's the test program:

// ts.c
//
// Compile with 'g++ -std=gnu++11 -O2 -c ts.c -o ts.o',
// then examine the result with 'nm -A'.
// Or try building with 'g++ -std=gnu++11 -O2 ts.c -o ts.exe',
// and see it fail.
#define __USE_MINGW_ANSI_STDIO 1
#include <stdio.h>

// The following 3 macros are for mingwrt-3.22, not needed for 5.0
#ifndef _GLIBCXX_USE_C99
#define _GLIBCXX_USE_C99 1
#endif
#ifndef _ISOC99_SOURCE
#define _ISOC99_SOURCE
#endif
#ifndef _GLIBCXX_HAVE_WCSTOF
#define _GLIBCXX_HAVE_WCSTOF 1
#endif

#include <string>
#include <vector>

struct string_view
{
string_view (const char *str_, size_t len_)
: str (str_), len (len_)
{}

const char *str;
size_t len;
};

class user_args
{
public:
/* Save the command line and store the locations of arguments passed
to the user defined function. */
explicit user_args (const char *line);

/* Insert the stored user defined arguments into the $arg arguments
found in LINE. */
std::string insert_args (const char *line) const;

/* The arguments. Each element points inside M_COMMAND_LINE. */
std::vector<string_view> m_args;
};

static std::vector<user_args> user_args_stack;

std::string
user_args::insert_args (const char *line) const
{
std::string new_line;
new_line += std::to_string (m_args.size ());
return new_line;
}

int
main (int argc, char *argv[])
{
char line[80];
const user_args &args = user_args_stack.back ();
args.insert_args (line);
return 0;
}

------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe
Keith Marshall
2017-05-09 21:59:12 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Eli Zaretskii
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
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!
Post by Eli Zaretskii
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.
Post by Eli Zaretskii
(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
Post by Eli Zaretskii
Any ideas for solutions are welcome.
See below.
Post by Eli Zaretskii
(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).
Post by Eli Zaretskii
[... 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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscrib
Eli Zaretskii
2017-05-10 17:15:44 UTC
Permalink
Date: Tue, 9 May 2017 22:59:12 +0100
Post by Eli Zaretskii
(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).
Thanks, this means I at least have a workaround for mingwrt-5.0.
$ 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?
Yes, I link libmingwex statically.

It is of course expected that linking against a DLL will not hit this
problem. I'd like to avoid a dynamic link against libmingwex, because
otherwise distributing a GDB binary would need to distribute the
libmingwex DLL, which increases the probability of a DLL hell on the
end-user's machines, and also will require me to provide the sources
for libmingwex near the binaries.

So I hope you will find a solution that works for static linking as
well.

Thanks.

------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe
Keith Marshall
2017-05-10 20:14:02 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Eli Zaretskii
... what is the difference between my link and yours? Dynamic vs.
static linking of libmingwex, perhaps?
Yes, I link libmingwex statically.
As it is your right to choose; I respect that.
Post by Eli Zaretskii
It is of course expected that linking against a DLL will not hit this
problem. I'd like to avoid a dynamic link against libmingwex, because
otherwise distributing a GDB binary would need to distribute the
libmingwex DLL, which increases the probability of a DLL hell on the
end-user's machines,
libmingwex.dll will be versioned, following libtool guidelines, so
this _shouldn't_ become an issue.
Post by Eli Zaretskii
and also will require me to provide the sources for libmingwex near
the binaries.
The MIT/X.org licence of libmingwex.dll _doesn't_ impose any such
requirement, so unless you consider that GDB's GPL stomps on that
freedom, then no, with the IANAL proviso, I don't think it would.
Post by Eli Zaretskii
So I hope you will find a solution that works for static linking as
well.
Declaring snprintf and vsnprintf as weak symbols, for the libmingwex
build, does the trick, but it isn't my preferred solution. In fact,
the more I look into it, the less I like the change which introduced
the problem; I'm inclined to revert:
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/c0372a60e6918ffd944670ba8502a0d99fa69044/

Apart from _completely defeating_ -Wformat checking for snprintf(),
and vsnprintf(), (which will _always_ get it wrong WRT one or other
of the two subsets of format specifiers which are _not_ within the
intersection of the ms_printf and gnu_printf sets), it offers no
real value; in fact, it seems more harmful than useful.

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

iQIcBAEBAgAGBQJZE3SKAAoJEMCtNsY0flo/y/AQAKB8K8qujxgVnOZHXpVhhszK
g6yJKhqzkyV2z+YYn4aWlMK7fchwbaJmFFhXlfmfkGsNpfTGFNXQ2yIXXA2YddD3
DNr7hayNXhUDXtvUc3WDV/m74T5aU4q4rfQmB5OLeWPOw8nU5SJ09kZuvgqc+PIs
oePpbWr8a+2P+vOEpWyTTsbCYMgRjacrHn5j8fNjr7WPAAjnjl26H+pMUtLusoA5
UGZyHEBaX6ojSXhf7BgSwu1VDkJgTVCrk+0gQVO997yEoxWmKvhdDMz1KFxdD4aH
XrhU9wuGHwhJyXzQHv1NAanuHYgj+t5/+VK1AmBPyg9HJfs6N0+omn5eXNhqKZsy
NLsl8Uvs7gMDF1P5Xwt8kh6e42tZQUnuHjxJbyRWgVb+zEfRxnBJRu4QjKWqBwRw
eK6wc9uMg2VuIIMWzII9v8cDNE3rC28iyFFeyo/iKtFp/SraAptq0dzri+sMhnNn
Oz9JbXF18JEInFMCxGM5w3MtDr7TKulhwf6IVoNlJE+btyEhI2vhMxH5/fk21MHl
xZ7QnDQrGaGjPs6t7TcFQ96H2c0DVyJeWWnCqab0EFP7CdU89lMkTC2NHz/u0eqE
co//9icaQp8jF0RHLoxhZyS/2CZ3UgE1EAV6+Z7ZkcGSlKKFUxNY/kwnxgSVcMVl
5clztlbBBexiVqK0Pa7T
=5/yz
-----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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe
Keith Marshall
2017-05-10 22:50:52 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Keith Marshall
Post by Eli Zaretskii
So I hope you will find a solution that works for static linking
as well.
Declaring snprintf and vsnprintf as weak symbols, for the libmingwex
build, does the trick, ...
As does simply adding the "static" keyword, for the stdio.h C++ inline
redirects; I can no longer remember why Danny Smith persuaded me to omit
it.

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

iQIcBAEBAgAGBQJZE5lMAAoJEMCtNsY0flo/UYUQAKzRI9bFddK4kNmukRQSf0s1
77iOb6+d6xLYIElguq46ac/P9bSF4st4Qz+uoUSxH+YGw1XSiDPRVArgCbPN93W9
FRnLfOKYwX0+sNl8dUdoKJ3HPfPp4f/rHDXfXQ7ZAJvKGXsgUrxlnjCvyRMhtBco
lZRR1P1Q42LtXeZSu2QPh+E+Zwu1T842p41Sv3yNVnLPNDPfJDz29lRdDGXV600+
0Uv6Un5tCjI3qT6nFLhodCzrOz6Im3kQ7Grl4oJlbx2xZu5rzb/xBZsAu2YKxfQk
2fs5MbU2drADRgrwHThX4smpPMwZXLH7CPK4JpZvs9Fsj9HyCpb5pXNphnPsNLlE
a5NX3gSRsqWqJi974F+OYu6ol2vE+F6xpXw3djX4VeVJ72qzXiqPrpDedgVEO1xW
Sj+pAi+kvG111LVTf5tPmTfLd0oqm45ctPeJRc9HTdOmc7qACB2X5oO2dsIZQBER
xMsfsEJ67W5Jskaoal+ytxmrnp9jp6a1hy4YvFDaPOmatAzVQSWrxqnbC14g7Vic
+UeNcNzgNQDik8WV//FAskZZQsOUSnFw5Owhyf3Mje+am8s1n91x6gNBrtqyhhIy
qkfXiARTqyjXQ6M5KSyfNXSnvAUYfGKpaLHjtS2ek6oQBR/kNF1Ae4PBJFMSVal1
TMxFni9JMSmCArQtc9uw
=1U5L
-----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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe
Eli Zaretskii
2017-05-11 02:35:11 UTC
Permalink
Date: Wed, 10 May 2017 23:50:52 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Keith Marshall
Post by Eli Zaretskii
So I hope you will find a solution that works for static linking
as well.
Declaring snprintf and vsnprintf as weak symbols, for the libmingwex
build, does the trick, ...
As does simply adding the "static" keyword, for the stdio.h C++ inline
redirects; I can no longer remember why Danny Smith persuaded me to omit
it.
I'm not an expert on C++, but I thought it doesn't like 'static
inline' functions. But maybe inside extern "C" that is not an issue?

------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe
Keith Marshall
2017-05-11 09:03:53 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Eli Zaretskii
From: Keith Marshall
Date: Wed, 10 May 2017 23:50:52 +0100
Post by Keith Marshall
Post by Eli Zaretskii
So I hope you will find a solution that works for static linking
as well.
Declaring snprintf and vsnprintf as weak symbols, for the libmingwex
build, does the trick, ...
As does simply adding the "static" keyword, for the stdio.h C++ inline
redirects; I can no longer remember why Danny Smith persuaded me to omit
it.
I'm not an expert on C++, but I thought it doesn't like 'static
inline' functions. But maybe inside extern "C" that is not an issue?
I don't know. I am neither expert in, nor a fan of, C++ either.

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

iQIcBAEBAgAGBQJZFCj5AAoJEMCtNsY0flo/MBkP/1aEY/Ir4er+cP2hgYhpJYbG
KX/QK1chTROEfSRsCw8b++jeLGbkifeCsv4GY27Ktm96G6oEzlAIfyjG+RDqpeOk
GWXAY4LWLaRK+ficEclWvaLsDB/9/VJ78Gqmj5BpxQJFWuE18BISStafqvx/hUEi
QTen2p/x574KELUSbDYQvJ9KMlldy62RcztgBW5U78oSbOS8v9dU75U7FRVHtnpl
8zbZfA4PGbjJYnn1iZ3Ccp1eSPlXxB3VjDWzSky9BmMddPWyu7HtMeJAUNrrQsP7
lRyQH+6BG0AMJDobeBnyuSzGlaoYWDhL+ikg2JjPCMOQgg9302Alfw5aMwesp4jL
vV/jCe8hrarxDia1XSzsF/+WakAc0WhejYmmbcRvSYdJet5Br+7pu8Q3V4B5lcje
TR5Wo+QGDFhOiIGfS1tMibwyx+XS0SGv1/LFpk3xmaSAvX4oA2RxhdFXfkoWy2VL
2ivtLHUZGpgm8LMPQceJqbA3Q9psFXQU42PR09uNTaKYn2ytQHOlNvd9gGXqJlTc
GipfIZgLpZ9rYH/41EsgktE3IRpm36/9X6eHn/ODt5EGGiXXkSi+3dlvZf0msbTI
hVU9g+R/cvZxC2qU25uxNHSp5Z0gONQ4L0+2hVu3uv6QqLQsNlQ/NJjgW7aqJCot
cDl6cY+lCVCaSq73mtCN
=99GG
-----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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe
Keith Marshall
2017-05-22 18:30:19 UTC
Permalink
Post by Eli Zaretskii
From: Keith Marshall
Date: Tue, 9 May 2017 22:59:12 +0100
$ 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?
Yes, I link libmingwex statically.
...
So I hope you will find a solution that works for static linking as
well.
Please try the attached (modified) stdio.h; it reverts the
unsatisfactory function inlining, (so reverting to mingwrt-3.22
behaviour), but also lays the groundwork for more appropriate -Wformat handling, (esp. with a local patch in upcoming GCC-6.3.0).

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
Eli Zaretskii
2017-05-24 18:15:36 UTC
Permalink
Date: Mon, 22 May 2017 19:30:19 +0100
Post by Eli Zaretskii
Yes, I link libmingwex statically.
...
So I hope you will find a solution that works for static linking as
well.
Please try the attached (modified) stdio.h; it reverts the
unsatisfactory function inlining, (so reverting to mingwrt-3.22
behaviour), but also lays the groundwork for more appropriate -Wformat handling, (esp. with a local patch in upcoming GCC-6.3.0).
Tried it. It solves the problem; hope to see it soon in some mingwrt
release near me.

Thanks!

------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe
Keith Marshall
2017-05-24 22:27:47 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
From: Keith Marshall, Mon, 22 May 2017 19:30:19 +0100
Post by Keith Marshall
Please try the attached (modified) stdio.h; it reverts the
unsatisfactory function inlining, (so reverting to mingwrt-3.22
behaviour), but also lays the groundwork for more appropriate
-Wformat handling, (esp. with a local patch in upcoming GCC-6.3.0).
Tried it. It solves the problem;
Thanks for this confirmation.
hope to see it soon in some mingwrt release near me.
I pushed it to:
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/40982dff81a3c1dc0572cf2cd0a23156661ae98d/

so it will be in the next published release.
Thanks!
You're welcome.

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

iQIcBAEBAgAGBQJZJgjiAAoJEMCtNsY0flo/XFkQALkhkBgRHHNhTqo4jqqZBOIj
sIqyf3AGfNNuFRm1+k62p8Lo9l7PI33sCqeQNB5qQxiQ69l/hRzMefSTpr+okCUi
6AOQEhVmv0mEa5v2IbfBl4MNWgq04AAQvjL7ACbgFrxKbY38UQnN3StqLz04tF8Y
X5YQdWGkQo/xuZTdppQ96HYpxK/urWUog/hEc4yvbtJy2MF6xjYEdfaDzOmflvJV
SYWScxUgBQcb5+zV6tZp/Lia0PUOnuqtWPjplEKve3eY16vCUJtW2DtNYS54OgEw
3ykxUoZ/waWNXZfT5o2Reuil7twMnlzW2w/o4jca51/0pBalCHm1HlQiHgJyu6cH
M02AE+K6aHfJ4GYEymRqi8d0u3HknYJwxMj3qvYPyIzJ8f8VV+6XfK5tYW4gcMHx
qcMxX4lLHk7fvUjwWUEvUm8Iq4TKEU9S71CxKnpimcPAoAD7HpvnmL4P6LuPG/sd
erMKGd4ul/9BQ3jSbRsfQ7vCuDah3lGTE2Kn3JBvNluVFb/ezQT7lttBYhKZbfwH
yBvrwt1bKZzCS3ornLhLoM66ddU/q7/hYSxMlH6Wto+tnIAmiGJdF3vq/bOJvmWT
C2VS4eS/lXWSaoUHEOw+zxf6hCyv0fSggtpnyhET+39PbaBUepj0VswOxiFeiOOn
oOUqFxVxaDOj5ORw7hYx
=St0e
-----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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe
Loading...