Red Hat Bugzilla – Bug 58092
libtabe resets LD_LIBRARY_PATH while building, so Intel compiler cannot build libtabe
Last modified: 2007-04-18 12:38:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Description of problem:
Intel C/C++ compiler is delivered with shared libraries. It itself needs them
to run. In addition, programs built by Intel compiler with default options need
the shared libraries too. Intel shared libraries are searched in directories
pointed out by the environment variable LD_LIBRARY_PATH. Before building a
package, a user sets this variable properly. During building, the packages may
only add something to the contents of LD_LIBRARY_PATH but not replace it. Using
LD_LIBRARY_PATH to point out some shared libraries is a commonly used method in
Linux, and the packages should treat the variable carefully. Unfortunately,
some packages don't follow the rule and replace LD_LIBRARY_PATH totally during
building (of course, I mean the variable's copy that is local for the building
task). These packages are: libtabe, procmail, openssl and openssl096. I'm going
to write bug reports on all of them. The following is a more detailed
description of the problem relative to libtabe.
The problem is that src/tsi-src/Makefile.in contains commands resetting
LD_LIBRARY_PATH variable to just ".." before running some programs built by the
compiler. The faulty commands are in the lines 36 and 39 of Makefile.in. For
example, the line 36 is the following:
$(env_libpath)=.. $(ADD) -d $(TSIDB) -f $(SRC) -r -y
It should be corrected in a way like this:
$(env_libpath)=..:$($(env_libpath)) $(ADD) -d $(TSIDB) -f $(SRC) -r -y
Here $(env_libpath)=LD_LIBRARY_PATH, $(ADD)=../util/tsiadd (some program), etc.
Actually, I'm not sure that LD_LIBRARY_PATH needs to be changed here at all.
All the programs called after changing LD_LIBRARY_PATH (programs ../util/tsiadd
and ../util/tsiyindump) work fine without the path ".." being in
LD_LIBRARY_PATH. At least this is true on a Pentium III (i386 architecture).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
If you don't have Intel compiler (icc) you are unable to reproduce the problem.
This compiler is not free. If you really need it to fix the problem, let me
know and I'll try to help you. If you have the compiler, the steps to reproduce
the problem will be the following:
1. Make sure that all environment necessary for icc is set.
2. Make sure that icc will be called instead of gcc, g++, cc, cpp and c++. I
recommend you make links to icc with these names, put them into some directory
and add this directory to the beginning of the PATH variable.
3. Install the package mentioned above from the .src.rpm file (-i option of
rpm). Make sure you have enough permissions to do that.
4. Try to build the .spec file (-bc option of rpm) and get an error message.
Actual Results: The package won't build. In the output (near the end), you may
see the following error message:
error while loading shared libraries: libcxa.so.1: cannot open shared object
file: No such file or directory
Expected Results: The package should build with no problem.
Looking into it. A question, Have you put the your library's path to