I am facing a weird but a sensible issue, I have 2 ORACLE_HOMEs, 1st one points to ORACLE Database Software and 2nd one points to ORACLE Client Software.

Why I am forced to do this - reason is: In my system Pro *c is getting compiled from ORACLE Database ORACLE_HOME however Pro *Cobol is getting compiled from ORACLE Client ORACLE_HOME.

To compile Pro *Cobol:


To compile Pro *C


If I put both the path i.e. /u01/app/oracle/product/11.2.0/db_1/lib and /u01/app/oracle/product/11.2.0/client/lib in 1 LD_LIBRARY_PATH, only whichever comes first is getting successful.

Is there any way to fix this issue?

For a temporary fix, I have created 2 small script with different LD_LIBRARY_PATH in each file; so I call this script before I compile Pr *C or Pro *Cobol.

I just don't want to call any script and only 1 LD _LIBRARY_PATH must be able to fix it.

Let me know.


  • Could you please eloberate the actual problem that occurs. LD_LIBRARY_PATH is normally used to lookup libraries, and yes, if a library is found in the first path of LD_LIBRARY_PATH, that one is used. So if you have different environments that search for the same library but with different properties, you have to specify different LD_LIBRARY_PATH variables. But at the moment the actual problem is not very clear...
    – Thomas
    Dec 26, 2016 at 10:26
  • @Thomas- I believe I have specified the actual problem; I have Pro *C and Pro *Cobol programs. Pro *C uses libraries from ORACLE_HOME where database software is installed and Pro *Cobol uses libraries where Oracle Database Client is used. So any one of them can work at a time, else I get Segmentation Fault error for other one and vice verca. How can I specify different LD_LIBRARY_PATH and force application to use specific one. Let me know. Thanks! Dec 27, 2016 at 6:57

2 Answers 2


As @Thomas said in his comment, the problem is that the client and the server contains a very similar set of libs, and if a lib with the matching name is found, it is used, whether it works in the end or not.

There is no way to overcome this, at least not the way you intend to. There is no "application-specific" LD_LIBRARY_PATH, so you probably have to stuck with your script.

  • Thanks Lacek. I have hard coded in the script to overcome this issue. Dec 29, 2016 at 17:52

There's no way to give 2 paths which has library files of the same name in LD_LIBRARY_PATH, the first one in the reading order for the system will be read and used first. HOWEVER...

If you call your command with LD_LIBRARY_PATH=.... in front of the command (on the same line.) then you can avoid needing to have a script switch the variables out.

There should be no delimiters other than a single space between the definition of the variable and the command, like so:

LD_LIBRARY_PATH=/usr/local/lib64:${LD_LIBRARY_PATH} /path/to/your/command

This sets the variable for that single run of the command only, so yes you have to do this every time. However, you don't have to "switch" the variable around by a script anymore.

You can put the above (you will need to modify it of course) into a desktop shortcut also if you are using a GUI environment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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