multiple versions of 'vsnprintf'

[AMScaglione]

When adding this into code::blocks, I am getting this error when I attempt to compile. I am honestly not sure where to begin with this one, as it has never happened before I included this

here's a screenshot of what is happening

[gregmarr]

I would try including only "stdio.h" or "cstdio", not both. The two headers declare the same functions, the former in the global namespace, and the latter in the std namespace. They may be interfering.

[AMScaglione]

That is not the issue. Upon narrowing it down, I have determined that it is an issue with including json.hpp and fstream. When one of them is gone, the error goes away. However without fstream I have no way (that I know of, I'm still a bit of a rookie) of reading in json files

[gregmarr]

In that case, it's probably one of the other header files that json.hpp includes. You could confirm that by including these header files instead of json.hpp and commenting out the use of the json library.

https://github.com/nlohmann/json/blob/develop/src/json.hpp#L32-L56

[AMScaglione]

Nope :/ including all of those compiled just fine

[AMScaglione]

However, if I just straight up copy the contents of json.hpp into my test program, it gives me the error again. So the problem is definitely coming from somewhere inside that

[TurpentineDistillery]

compiled just fine.

What if you add a call to snprintf in main()? - Does it still work?
Since this is a linker rather than compiler issue, I'd hypothesize that you may be linking against multiple libraries with conflicting definition of vsnprintf.

[AMScaglione]

With the json stuff commented out and the listed includes included, adding a reference to snprintf worked correctly with no errors.

Also, I am not linking to any other libraries in my linker settings in codeblocks

[nlohmann]

Which compiler are you using inside code::blocks. I remember a discussion (#136 (comment)) a while ago that was related to MinGW support.

[AMScaglione]

Yeah I am using mingw. What should I do about this? I'm only a junior in college so I dont really know anything about that sort of thing

…

On Thu, Apr 6, 2017 at 3:18 AM, Niels Lohmann ***@***.***> wrote: Which compiler are you using inside code::blocks. I remember a discussion (#136 (comment) <#136 (comment)>) a while ago that was related to MinGW support. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#549 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVcekU-KGR6VuEQQRYXcqSXmyGV5SNrJks5rtJG8gaJpZM4M077d> .

[nlohmann]

The problem with MinGW is that it may have a compiler with a non-compliant standard library. A frequent problem with MinGW is also the support of the std::to_string function, but I also heard problems with all kinds of snprintf. So, which compiler are you using?

[AMScaglione]

Oh! It says gnu gcc compiler

…

On Thu, Apr 6, 2017 at 11:44 AM, Niels Lohmann ***@***.***> wrote: The problem with MinGW is that it may have a compiler with a non-compliant standard library. A frequent problem with MinGW is also the support of the std::to_string function, but I also heard problems with all kinds of snprintf. So, which compiler are you using? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#549 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVceka--x_TaX-fmIeVVs2zWG6WVxWQnks5rtQhRgaJpZM4M077d> .

[nlohmann]

Can you switch to Clang?

[AMScaglione]

Well I tried switching to clang, and now Im getting problems where clang cant find ANY of the include headers, even simple ones like iostream. Im fairly certain that that is a compiler issue, but even after lots of research I have no clue how to resolve it

…

On Fri, Apr 7, 2017 at 8:55 AM, Niels Lohmann ***@***.***> wrote: Can you switch to Clang? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#549 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVcekQhpGSBhr5xcHNtgZ7bRXVgns_SRks5rtjJIgaJpZM4M077d> .

[nlohmann]

Sorry to hear that. I also have little experience with MinGW. Could you please try just compiling

#include "json.hpp"

using json = nlohmann::json;

int main() {
    json j;
}

with GCC? Also, can you tell me the version of GCC?

[AMScaglione]

That resulted in the same vsnprintf error. How can I find the version?

…

On Fri, Apr 7, 2017 at 3:28 PM, Niels Lohmann ***@***.***> wrote: Sorry to hear that. I also have little experience with MinGW. Could you please try just compiling #include "json.hpp" using json = nlohmann::json; int main() { json j; } with GCC? Also, can you tell me the version of GCC? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#549 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVcekRX6WGRRb5ivS9Uv1Uo_CntmdZeaks5rto5YgaJpZM4M077d> .

[AMScaglione]

gcc -v returned this:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-5.1.0/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 5.1.0 (tdm64-1)

[nlohmann]

You may want to try https://github.com/JamesBremner/nlohmann-json-parser-for-mingw.

[AMScaglione]

Thank you, that works!

[nlohmann]

Good to hear. Sorry about the suboptimal support for MinGW.