Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multiple versions of 'vsnprintf' #549

Closed
AMScaglione opened this issue Apr 5, 2017 · 19 comments
Closed

multiple versions of 'vsnprintf' #549

AMScaglione opened this issue Apr 5, 2017 · 19 comments
Labels
platform: mingw related to MinGW

Comments

@AMScaglione
Copy link

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
Copy link
Contributor

gregmarr commented Apr 5, 2017

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
Copy link
Author

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
Copy link
Contributor

gregmarr commented Apr 5, 2017

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
Copy link
Author

Nope :/ including all of those compiled just fine

@AMScaglione
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link
Owner

nlohmann commented Apr 6, 2017

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

@AMScaglione
Copy link
Author

AMScaglione commented Apr 6, 2017 via email

@nlohmann nlohmann added the platform: mingw related to MinGW label Apr 6, 2017
@nlohmann
Copy link
Owner

nlohmann commented Apr 6, 2017

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
Copy link
Author

AMScaglione commented Apr 6, 2017 via email

@nlohmann
Copy link
Owner

nlohmann commented Apr 7, 2017

Can you switch to Clang?

@AMScaglione
Copy link
Author

AMScaglione commented Apr 7, 2017 via email

@nlohmann
Copy link
Owner

nlohmann commented Apr 7, 2017

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
Copy link
Author

AMScaglione commented Apr 7, 2017 via email

@AMScaglione
Copy link
Author

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
Copy link
Owner

nlohmann commented Apr 8, 2017

@AMScaglione
Copy link
Author

Thank you, that works!

@nlohmann
Copy link
Owner

nlohmann commented Apr 9, 2017

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

@nlohmann nlohmann closed this as completed Apr 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform: mingw related to MinGW
Projects
None yet
Development

No branches or pull requests

4 participants