Bug 58098 - openssl resets LD_LIBRARY_PATH while building, so Intel compiler cannot build openssl. So does openssl096.
Summary: openssl resets LD_LIBRARY_PATH while building, so Intel compiler cannot build...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: openssl
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-01-08 15:15 UTC by Denis
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-02-03 10:02:01 UTC
Embargoed:


Attachments (Terms of Use)

Description Denis 2002-01-08 15:15:54 UTC
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've 
already written bug reports on libtabe (# 58092) and procmail (# 58095). Below 
is a more detailed description of the problem relative to openssl and 
openssl096. It doesn't make sence to write separate bug reports on these 2 
packages as their problems are absolutely the same.

Both packages contain commands changing LD_LIBRARY_PATH in their spec files, 
section %build. For example, openssl-0.9.6.spec contains the following string:
	LD_LIBRARY_PATH=${TOPDIR}:${PATH} ; export LD_LIBRARY_PATH
To solve the problem, this string should be changed to something like this:
	LD_LIBRARY_PATH=${TOPDIR}:${PATH}:$LD_LIBRARY_PATH ; export 
LD_LIBRARY_PATH


Version-Release number of selected component (if applicable):


How reproducible:
Always

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 one of the packages 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 error message about libcxa.so.1 should disappear. Then 
either the package will build with no problem or another problem may appear 
with the following diagnostics:
ld: libcrypto.so.0.9.6: undefined versioned symbol name __register_frame_info@@G
LIBC_2.0
It's Ok for you if you get this diagnostics.

Additional info:

Comment 1 Tomas Mraz 2005-02-03 10:02:01 UTC
This should be fixed in current Fedora Core.



Note You need to log in before you can comment on or make changes to this bug.