I encountered a preprocessor or lexical error when I tried to build my project to an archive. This did not happen on the release nor debug configuration settings on the simulator.
The message is:
lexical and preprocessor issue: 'tidy.h' file not found
The 'tidy.h' is included by CTidy.h, which is part of TouchXML library.
I found 'tidy.h' in a subfolder of 'iPhoneSimulator5.1.sdk'. To my surprise, the file is absent in 'iPhoneOS5.1.sdk'
Is it OK for me to just copy the file to the iPhoneOS5.1.sdk?
Thanks
Try commenting out the:
#include "tidy.h"
... in CTidy.h, or alternatively comment out:
#include "CTidy.h"
That is, check to see whether the header file is really necessary.
If you find that it's not, either submit a patch to the TouchXML developers, or file a bug with them, or send them an email.
It is quite common for headers to be included unnecessarily. For example I could write some code that depends on "foo.h", then delete my code, or refactor it in such a way that it doesn't need the header anymore, yet forget to delete the header inclusion as well.
Related
I'm trying to build a project with vitis using the library xuartps.h but I can't because of this error
code screenchot
I don't know why this happens. Could you help me please?
This is an include file. It gets literally copy-pasted on your sources. On top of that, the compiler could notify the error around the wrong line, but it could be before or after the one which is actually wrong.
Check your sources that include such header, you must miss a semicolon there, or another typo. You should not look into the header.
I have the following project setup:
1) A main iOS project ('super project')... nothing special here, the project was built on top of one of the default iOS templates from Xcode.
2) A second project ('subproject'), which was created on top of the Static Library template. I added this project to the super project, and created references to it from the superproject in the 'Target Dependencies' and 'Link Binary with Libraries' build phases.
Inside the subproject, I have a C function declaration which looks like this:
ABAddressBookRef myABAddressBookCreateWithOptions(CFDictionaryRef options, CFErrorRef * error);
It's meant as a replacement/proxy of the similarily named function from the AddressBook framework and uses a type (ABAddressBookRef) from that framework. The declaration is stored in a header file, and the implementation exists in the corresponding .m file. To make this type available, I added the framework header to the .pch file of my subproject:
#ifdef __OBJC__
#import <AddressBook/AddressBook.h>
#import <Foundation/Foundation.h>
#endif
The following problem occurs:
If I build the superproject (release or debug config), the build fails with this error message:
.../ManagedCFunctions.h:24:1: Unknown type name 'ABAddressBookRef'
Things I've done to fix the issue, or at least get an idea of what's going on:
Building the subproject separately works (but a subsequent superproject build fails regardless)
Uncommenting the declaration gets rid of the error, but naturally raises an "Implicit Declaration of Function" warning at the calling location
Adding the import to the superproject's .pch file does not help
Adding the import to the header file of the function directly works, but is not an option in my scenario (parts of the code are autogenerated, and it would be hard to find out which file needs which frameworks)
I suspect that maybe the header file is not processed in Objective-C, but rather C mode, so the imports are ignored due to the #ifdef __OBJC__ macro around the import, but removing it hasn't helped either. I also tried to add #import <Foundation/Foundation.h> to the function's header file to 'suggest' Objective-C mode, and it actually enabled correct syntax highlighting in the file, but hasn't helped for building.
Any suggestions as to why the symbol is found in the .m, but not in the .h file? Or any workaround that does not require adding the import to a specific header file, but globally?
Today I found a isuue after I in project -> Info -> Configurations add a configuration file, then I run my project, it goes wrong in my pch file.
It shows that xxx.h not found, I search a lot of solutions, but I can not get the right answer. So I remember that step.
I deleted the configuration file, and my project become normal.
I hope this will be helpful for this kind issue.
Using PC-Lint, I'm attempting to make a header file be treated as a library header so that I can suppress messages from inside it. I'm using the library module option +libm(module.c) which should treat module.c as a library module and any headers it includes (i.e module.h) as library headers as described in section 6.1 of the PC-Lint manual for v9.00. Naturally, module.h is also included in my source files which are not library modules.
The problem is that when I lint the code, I still get messages from module.h even though I provided the +libm(module.c) option. I suspect this is because the module.h file is included in my other non-library modules. But such a situation is a typical use case and so this makes this +libm option useless. I know I could use +libh(module.h) or +libdir(...) but I want +libm(module.c) to work properly for me. Any suggestions?
It is not presented like that in the manual, but my experience shows that not all header files included by the library module are considered library. They cannot be: What if the module includes your own header files, the header files you want explicitly to be processed?
Use the Lint option -vf (caution: large output!) to see how Lint interprets your header files. Library files are designated as such.
The ones missing can be added using the normal -lib* option set.
I've run into trouble in the past when I've tried porting some C++ code written on Mac OS X to a Linux system, or trying to compile code written against an older version of gcc/g++ with a newer one:
It seems that some (older?) versions of gcc/g++ would automatically include some header files for you.
For example, code that uses printf should require #include <stdio.h>. And code that uses memcpy should require #include <string.h>. But depending on the version of gcc I'm using, it will occasionally include these for me.
It wreaks havoc when I forget to include something and then never get errors until I go to compile the code on another system. At that point it's a game of running all over the project and fixing the includes.
Has anyone else run into this? Is there a way to force gcc to autoinclude or to not autoinclude? Or, is there a way to know what it's autoincluding?
-include file
Process file as if #include "file" appeared as the first line of the primary source file. However, the first directory searched for file is the preprocessor's working directory instead of the directory containing the main source file. If not found there, it is searched for in the remainder of the #include "..." search chain as normal.
If multiple -include options are given, the files are included in the order they appear on the command line.
http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
Are you sure it's not other headers pulling those one's in, and on the other platforms not doing so?
When compiling on different systems, you might meet different problems and not only includes.
I would suggest investing in a continuous build system that will compile on all OS you need after each update of the code, so you are rapidly aware of any portability issue.
You can also put all common system header files inside a specific header file you will write and systematically include it in all your files.
Is there a "call stack" for compiler errors in Visual Studio 2005 (C++)?
For example, I am using a boost::scoped_ptr as the value in a QHash. This is however causing the following compile error:
1>c:\qt\include\qtcore\../../src/corelib/tools/qhash.h(743) : error C2248: 'boost::scoped_ptr<T>::operator =' : cannot access private member declared in class 'boost::scoped_ptr<T>'
From the build output I know which of my source files is causing the error and the line number in the qhash.h that is causing the error but I am trying to track down the line number in my source file that is generating the error (hence the "call stack" idea).
Please note, I am not looking for the solution to the problem of using a scoped_ptr in a QHash but the problem of tracking down where compile errors are generated. This would also be useful for helping track down weird warnings. More often than not I run into this problem when using templated classes.
Thanks!
Sometimes with strange errors it helps to preprocess the file and look at that output. With VS look for "Generate Preprocessed File" under preprocessor settings (or set the /P switch). This will generate XXX.i from XXX.cpp which may help you figure out the problem.
Make sure you turn off the switch after, with this option turned on it won't generate an obj file.
If you look at the build output, you should see which project and which .cpp file was being compiled when this error occurred.
There is really no notion of "call stack" here, because the compiler processes one source file at a time. You have a compiler error in the header file, so you need to find out which source file including that header was being compiled.
These types of errors can be hard to track down. Usually I end up comment out code and finding the offending line and working from there. After doing it a while you will learn to better read the error messages and understand what tripped up the compiler. As it stands the compilers error messages are just horrible.
In this case it is saying that you have an object of type boost::scoped_ptr<T> that it is trying to copy but the class won't let you (operator= and the copy ctor are both hidden). So you need to look at how the class is used and see why it is trying to copy it. Maybe a scoped_ptr isn't what you need. Maybe you need a shared_ptr?