Bug 124984 - Problems with relocatable glibc rpm packages
Problems with relocatable glibc rpm packages
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-01 15:37 EDT by Ashwani Wason
Modified: 2007-11-30 17:07 EST (History)
0 users

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


Attachments (Terms of Use)
Spec file (92.54 KB, text/plain)
2004-06-01 15:39 EDT, Ashwani Wason
no flags Details
Gzipped log file from rpmbuild (236.85 KB, application/octet-stream)
2004-06-01 15:41 EDT, Ashwani Wason
no flags Details
Test program (333 bytes, text/plain)
2004-06-01 15:41 EDT, Ashwani Wason
no flags Details
Log file from build with NPTL and NPTL LD.SO testing enabled (76.13 KB, application/octet-stream)
2004-06-01 17:26 EDT, Ashwani Wason
no flags Details

  None (edit)
Description Ashwani Wason 2004-06-01 15:37:47 EDT
Description of problem:

I rebuild the glibc rpms to install glibc and related rpms in a
non-standard location (/opt/eternal/glibc). I've been doing a number
of changes to the spec file to get this done because the spec file
that comes with redhat's glibc does not allow relocation by just
changing the prefix (modified spec file attached: hopefully fixes will
be merged).

I never had any problems in the past in either building, installing,
or using the modified rpm packages. When I build 2.3.2-95.20 glibc
rpms for i686 using the attached spec file I see the following problems:

1. NPTL and NPTL LD.SO tests fail. The build just hangs in the testing
phase and does not continue. I do not have a log file for this, but it
can be reproduced consistently. On the same machine if I rebuild using
the spec file distributed by redhat, the build completes successfully,
even though some of the tests fail.

2. I commented out these two tests and then continued the build. The
packages were built (log file from rpmbuild attached) and they also
install successfully. However a program that uses dlsym (attached) and
that is linked against this glibc does a segmentation violation at
startup time in dlfcn/dlsym.c:54.

----------------------------------------------------------------------

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

2.3.2-95.20

----------------------------------------------------------------------

How reproducible:

Every time.

----------------------------------------------------------------------

Steps to Reproduce:

1. Build relocatable glibc packages using the attached spec file and
install them. Command used for build: rpmbuild -ba -vv --target=i686
--target=i386 glibc.spec 2>&1|tee glibc.log

2. Link the attached program (dlsym.c) against the standard glibc and
run it. Works. Some info:

ash 120 ashwas> gcc -o dlsym.real dlsym.c -D_GNU_SOURCE -ldl

ash 120 ashwas> ldd dlsym.real
        libdl.so.2 => /lib/libdl.so.2 (0xb75d9000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb74a1000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)

ash 120 ashwas> ./dlsym.real
Address of dirname is 0xb757c660.

3. Link the attached program (dlsym.c) against the modified glibc and
run it. Does not work. Some info:

ash 120 ashwas> gcc -o dlsym.mod -I/opt/eternal/glibc/include
-D_GNU_SOURCE -g dlsym.c
-Wl,--dynamic-linker=/opt/eternal/glibc/lib/ld-linux.so.2
-Wl,--rpath=/opt/eternal/glibc/lib:/lib:/usr/lib
-L/opt/eternal/glibc/lib -ldl

ash 120 ashwas> ldd dlsym.mod
        libdl.so.2 => /opt/eternal/glibc/lib/libdl.so.2 (0xb75e7000)
        libc.so.6 => /opt/eternal/glibc/lib/tls/libc.so.6 (0xb74af000)
        /opt/eternal/glibc/lib/ld-linux.so.2 =>
/opt/eternal/glibc/lib/ld-linux.so.2 (0xb75eb000)

ash 120 ashwas> ./dlsym.mod
Segmentation fault (core dumped)

----------------------------------------------------------------------

Additional info:

From the build and execute machine:

ash 120 bin> uname -a
Linux ash 2.4.21-15.ELsmp #1 SMP Thu Apr 22 00:18:24 EDT 2004 i686
i686 i386 GNU/Linux

ash 120 bin> cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping        : 9
cpu MHz         : 2992.722
cache size      : 512 KB
physical id     : 0
siblings        : 2
runqueue        : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 5976.88

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping        : 9
cpu MHz         : 2992.722
cache size      : 512 KB
physical id     : 0
siblings        : 2
runqueue        : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 5976.88

RPM information:

Standard glibc:

[root@ash 05-28-2004]# rpm -qa --queryformat '%{NAME} %{VERSION}
%{RELEASE} %{ARCH}\n'|grep glibc
glibc-headers 2.3.2 95.20 i386
glibc 2.3.2 95.20 i686
glibc-utils 2.3.2 95.20 i386
glibc-common 2.3.2 95.20 i386
glibc-profile 2.3.2 95.20 i386
glibc-devel 2.3.2 95.20 i386
glibc-kernheaders 2.4 8.34 i386

RPMS and install of modified glibc:

[root@ash 05-28-2004]# ls -R RPMS/i686
RPMS/i686:
glibc-eternal-2.3.2-95.20.i686.rpm
glibc-eternal-common-2.3.2-95.20.i386.rpm
glibc-eternal-debug-2.3.2-95.20.i386.rpm
glibc-eternal-debuginfo-2.3.2-95.20.i686.rpm
glibc-eternal-debuginfo-common-2.3.2-95.20.i386.rpm
glibc-eternal-devel-2.3.2-95.20.i386.rpm
glibc-eternal-headers-2.3.2-95.20.i386.rpm
glibc-eternal-profile-2.3.2-95.20.i386.rpm
glibc-eternal-utils-2.3.2-95.20.i386.rpm
nptl-eternal-devel-2.3.2-95.20.i686.rpm
nscd-eternal-2.3.2-95.20.i386.rpm

