Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I guess that this question is a borderline between ServerFault and StackOverflow and this site. But I think that U&L is most relevant.

I have some C++ code that depends on a library in version X and system provides version Y (X>Y). I have compiled this library and placed resulting files into /opt/lib_name/X/lib, version Y is installed in /usr/lib64. I want to link against so libraries.

Now I'd like to create some script that somehow enables version X, so any code I build with gcc is compiled against version X without any changes in the makefiles.

For now I set LIBRARY_NAME_DIR variable and in the makefile i just append -L $LIBRARY_NAME_DIR, which works but requires me to change makefiles.

Is there any way to do to do this sort of things without having root access to the computer.

Note: while I believe that answer to this question does not depend on the specific libary or the code, all details for my particular problem are here: http://stackoverflow.com/q/24189130/7918.

What I have tried:

  • I have set: LIBRARY_PATH, LD_LIBRARY_PATH, CPLUS_INCLUDE_PATH.
share|improve this question

1 Answer 1

up vote 2 down vote accepted

I don't think there is any way to do this robustly purely with environmental variables. The problem with using LIBRARY_PATH seems to be that any given -L option has precedence. If for any reason the gcc command has -L/usr/lib64, this will be searched first an the older version of the library will be found. Seemingly you are going to change the Makefiles, you should also be careful that a -L/usr/lib64 does not appear first.

Looking at your SO question though, it doesn't look like the above is an issue. However, there is an unnecessary trailing : on the value of your LIBRARY_PATH variable, which might explain why it didn't work.

Also, as noted in the answer to the SO question, LD_LIBRARY_PATH is used by the dynamic linker and is only relevant at runtime for your application. This can be used if the location of the dynamic libraries cannot be found when the application is run. What is used by the GNU linker is LD_RUN_PATH, which essentially does for -rpath what LIBRARY_PATH does for -rpath, except that specifying any -rpath means that LIBRARY_PATH will be ignored (and not just given lower precedence).

What you could try then is:

LIBRARY_PATH=/opt/lib_name/X/lib LD_RUN_PATH=/opt/lib_name/X/lib make

Something that might be more robust is to create a wrapper script for gcc that includes the necessary options, eg:

#!/bin/sh
gcc -L/opt/lib_name/X/lib -Wl,-rpath,/opt/lib_name/X/lib "$@"

Name the file gcc, make it executable and put it in a directory by itself (or at least one where there are no files with the same name as vital commands). Then you could run make like:

PATH=/path/to/script:$PATH make
share|improve this answer
    
Thanks! After additional debugging it turns out that the makefile (provided with the model I use) added -L/usr/lib64. Or it was added by this: stackoverflow.com/q/7493620/7918. So there really is no robust way. –  jb. Jun 13 at 17:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.