I'm currently porting a rather big project from C++ Builder 5 to the newest version, C++ Builder XE. It's my first experience with C++ Builder. I'm stuck with an error in a file, but I don't want to include this file anyway (it's code of a component not required anymore). I was not able to find out where and how this file is included, however. The compiler error does not give any hint at all apart from the error itself. How do you usually find out where a file is included?
The preprocessor is perfect for this. Right click on the cpp file which gives you the error in the project manager then choose "preprocess"
The output from this tells you every file and line number in the order they are processed. You can then search for the file in question, and the line above it is the file that included it.
This could conceivably be another header file as well, so it could be a long chain, but you can determine exactly where it comes from.
In the Project Options, enable the compiler's general messages. When the compiler encounters an error, you will be able to see the chain of includes that lead to the erroneous code.
If the files in question are rather sizable, a tool like Doxygen can be helpful in showing you the include dependencies (as well as call paths, etc.).
If it's just once or twice you'll have to do this, David Dean's suggestion of the preprocessor is golden.
Related
A file of Delphi's own LIBs has been changed, for a specific need. Since we have several programmers, I need to make sure everyone has this change, and in the future as well.
As the Delphi libs are installed and are not versioned, I need to verify that it is in the correct version.
I wanted to do this before compiling the version.
What I was able to do is create a hash of the file so I assure that it was not modified
{$IF getMD5('C:\Delphi7\Lib\arquivo.dcu') = 'B1C1CBE80477S09AC4C1B39C28FE9619'}
{$Message Fatal 'Version of file .dcu file in Delphi7 Lib is wrong..}
{$IFEND}
That way it does not work, because every moment returns the message of [Fatal Error]
Any idea?
My Delphi time was long ago, but my approach with C++ would be, to add a unique symbol to the lib, that the project depends on. Then, you will at least get a link time error if the symbol is missing (i.e. not your version of the lib is used).
How could this look like (not sure if this is feasible in Delphi)?
In addition to your modifications to the LIB, you also add a function called "MyModificationSentinelABCDEF()" that is empty (the name is not important, just make sure it is unique). Then, instead of the $IF statement you proposed, you add a call to this function and a descriptive comment to explains why it is there and what has to be done if there is an error related to it.
If the function is missing, you should see a compile/link error.
My project uses objective c++. I have to enable modules but when I Set "Enable modules" to YES my project starts to prompt lots of errors that I don't know how to handle them. I have set "Build Active Architectures" to NO and added -fmodules and -fcxx-modules.
I have to mention that my project is pretty old (7 years).
Attached part of the error's log.
It looks like it messes up everything.
error log
There is a problem with your include paths somewhere. The system-supplied header tgmath.h has a line that says #include <complex.h>. That should be resolved as a "system" file. Instead, your log shows it referencing something in another path (.../dmz_files/Eigen/.../Complex.h).
Contributing to the problem is the Mac file system, which doesn't do a good job of distinguishing between "complex" and "Complex".
The actual errors are coming from trying to interpret C++ code in an Objective-C context, but those are rather irrelevant compared to referencing the wrong file.
(Why this should be specific to modules, I do not know.)
I've set up VES and am modifying the Kiwiviewer app in XCode 4.3.2. Kiwi builds and runs fine, so I'm now trying to set up Sudzc within my app (it works fine standalone). I've followed the tutorial here but at the point after modifying the headers, where his app builds and runs, mine instead comes up with a succession of errors. At first, it gives >150 errors all along the lines of:
Lexical or Preprocessor Issue
Invalid token at start of a preprocessor expression
Mostly pointing at the line
#include "xmlversion.h"
in a file tree.h, which is a part of vtkmodular/Utilities/vtklibxml2/include/libxml/tree.h.
Changing the " " to < > (which was suggested for a similar problem) instead gives another Lexical or Preprocessor Issue, this time that 'xmlversion.h' file not found - seemingly all in the file tree.h. The file's in my Project Navigator (and cmd-clicking on #include "xmlversion.h" does indeed load the file, so it understands it that way).
Presumably then the problem is with vtk having its own version of libxml2? If this is the case - what can I do about this? All of the errors I've looked at seem to originate from within soap handler classes, and eventually get through to "include < libxml/tree.h>" - which is then in the vtk directory shown above. I'm not really sure where to go from here - is it wrong to include the library that's added in the instructions? Can/should I modify the header paths? If this isn't the tree.h the rest of the code is looking for, where is it - a quick system search didn't find it?
Or am I completely off the mark?
Thanks in advance!
I got an answer from the VES Mailing List, link here. It ended up being as simple as removing the VTK version of libxml2, which it seems VES doesn't use. Hope this might be of use to someone!
When compiling a OpenCV 2.3 project in Builder I get multiple errors starting with "_fm_atan2l is not a member of 'std'" and continuing with other math related errors in that form. I also get "Multiple declaration of '_Ctraits::_Isnan(double)' and other similar errors. This happens after I simply include the OpenCV header files and thus seems unrelated to anything I have done in the application itself.
The only file I have included so far is "cv.h" in OpenCV's include directory. Am I doing it wrong already or is there maybe something else I have to set up first?
You can download simple project combining 2.3.2 and c++ builder xe2 from my site:
http://www.compvision.ru/forum/index.php?showtopic=763
There are fixed headers for builder, and lib converter in archive.
There are also .lib files in archive, but it'll be better if you make them by yourself from original .lib files contained in your opencv distribution using LibConverter.exe utility.
And there is some strange thing: some dll files need to be renamed to something like .dl or .d. Compiled program will prompt you about it.
you can correct OCV atan2 issue with bcc32, including fastmath in std namespace (for more info see: https://forums.embarcadero.com/message.jspa?messageID=363384 [^]).... but more other issues are there after ...
Until now I'm unable to build OCV 2.3.1 with CBuilder XE2 :(
I am trying to resolve a problem with a set of packages that apparently have dependency issues. Occasionally during a Build All, I get this error:
Delphi "E2161 Error: RLINK32: Error opening file ________.drf "
What does it mean / indicate, and what is a "drf" file?
It looks like this turned out to be the main problem / solution.
Open up all the packages for which you have source code, and specify the compile option:
'Rebuild explicitly' instead of 'Rebuild when needed'.
In addition to the Solving the 'cannot find drf file' problem when compiling packages article, I also came across Delphi bug report #44134, in which a commenter mentions that the problem stems from having your .dpk files in the same directory as your .pas files when that same directory is in the library path and "rebuild as needed" is enabled.
You thus have three options for fixing this problem:
Turn off "rebuild as needed". This seems to be the most common solution.
Put your package files (*.dpk, *.dproj) into a separate directory and then reinstall the packages. I have done this, with success.
Remove the directory containing your .dpk and .pas files from the library path. Note that Delphi will add it back again in certain circumstances, including when you install/reinstall your package.
Hmm... never heard of them. I just searched the project that inspired the question you linked to, and there's nothing in there with a "DRF" extension. Checking here doesn't turn up anything Delphi-related. But the fact that it's a linker error, not a compiler error, would lead me to guess that the first two letters stand for "Delphi Resource."
Try a search through your project's directory tree and see if you can find anything with a DRF extension. If so, try opening it with a text editor to see if it's readable, and if not, try a hex editor if you know anything about reading binary file formats. See if you can make any sense of it.
If you don't find any, then Delphi's probably getting it from somewhere in the code it's compiling. Try running a grep search for "DRF" on your directory tree and see if it turns up anything.
From http://www.delphifaq.com/faq/delphi/delphi_ide/f157.shtml :
When you compile with packages, you
can specify which packages should be
considered for linkage. The package
requirements of the project get stored
into a temporary Windows resource file
with a .DRF extension.
Whatever that file with the many underscores is, the linker is most probably searching it in what it thinks the tempdirectory is (you can confirm this using filemon). The explanation at DelphiFaq, where a misdefined %TEMP% is the culprit, is as likely as any reason.
Sometimes the problem was file access permissions.
A workaround was run Delphi as Administrator.