[root@ash 05-28-2004]#  rpm -ivh RPMS/i686/*
Preparing...                ################################### [100%]
   1:glibc-eternal-debuginfo################################### [  9%]
   2:glibc-eternal-common   ################################### [ 18%]
   3:glibc-eternal          ################################### [ 27%]
Stopping sshd:[  OK  ]
Starting sshd:[  OK  ]
   4:glibc-eternal-headers  ################################### [ 36%]
   5:glibc-eternal-devel    ################################### [ 45%]
   6:glibc-eternal-debug    ################################### [ 55%]
   7:glibc-eternal-debuginfo################################### [ 64%]
   8:glibc-eternal-profile  ################################### [ 73%]
   9:glibc-eternal-utils    ################################### [ 82%]
  10:nptl-eternal-devel     ################################### [ 91%]
  11:nscd-eternal           ################################### [100%]

root@ash 05-28-2004]# rpm -qa --queryformat '%{NAME} %{VERSION}
%{RELEASE} %{ARCH}\n'|grep eternal
glibc-eternal 2.3.2 95.20 i686
nscd-eternal 2.3.2 95.20 i386
glibc-eternal-debug 2.3.2 95.20 i386
glibc-eternal-debuginfo-common 2.3.2 95.20 i386
glibc-eternal-devel 2.3.2 95.20 i386
glibc-eternal-utils 2.3.2 95.20 i386
glibc-eternal-headers 2.3.2 95.20 i386
glibc-eternal-profile 2.3.2 95.20 i386
glibc-eternal-debuginfo 2.3.2 95.20 i686
glibc-eternal-common 2.3.2 95.20 i386
nptl-eternal-devel 2.3.2 95.20 i686

GDB info:

ash 120 ashwas> gdb dlsym.mod core.29821
Using host libthread_db library "/lib/tls/libthread_db.so.1".
Core was generated by `./dlsym.mod'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /opt/eternal/glibc/lib/libdl.so.2...done.
Loaded symbols for /opt/eternal/glibc/lib/libdl.so.2
Reading symbols from /opt/eternal/glibc/lib/tls/libc.so.6...Reading
symbols from
/usr/lib/debug//opt/eternal/glibc/lib/tls/libc-2.3.2.so.debug...done.
done.
Loaded symbols for /opt/eternal/glibc/lib/tls/libc.so.6
Reading symbols from /opt/eternal/glibc/lib/ld-linux.so.2...Reading
symbols from
/usr/lib/debug//opt/eternal/glibc/lib/ld-2.3.2.so.debug...done.
done.
Loaded symbols for /opt/eternal/glibc/lib/ld-linux.so.2
#0  0xb75eb6d6 in ?? () from /opt/eternal/glibc/lib/ld-linux.so.2
(gdb) bt
#0  0xb75eb6d6 in ?? () from /opt/eternal/glibc/lib/ld-linux.so.2
#1  0xb75e8032 in dlsym (handle=0x0, name=0x0) at dlsym.c:54
#2  0x0804845b in main () at dlsym.c:7
(gdb)
Comment 1 Ashwani Wason 2004-06-01 15:39:36 EDT
Created attachment 100758 [details]
Spec file
Comment 2 Ashwani Wason 2004-06-01 15:41:15 EDT
Created attachment 100759 [details]
Gzipped log file from rpmbuild
Comment 3 Ashwani Wason 2004-06-01 15:41:42 EDT
Created attachment 100760 [details]
Test program
Comment 4 Ashwani Wason 2004-06-01 17:26:13 EDT
Created attachment 100767 [details]
Log file from build with NPTL and NPTL LD.SO testing enabled

The rpmbuild hangs here at a certain point in testing (see the end of the log
file). The last few error statements say that libgcc_s.so.1 must be installed
for certain nptl tests. It is installed on the build machine:

ash 120 05-28-2004> rpm -q --whatprovides libgcc_s.so.1
libgcc-ssa-3.5ssa-0.20030801.47
libgcc-3.2.3-34

ash 120 05-28-2004> ls -l /lib/libgcc_s.so.1
lrwxrwxrwx    1 root	 root		28 May 17 00:51 /lib/libgcc_s.so.1 ->
libgcc_s-3.2.3-20040414.so.1*
ash 120 05-28-2004> ls -l /lib/libgcc_s-3.2.3-20040414.so.1
-rwxr-xr-x    1 root	 root	     32408 Apr 15 12:01
/lib/libgcc_s-3.2.3-20040414.so.1*
Comment 5 Jakub Jelinek 2004-06-08 06:20:31 EDT
Well, if you build with prefix other than /usr, you must deal with
its consequences.  Particularly e.g. that the dynamic linker will not
search by default in the library paths it normally does and thus will
not find libgcc_s.so.1 unless you link it into that path.
Comment 6 Ashwani Wason 2004-06-11 12:52:24 EDT
>> Particularly e.g. that the dynamic linker will not
>> search by default in the library paths it normally does and thus will
>> not find libgcc_s.so.1 unless you link it into that path.

The binaries that we build and that use the relocated dynamic linker
are compiled in a fashion to take care of it. 

Like I said earlier building/installing/using the i386 glibc has no
problem with this. It is only the i686 glibc that is broken when
relocated. There is definitely a problem somewhere even though you do
not intend to acknowledge it.

Even the glibc FAQ's say that a prefix other than /usr should be just
fine.

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