I am trying to compile some C++ code which uses the CGAL library on OS X Lion. I downloaded and installed on some directory the CGAL library. Then, when I try to compile the code, using "make";
triangulation.h:18:64: error: CGAL/Exact_predicates_inexact_constructions_kernel.h: No such file or directory
which means it does not find the CGAL lib. I look at the Makefile, and I see that it compiles using the flag
-lCGAL
Wondering how to solve this, I guess I could pass the information about the placement of my compiled library to this variable, but I do not how. I tried with export and so on but it does not recognize it, any hints?
The error message doesn't mean the library isn't found; it means a header file isn't found. The -lCGAL switch does indeed refer to the library. You're going to need a -IXXXXX switch added on to CFLAGS, where XXXXX is the path to the directory containing the CGAL directory which in turn contains Exact_predicates_inexact_constructions_kernel.h .
Related
How can I link libxml on MinGW when using an omnetpp shell?
I am using omnetpp on a windows 10 machine.
My problem happens when I am trying to install the 3rd party package from here
I think that there is a problem in the Makefile failing to locate the libxml library
Following Rudi's answer (following the question) I changed the Makefile libxml path to I/mingw64/include/libxml2 but I still
get a undefined reference to 'xmlFunctionName' error (for many function names)
I tried to isolate the problem and to compile a sample of code from libxml2
Following the compilation guide: using gcc `xml2-config --cflags --libs` -o tree2 tree2.c
I got a fatal error: 'libxml/parser.h' file not found
When I replaced xml2-config --cflags --libs with -I/mingw64/include/libxml2
I got the same error as before undefined reference to 'xmlFunctionName'
what can I do to resolve that issue?
To this specific problem: libxml2 is actually already present as OMNET 5.x also uses it. All dependencies and tools are available in the tools/win64/mingw64 directory. The problem is that (for unknown reasons) the include file of the include/libxml2/libxml folder. The configure script correctly detects this and makes it available in the Makefile.inc as XML_CFLAGS= = -I/mingw64/include/libxml2
This must be added to the compiler flags for each file where you want to use the XML parser. (the library files are in the /mingw64/lib folder) so those are detected and can be used without additional config.
Generally, third party libraries should be available in the /mingw64/include and /mingw64/lib folders. You can either copy them manually there or try to install it with the mingw package manager (however that will most likely ruin your omnet installation as mingw64 is not particularly consistent and it is a rolling release - i.e. this is highly not recommended).
Android NDK: WARNING:/cygdrive/e/android-sdk-windows/AndroidWorkspace/muPDF/jni/Android.mk:mupdfcore: LOCAL_LDLIBS is always ignored for static libraries [armeabi-v7a] Compile : mupdf <= mupdf.c /bin/sh: /cygdrive/c/Users/MEHDI/Downloads/Compressed/android-ndk-r9d-windows-x86/android-ndk-r9d/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-gcc: No such file or directory make: * [/cygdrive/e/android-sdk-windows/AndroidWorkspace/muPDF/obj/local/armeabi-v7a/objs/mupdf/mupdf.o] Error 127
It looks like you're trying to use GCC 4.4.3 which is no longer distributed with the NDK. Did you set NDK_TOOLCHAIN_VERSION in your environment? If so, please undefine it and re-run the command.
Apart from that, the warning is perfectly normal. You should use LOCAL_EXPORT_LDLIBS if you want to export dependent system libraries for your static library. LOCAL_LDLIBS is only used when building a shared library or executable.
ndk-build on Windows does not need cygwin, and some of its components cannot work with cygwin. Run ndk-build.cmd from Windows CMD shell, and avoid hardcoding cygdrive anywhere.
The warning you get is legitimate. You probably have include $(BUILD_STATIC_LIBRARY) in your Android.mk: this module does not use linker, therefore it does not need LOCAL_LDLIBS neither LOCAL_LDFLAGS. I would not worry about this warning, if this is the only problem in your build.
If you need more help with your project, please post the Android.mk file (or fragments of it), and also the Application.mk if you have one.
I have included the boost library in a Codeblocks c++ project.
Now, in the file
boost/function.hpp
there is an include statement
#include <boost/preprocessor/iterate.hpp>
However I get this error in Codeblocks when I try and compile:
/home/arvind/Documents/Workspace/Browser/boost/function.hpp|15|fatal error:
boost/preprocessor/iterate.hpp: No such file or directory|
What am I doing wrong here? I have simply included the Boost library as it is.
Also, I cannot find the screen/option to set the main class (which will actually execute).
How do I do this?(I am new to CodeBlocks hence this question).
Your boost includes seem to be in a non-standard/system directory : /home/arvind/Documents/Workspace/Browser, you must tell the compiler to look there (gcc -I command-line switch).
Go to Project->Build Options->Search Directories->Compiler and add the directory where boost includes are. I don't have a codeblocks install right here so this was from here.
If you can, I would recommand installing boost on your system once and for all instead of just copying files in your codeblocks workspace.
There is a laptop on which I have no root privilege.
onto the machine I have a library installed using configure --prefix=$HOME/.usr .
after that, I got these files in ~/.usr/lib :
libXX.so.16.0.0
libXX.so.16
libXX.so
libXX.la
libXX.a
when I compile a program that invokes one of function provided by the library with this command :
gcc XXX.c -o xxx.out -L$HOME/.usr/lib -lXX
xxx.out was generated without warning, but when I run it error like this was thrown:
./xxx.out: error while loading shared libraries: libXX.so.16: cannot open shared object file: No such file or directory , though libXX.so.16 resides there.
my clue-less assumption is that ~/.usr/lib wasn't searched when xxx.out is invoked.
but what can I do to specify path of .so , in order that xxx.out can look there for .so file?
An addition is when I feed -static to gcc, another error happens like this:
undefined reference to `function_proviced_by_the_very_librar'
It seems .so does not matter even though -L and -l are given to gcc.
what should I do to build a usable exe with that library?
For other people who has the same question as I did
I found a useful article at tldp about this.
It introduces static/shared/dynamic loaded library, as well as some example code to use them.
There are two ways to achieve that:
Use -rpath linker option:
gcc XXX.c -o xxx.out -L$HOME/.usr/lib -lXX -Wl,-rpath=/home/user/.usr/lib
Use LD_LIBRARY_PATH environment variable - put this line in your ~/.bashrc file:
export LD_LIBRARY_PATH=/home/user/.usr/lib
This will work even for a pre-generated binaries, so you can for example download some packages from the debian.org, unpack the binaries and shared libraries into your home directory, and launch them without recompiling.
For a quick test, you can also do (in bash at least):
LD_LIBRARY_PATH=/home/user/.usr/lib ./xxx.out
which has the advantage of not changing your library path for everything else.
Should it be LIBRARY_PATH instead of LD_LIBRARY_PATH.
gcc checks for LIBRARY_PATH which can be seen with -v option
I've set LIBRARY_SEARCH_PATHS to /opt/local/lib, and verified that the library in question is there (I'm linking to GLEW):
$ls /opt/local/lib
libGLEW.1.5.1.dylib libfreetype.a libz.a
libGLEW.1.5.dylib libfreetype.dylib libz.dylib
libGLEW.a libfreetype.la pkgconfig
libGLEW.dylib libz.1.2.3.dylib
libfreetype.6.dylib libz.1.dylib
but Xcode gives me the linker error
library not found for -lGLEW
I'm generating the Xcode project with CMake, so I don't want to explicitly modify the Xcode project (if someone suggests adding it as a framework, or something like that). Xcode recognizes USER_HEADER_SEARCH_PATHS fine (as in this question); why doesn't it work here?
Perhaps adding something like this to your CMakeLists.txt?
find_library(GLEW_LIB GLEW /opt/local/lib)
if(NOT ${GLEW_LIB})
message(FATAL_ERROR "Could not find GLEW")
endif()
target_link_libraries(myprogram ${GLEW_LIB} ...)
Where myprogram is the name of the target executable that needs to link with the library. You would replace the ... with the other libraries you are using on that executable.
This way CMake would handle the library path details for you.
Xcode works on potentially multiple SDK's, so whenever your define these kinds of things (like HEADER_SEARCH_PATHS or LIBRARY_SEARCH_PATHS) the current SDK root is prepended to the actual path that's getting passed to the linker.
So, one way to make this work would be to add your directory to the SDK. For example, assuming you're building with the Mac OS X 10.5 sdk, you could add your opt dir:
ln -s /opt /Developer/SDKs/MacOSX10.5.sdk/opt
Your library would now be found on your system.
If you don't want to do this, then you will have to look at CMake and find out how to get it to generate a library requirement for your actual library (I don't know anything about CMake, so I can't help you there). This is also why you see a difference between USER_HEADER_SEARCH_PATHS and HEADER_SEARCH_PATHS re your other question.
As another option, you could also specify this path with the OTHER_LDFLAGS build variable:
OTHER_LDFLAGS=-L/opt/local/lib
This would cause the linker to search /opt/local/lib as well as its standard paths and wouldn't require you to generate a different project file.