[suggest] Bug report: Bogus dependency in dante RPM: "ld-linux-x86-64.so.2(GLIBC_PRIVATE)(64bit)"

[Dag Wieers]

On Tue, 10 Jun 2008, Volkert de Buisonjé wrote:

> (NOTE: I know I should have attached a patch, but please read on for the 
> reason why I was unable to do that.)
>
> Bug report: Bogus dependency in dante RPM: 
> "ld-linux-x86-64.so.2(GLIBC_PRIVATE)(64bit)"
>
> How to reproduce: try "yum install dante" on any CentOS 5.x x86_64 machine

Yes, I know but I do not have a solution for it.


> Dear RPMforge developers,
>
> I've noticed something odd when attempting to install the Dante SOCKS proxy 
> server on a CentOS 5.1 x86_64 machine.
>
> Whenever I attempt to either install Dante from RPMForge through yum or build 
> the RPM from source using the upstream tarball, I encounter the following 
> dependency error:
>
> ld-linux-x86-64.so.2(GLIBC_PRIVATE)(64bit)
>
> From what I have understood so far (mostly from searching for this dependency 
> on rpm.pbone.net) , this dependency is bogus, since it only applies to 
> earlier distros (CentOS 3 / EL3).
>
> The really weird thing is that I can successfully build a natively compiled 
> binary RPM on a CentOS 5.1 x86_64 machine using either the src rpm or the 
> SPEC file and then I *still* get this dependency error when trying to install 
> the resulting binary RPM's.
>
> At first I thought this would have to be some hardcoded dependency specified 
> somewhere in the Dante SPEC file, but I couldn't find any reference to 
> "ld-linux-x86-64.so.2(GLIBC_PRIVATE)(64bit)" anywhere in the SPEC file.
>
> After installing the (natively built) binary RPM's using the --nodeps option, 
> Dante appeared to run fine.
>
> Do you have any idea how to remove this (apparently) false dependency? 
> Thanks.

You can remove it manually by trimming the output of the script used to 
find the requirements automatically, but that is not the correct solution 
here. We have to find out why the dependency is added.

I investigated and after an hour found this and wrote a patch.

 	[root at rhun ~]# echo /lib/libsocks.so.0.1.0 |  /usr/lib/rpm/find-requires
 	ld-linux.so.2
 	ld-linux.so.2(GLIBC_PRIVATE)
 	libcrypt.so.1
 	libc.so.6
 	libc.so.6(GLIBC_2.0)
 	libc.so.6(GLIBC_2.1)
 	libc.so.6(GLIBC_2.1.3)
 	libc.so.6(GLIBC_2.2)
 	libc.so.6(GLIBC_2.3)
 	libc.so.6(GLIBC_2.3.4)
 	libc.so.6(GLIBC_2.4)
 	libdl.so.2
 	libnsl.so.1
 	libpam.so.0

 	[root at rhun ~]# objdump -p /lib/libsocks.so.0.1.0 | grep PRIVATE
 	    0x0963cf85 0x00 08 GLIBC_PRIVATE

 	[root at rhun ~]# objdump -t /lib/libsocks.so.0.1.0 | grep PRIVATE
 	00000000       O *UND*  00000004              __libc_enable_secure@@GLIBC_PRIVATE

So that seems to be the problem:

 	[root at lisse dante-1.1.19]# grep -r '__libc_enable_secure' .
 	./config.log:configure:30565: checking for __libc_enable_secure
 	./libscompat/issetugid.c:extern int __libc_enable_secure;
 	./libscompat/issetugid.c:       if (__libc_enable_secure)
 	./NEWS:o Use __libc_enable_secure if it exists and issetugid() doesn't.
 	./configure:echo "$as_me:$LINENO: checking for __libc_enable_secure" >&5
 	./configure:echo $ECHO_N "checking for __libc_enable_secure... $ECHO_C" >&6
 	./configure:extern int __libc_enable_secure;
 	./configure:    if (__libc_enable_secure == 0)
 	./configure.ac:AC_MSG_CHECKING([for __libc_enable_secure])
 	./configure.ac:extern int __libc_enable_secure;
 	./configure.ac: if (__libc_enable_secure == 0)

And I wrote a new patch that gets rid of the use of internal function 
__libc_enable_secure even though there has been some interest to have the 
issetugid() functionality as part of glibc/kernel instead of less secure 
by each applications.

Kind regards,
-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]