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
C++ Builder and mem.h ambiguity #3911
Comments
Indeed, that's unexpected. Which version of |
It's the latest ZSTD - 1.5.5. Also, many compiler headers use <mem.h> - so we got tons of nightmare errors form e.g. winnt.h |
I checked, and there is no place in the source code where
Do you mean it happens with some other programs and libraries too ? |
I have never experienced any problems with C++ Builder and other libraries like libdeflate, zlib, xxhash, lz4, etc. |
So, if I do understand properly, That's pretty weird. The environment must be altered pretty strongly to reach such a situation. As a first investigation step, let's check: is |
I seem to have a similar problem. Not really the same, but similar (I think related) in that C++ Builder (Clang actually) says that <string.h> needs to be included. I'm running in circles trying to add includes etc. Using v 1.5.5, downloaded today. To elaborate. I created a new static library project with C++ Builder 12 (clang for both 32 and 64 bit) and I added all *.c files from /common/ and /decompress/ to the project. I then built the *.dll and *.a files semi successfully. Semi because I get these weird warnings, yet the dll/a files get built.
I get a lot more warnings (but always memcpy, memset and memmove), you get the gist. When I add the library to a project and use a function, for instance
Which goes straight to the heart of the warnings .. PS. What am I missing ? (aside from a good night's sleep ;) PS. prototyping the functions in
gets rid of the lib building warnings, but the linker problems in the main project that uses the static lib remain |
Before I move on, and for others, should they be in the same situation, the solution is to rename I hope next version of the library can take that in account The problem is a circular include issue as mem.h gets processed before it should. I think it's an Embarcadero issue (that you probably should work around), because I believe the #include OMG. I should have read the original post better, it's basically the same conclusion -lol-. |
It's very weird issue, but currently we have ambiguity between "mem.h" from ZSTD and <mem.h> from Embarcadero RAD Studio (C++ Builder which is actually based on clang) See: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Memset,_wmemset
Currently it is not possible to compile ZSTD with RAD Studio unless rename "mem.h" to, say, "zstd_mem.h"
All other your programs like LZ4 and XXHASH have no compile issues with C++ Builder.
The text was updated successfully, but these errors were encountered: