How to change #include statements with relative paths in c++ files so they work when compiling?
Hi,
I have no suitable background to deal with such cases on my own. I've got this soft LoRDEC, which needs gatb-core to work. When compiling it all #include statements from gatb files in c++ generate error because of relative path in them: etc.
fatal error: hdf5/hdf5.h: No such file or directory
I could change those paths manually but it seems tedious. Is there any clever way to deal with it?
Thanks
• 7,452 views
•
link
1 answer
First check that you've installed the hdf5 library. Then if the software has a configure script, check if you can specify the path to the hdf5 library as part of the configuration. Otherwise you could try setting LDFLAGS on the command line before compiling e.g. (for Bash)
export LDFLAGS="-L/path/to/hdf5/lib"
./configure
make
make install
• 0 views
•
link
Log in to answer this question.
UNIX is your friend. sed will make it easy for you. Once you determine how to exactly identify these lines, what needs to be replaced and what should take its place, a combination of find and sed can do this in a few milliseconds for you :)
This seems quite difficult (for me) as there are functional characters like
/in paths and thissed 's/old/new/g'won't work. Could you give me example how to do this: eg. change#include <gatb/bank/impl/BankFasta.hpp>on#include </home/../gatb/bank/impl/BankFasta.hpp>with sed command?Use backslash to escape meta-characters.
This is pretty off-topic, but you generally just want to add an appropriate
-Ioption to the Makefile (or whatever else it's using).For gatb-core I downloaded binaries. I've got some options in Makefile of LoRDEC.:
Do you mean something else?
If
hdf5.his under$(GATB)/include/hdf5/then that should work. If you post the gcc or cc line that produces that error then we'll be able to determine better what's wrong.Typically
-I/path/to/include/dirgoes toCPPFLAGS(cpp=c-preprocessor, not c-plus-plus) and-std=c++0x -O3 -gtoCXXFLAGS. Nonetheless, the naming is defined in Makefile. A lot of makefiles do not follow this convention. Another makefile-independent approach is to specify