Bug 58095 - procmail resets LD_LIBRARY_PATH while building, so Intel compiler cannot build procmail
procmail resets LD_LIBRARY_PATH while building, so Intel compiler cannot buil...
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: procmail (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-08 09:23 EST by Denis
Modified: 2010-05-05 09:02 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-06 20:21:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Denis 2002-01-08 09:23:09 EST
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 a bug report on libtabe (# 58092) and I'm going to write bug 
reports on others. The following is a more detailed description of the problem 
relative to procmail: 

While building, the script "src/autoconf" generates and runs several programs 
(all named _autotest.c) to determine experimentally some parameters of the 
current system. One of the programs is to determine the maximum number of 
program arguments. It resets the current environment to just one 
variable "PATH". See "src/autoconf", line 1351:
	*(environ=nenv)="PATH=."; ...
(environ is a global variable pointing to an array of strings with environment 
variables)
Then the program tries to run itself again by calling execv(argv[0],...);. 
However, the new instance of the program cannot be run because it needs 
LD_LIBRARY_PATH in the environment. Unfortunately, I can't propose a bugfix 
because I don't quite understand why the program resets the environment. 
Certainly resetting environment doesn't influence the program's output much. On 
my computer, the original output of the program built by gcc is the following:
	#define MAX_argc 7588
When I comment the resetting operator (/**(environ=nenv)="PATH=.";*/ ...), the 
output changes but just a little:
	#define MAX_argc 7625


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 procmail 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.

Additional info:
Comment 1 Trond Eivind Glomsrxd 2002-01-14 14:45:37 EST
1) Is this still a problem with procmail 3.22 from Rawhide?
2) Why not just put the path of the Intel libraries in /etc/ld.so.conf?

Comment 2 Denis 2002-10-18 08:54:59 EDT
Here are the answers:

1) Yes, this problem presents in procmail 3.22 from Rawhide 
(http://www.procmail.org/procmail-3.22.tar.gz).

2) From compiler's point of view, there is no difference between 
LD_LIBRARY_PATH, ld.so.conf or ldconfig using. The reason why we prefer 
LD_LIBRARY_PATH is that setting of environment variable does not require root 
permissions, when updating of ld.so.conf does. So, using of LD_LIBRARY_PATH 
makes compiler or libraries development and usage simpler. Probably we will 
take another way for compiler distributions. Nevertheless, procmail uses a 
risky programming style while truncates its whole environment.
Comment 3 Jens Petersen 2004-01-05 20:24:03 EST
If you have a non-intrusive clean patch to our package
then I'm happy to accept, but since we don't support icc
I don't have time to fix this.
Comment 4 Jens Petersen 2004-01-06 20:21:10 EST
Closing for now.

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