I'm working in visual studio 2010 and I have code written in C.
If i run in 'Debug' mode, the code will run without any error or warning.
But if I run the same in 'Release' mode, errors and warning will appear.
Error List:
warning C4013:'fprintf' undefined; assuming extern returning int
error C2065: 'stdout': undeclared identifier
What is the reason? please help
warning C4013:'fprintf' undefined; assuming extern returning int
It looks like you didn't include stdio.h.
Seems like a difference in configuration between Release and Debug.
Check the values for "Whole Program Optimization", they may differ between the two build configurations.
I had the same problem in reverse: In Release mode everything was fine, but in Debug mode some functions like 'ext' (FFTW library) were reported as "undefined; assuming extern returning int".
The failing build configuration (Release in my case) had under project properties Configuration Properties > General the option "Whole Program Optimization" set to No Whole Program Optimization.
The successful build configuration had this set to Use Link Time Code Generation. When I set that option in my failing target as well, everything worked fine.
Related
Hello I wanted to try out TLS Callbacks from this example. It's from YT and autor runs this on Windows just like me. I tried to run this code in 2 IDEs Visual Studio and Code Blocks and both of them return an error about this line:
#pragma comment (linker, "/INCLUDE:__tls_used")
VS2022: undefined external symbol __tls_used
Code Blocks: No such file or directory
This error also disappear in VS2022 wehn I use _tls_used instead of __tls_used, but it still doesn't works as it should. Is there any other linker setting that I am supposed to use for this code to make it working?
the Story
I use Symbols to control if a specific piece of Code should be included in the build or not - as most probably everyone working with C/C++ (and others) does. In this particular case I use two symbols, to control if the code running on the Microcontroller is in "Setup"-Mode, or in "EEPROM-Init Mode".
For Both Modes I use Symbols, the Setup Mode Symbol is "SWCONFIG_SETUP" and the EEPROM-Init Symbol is "SWCONFIG_EEPINIT".
The Symbols are defined in the Project Properties of CubeIDE:
The issue is:
both marked lines are skipped in debugging. I'd expect that I could step over/into them when I debug in single step moded, but the debugger just jumps over them, just as if they were disabled and the Symbol SWCONFIG_EEPINIT would not be defined.
I can control that e.g. the code is not executed, because i can not jump into the function with the debugger, and additionaly I can see the Files in the EEPROM were not erased, what would be the purpose of EEP_erase_files();
In the Code both sections are enabled, indicating that the Symbol is defined, otherwise that sections would be greyed out. In an other Code Section, using the #ifdef ... #else ... #endif syntax, the debugger jumps in the greyed out section, indication that it ignores the Symbol.
What I tried to resolve this:
I tried to rebuild/refresh the Index
I deleted the code and re-wrote it.
I deleted the Build Configuration and created it new
I deleted the Symbol in the Project Properties and created it new (using Copy & Paste from the code, to avoid typos)
The Question:
What the heck is going on here? Why is the IDE showing the code section as active, but the Debugger ignores it?
The strange thing is: this workflow allready did it's job!
Solved:
The issue was: i was starting the "Setup" Configuration, not the "SetupEEP" configuration, because for some reason i don't really understand, STM32CubeIDE does not automatically create a Debug configuration, when you create a Build configuration.
I had to create a new Debug Configuration, pointing to the executable in the SetupEEP directory. I just built the "SetupEEP" executable and pressed the debug button, but was not aware, that I started the Debug session with the executable from the "Setup" Build, because i had not created a Debug Configuration for "SetupEEP". This is why the code was omitted: because it was not included in the Build I was running ...
BTW: nice Pitfall, STM!
I am trying to compile PDCurses, but when it attempts to compile pdcscrn.c it gives the error message
../wincon/pdcscrn.c:93:5: error: unknown type name 'PCONSOLE_SCREEN_BUFFER_INFOEX'; did you mean 'PCONSOLE_SCREEN_BUFFER_INFO'?
PCONSOLE_SCREEN_BUFFER_INFOEX lpConsoleScreenBufferInfoEx);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PCONSOLE_SCREEN_BUFFER_INFO
../wincon/pdcscrn.c:95:5: error: unknown type name 'PCONSOLE_SCREEN_BUFFER_INFOEX'; did you mean 'PCONSOLE_SCREEN_BUFFER_INFO'?
PCONSOLE_SCREEN_BUFFER_INFOEX lpConsoleScreenBufferInfoEx);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PCONSOLE_SCREEN_BUFFER_INFO
../wincon/pdcscrn.c:97:8: error: unknown type name 'SetConsoleScreenBufferInfoExFn'
static SetConsoleScreenBufferInfoExFn pSetConsoleScreenBufferInfoEx = NULL;
and there are also a lot more lines, but that is the first part. I am using GCC 8.2.0, and I compiling the wincon directory because I am on windows 10. Thanks.
This is addressed in wincon/README.md:
If your build stops with errors about PCONSOLE_SCREEN_BUFFER_INFOEX,
add the parameter "INFOEX=N" to your make command line and try again.
(This will happen with older compile environments.)
BTW, you should specify the exact toolset you're using, since AFAIK there's no such thing as raw GCC for Windows -- it'll be something like MinGW or Cygwin.
I build one DLL on windows with microsoft-visual-c 6.0 including the source code from libxml2. Now I have used some xmlFree() calls in my code and I now get the linker warning LNK4049.
I have not the slightest idea, how to get rid of this warning. I googled, but all info I found was above my comprehension (I use normally gcc under solaris). Is there a simple receipt (add/remove compiler-flag or #define/#undef or similar)?
Thanks,
Peter
I was getting this warning when statically linking against libxml2_a.lib with MSVC 11. I haven't tried the DLL version so I'm not sure if it is affected in the same way.
The solution was to define these symbols in your project or makefile to tell the libxml2 header files to assume static linkage and avoid dll-importing and dll-exporting the xmlFree variable at the same time:
LIBXML_STATIC
The same applies to libxslt/libexslt too:
LIBXSLT_STATIC
LIBEXSLT_STATIC
Hope this helps.
I will add bit more context for others who face similar error like following.
We did libxml upgrade from 2.9.4 to 2.9.14 and we observed following errors which are similar to above .
warning LNK4217: locally defined symbol xmlStrcmp imported in function
"void __cdecl ::updateRunElement(struct _xmlNode *,class xml::XmlDoc &,struct _xmlNode *,struct const &)"
(?updateRunElement#YAXPEAU_xmlNode##AEAVXmlDoc#xml#2##2##Z)
LINK : error LNK1218: warning treated as error; no output file generated
warning LNK4217: locally defined symbol xmlFreeDoc imported in function "public: __cdecl xml::XmlDoc::~XmlDoc(void)" (??1XmlDoc#xml##QEAA#XZ)
LINK : error LNK1218: warning treated as error; no output file generated
All the other answers for this error points to set runtime library to /md (Multithreaded dll) or viceversa.
I also tried to suppress these warning by
#pragma warning( disable : 4217 1218) and also by project setting "Disable Specific Warnings" but both did not work as keep giving warnings/errors.
But as #vladimir. (Thanks for the answer) suggested defining LIBXML_STATIC as preprocessor in the project where you are using libxml library either as static or dynamically linked should fix all these warning errors.
Im trying to compile z/lib on z/OS USS(thats right a mainframe). ive got gmake and the c89 compiler (which im assuming is c89 standards compliant) and USS is supposed to be POSIX compliant.
But zlib seems to be tripping up on
struct internal_state FAR *state; /* not visible by applications */
with the following error(s)
c89 -O3 -DUSE_MMAP -D_XOPEN_SOURCE_EXTENDED=1 -D_POSIX_SOURCE -c -o example.o example.c
ERROR CCN3277 ./zlib.h:92 Syntax error: possible missing ';' or ','?
ERROR CCN3007 ./zlib.h:92 "struct internal_state" is undefined.
ERROR CCN3166 ./zlib.h:103 Definition of function FAR requires parentheses.
ERROR CCN3276 ./zlib.h:103 Syntax error: possible missing '{'?
ERROR CCN3273 ./zlib.h:124 Missing type in declaration of gz_header.
ERROR CCN3166 ./zlib.h:126 Definition of function gz_header requires parentheses.
ERROR CCN3276 ./zlib.h:126 Syntax error: possible missing '{'?
WARNING CCN3137 ./zlib.h:1346 Declaration must declare at least one declarator, tag, or the members of an enumeration.
ERROR CCN3275 ./zlib.h:1350 Unexpected text z encountered.
ERROR CCN3282 ./zlib.h:1350 The type of the parameters must be specified in a prototype.
ERROR CCN3275 ./example.c:95 Unexpected text file encountered.
ERROR CCN3045 ./example.c:95 Undeclared identifier gzFile.
ERROR CCN3046 ./example.c:96 Syntax error.
ERROR CCN3045 ./example.c:98 Undeclared identifier file.
ERROR CCN3019 ./example.c:523 Expecting an array or a pointer to object type.
ERROR CCN3280 ./example.c:527 Function argument assignment between types "const char*" and "int" is not allowed.
CCN0793(I) Compilation failed for file ./example.c. Object file not created.
FSUM3065 The COMPILE step ended with return code 12.
FSUM3017 Could not compile example.c. Correct the errors and try again.
gmake: *** [example.o] Error 3
when i progressively take out the FAR * (i think its a far pointer but im really not that sure) the errors go away. But as this is a library, im not sure what other artifacts are going to be produced by removing this.
has anybody got any ideas?
any old mainframe heads out there?
it turns out there is a previous version of zlib that compiles on USS, version 1.1.4 or close to that. Its a back level, but i presume this works because it is before the implementation of the FAR pointer in the latest code. So atm i think ive got it to work.
thanks for all your help.
Regards
Mark.
FAR is not a C89 keyword, it is a Microsoft/Intelism and is probably #defined somewhere. If not, you need to define it as nothing:
#define FAR
However, this will probably only fix one of many problems. I would guess that the library uses some form of conditional compilation to handle things like FAR pointers - you need to read the docs to find which configuration is most suitabkle for your platform.
I'd use xlc instead of c89 since xlc is your system default compiler but you'll still probably have issues. I'd subscribe to the MVS-OE email list, the people on it are quite helpful. The link to info about the list appears to be down now so send email to
LISTSERV#VM.MARIST.EDU
with the message: INFO MVS-OE
FWIW, IBM provides a prebuilt version of zlib that includes support for the compression hardware (so-called zEDC) available on recent-vintage mainframes. See zlib for zEnterprise Data Compression