I'm adding the gtest libraries as with an absolute link to the project, but this wouldn't work on somebody else's machine if their source is downloaded elsewhere in the system. Is there a way to link to the .libs with relative address instead of absolute address? Thanks.
Just use a relative path; they work fine for lib file paths (and lib-folder paths in the project settings).
e.g. Instead of "C:\moo\cow.lib" you might put "..\..\moo\cow.lib" (depending on where you're starting from, of course).
(Edit: Fixed a \ char that got swallowed up.)
Related
There is a ncurses6 originally installed in a user home dir, let's say "/home/test", so a test environment was built over this ncurses path, a lot of (in development) apps were compiled and is working now, depending only of the current HOME env variable.
But, because of a purpose beyond our control, we have to change the user home dir. And now it's anything different from "/home/test".
The external apps and ncurses tools still working, we need just point the libraries with LD_LIBRARY_PATH and use a more specific path like we used before for ncurses tools:
LD_LIBRARY_PATH=~/bin/ncurses-6.0/lib ~/bin/ncurses-6.0/bin/tic
But now, after changing the user home dir, we need to point also the terminfo database:
TERMINFO=~/bin/ncurses-6.0/share/terminfo LD_LIBRARY_PATH=~/bin/ncurses-6.0/lib ~/bin/ncurses-6.0/bin/tic
But, is there any way to make the TERMINFO database path permanent without recompiling and reinstalling the ncurses ? Is it hard code in ncurses during compilation ?
The default values are compiled-in. You can override those with environment variables (TERMINFO is standard, TERMINFO_DIRS is an extension). That's not new with ncurses6 (it predates ncurses4, twenty years ago).
The most practical "permanent" change would be to put the overrides in your shell initialization.
It's possible to modify an ELF binary (there's no checksums), but the resulting path couldn't be longer. It could be shorter, since the strings are null-terminated. Since your example adds to the path, that wouldn't work for you, anyway.
I have a problem where I need to know the filesystem path of the current binary, as well as those of any loading (as opposed to loaded) binaries. Here is an example (for Windows): Say we have an executable A.exe, which dynamically binds to B.dll, which in turn binds to C.dll. How could code executing in C.dll get the file paths of C.dll, B.dll, and A.exe?
Oh, and I need to be able to do it on Linux, Mac, and Windows.
On Linux, the closest thing I've found is dl_iterate_phdr, but the who-loaded-who info is missing.
On Windows, The Dynamic-Link functions don't have quite the right functionality.
On Mac, all I can find is what's in dlfcn.h, which is rather pithy for this purpose.
Thanks.
I have a project I can build on both Linux and Windows using CMake. The only issue is that Unix-style paths, in CMakeLists.txt, can't work on Windows (which uses backslashes instead of slashes, also requiring the drive letter).
Is there any way I can write a cross-platform CMakeLists.txt?
You question affects different details:
Just don't use backslashes. Windows will also process slashes.
Don't use drive letters. Use relative paths everywhere.
GET_FILENAME_COMPONENT(X "${CMAKE_CURRENT_SOURCE_DIR}" REALPATH) can solve the whole path without writing any absolute paths.
Add the tool binary paths into your PATH environment variable. So you do not need to search them by yourself (with absolute paths) or
Use FIND_PROGRAM() to get the tools absolute path without guessing around. You could add hints in which registry entries and paths cmake will search for the tool or
Consider to write your own module for every tool. You can copy the skeleton from any module of the modules folder (have a lock at FindJava.cmake; a very good and portable example on how to search a program).
If all those does not help, you can detect the platform by IF(WIN32) or IF(UNIX).
Hope, this helps...
I can't seem to make Xcode find the Core Plot header. I've done the following:
Clone the hg repo;
Drag the CorePlot-CocoaTouch.xcodeproj file into my project;
Opened the CP project and compiled it successfully;
Dragged the lib file into the target's static link list;
Added CorePlot-CocoaTouch as a direct dependency for the target.
But I'm still getting the "CorePlot-CocoaTouch.h: No such file or directory" error on compile. I've been googling around trying to find an answer, but only seem to find a few people having the same problem but no clear solution. What have I missed?
Please help me getting out of it.....
Thanks
Make sure your header search paths contain a reference to the core-plot source directory.
In your targets Build Settings set Header Search Paths to the core-plot/framework directory. For example when your core-plot directory is placed next to your project directoy the search path would contain a value of ../core-plot/framework/** (I'm using a recursive reference here, thus the ** at the end).
Do not miss :-
1-Do not forget to add the library to Target dependance under the "Targets" source list that appears. Click on the "Build Phases" tab and expand the "Target Dependencies" group. Click on the plus button, select the CorePlot-CocoaTouch library, and click Add. This should ensure that the Core Plot library will be built with your application.
2- Core Plot is built as a static library for iPhone, so you'll need to drag the libCorePlot-CocoaTouch.a static library from under the CorePlot-CocoaTouch.xcodeproj group to the "Link Binaries With Libraries" group within the application target's "Build Phases" group you were just in.
3 Under your Build settings, set the Header Search Paths to the relative path from your application to the framework/ subdirectory within the Core Plot source tree. Make sure to make this header search path recursive. You need to add -ObjC to Other Linker Flags as well (as of Xcode 4.2, -all_load does not seem to be needed, but it may be required for older Xcode versions). -Header Search Paths : you must put the relative path for libCorePlot-CocoaTouch.a and it is too much important to check the recursive check-box.
Finally the following link may can help you...
http://code.google.com/p/core-plot/wiki/UsingCorePlotInApplications
maybe this blog might help more than the google source page of CorePlot.
For newbies it might be helpful to use the mac shell to get the relative path of the libCorePlot-CocoaTouch.a. Just open the Terminal and insert following line:
mdfind -name libCorePlot-CocoaTouch.a
you will get listed all paths that contain the file named "libCorePlot-CocoaTouch.a"
I'm working on a Firefox plugin that uses external libraries to render 3D graphics on the browser.
The problem is that I want the plugin to use external libraries packed with it without changing the LD_LIBRARY_PATH variable.
The libraries are installed in a position relative to the plugin (a shared library too), while the actual executable (i.e. the browser) can be located somewhere entirely else.
I'm testing it on Ubuntu (no problem at Windows version of the plugin)
My dependencies are OpenSceneGraph libraries and static compilation will make the plugin really big (not an option if there is another one).
Use the rpath option when linking and specify the 'special' path $ORIGIN.
Example:
-Wl,-R,'$ORIGIN/../lib'
Here's a site that elaborates on using $ORIGIN:
http://www.itee.uq.edu.au/~daniel/using_origin/
You could maybe use the -L flag during the compilation to specify the relative path where the linker can find your shared objects.
If you have already generated your lib, you can link by directly invoking the ldcommand.
Tips : You can easily check if some symbols are defined in a lib using the unix command nm. This is a useful way to check that the linking is well-done.
(If I were you, I would just change temporaly the LD_LIBRARY_PATH as you said in your post. Why don't you want to do this ?)
It's wrong to use relative rpath for security reason,
You should use libdl functions (dlopen, etc)