On Mon, Mar 21, 2011 at 8:45 PM, Ian Lake <ian.lake@xxxxxxxxxxxxxx> wrote:
Is there a way to tell what files in my packages are requiring the 32bit glibc?
Perhaps this this toy script on the rpm buildroot directory can help : https://github.com/yersinia/junkcode/raw/master/rpm/rpm-find-deps/rpm-find-deps.sh.
What exactly does it mean to rebuild it separately for x86_64?
IMHO already answered. BTW,
it means to remake a rpmrebuild for that architecture directly (on a x86_64 machine) or in a chroot environment, using, for example, some build environment for this : http://ldn.linuxfoundation.org/article/opensuse-build-system-building-binary-packages-many-linux-distributions-once, just for an example.
hth
hth
From: Panu Matilainen <pmatilai@xxxxxxxxxx>Sent: Mon, March 21, 2011 10:12:12 AM
Subject: Re: Ignore RPM Dependencies
On 03/21/2011 04:52 PM, Ian Lake wrote:
> So if I want to address the underlying problem as you all suggested, I need some
> help.
>
> I am not in control of the system I am building on. I have been told everything
> on it was installed via RPMs.
>
> I'm guessing the dependencies I see, are caused by executable files with a #!
> /usr/local/bin/mypython but I don't know how to fix it....here is some of my
> reasoning
>
> /usr/local/bin/mypython is a soft link to the executable /usr/bin/python2.6
>
> when I build an RPM, I see these dependencies get generated.
> Requires(pre): /bin/sh
> Requires(post): /bin/sh
> Requires: /bin/bash /usr/bin/env /usr/local/bin/mypython libc.so.6
> libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libdl.so.2
> libdl. so.2(GLIBC_2.0) libm.so.6 libm.so.6(GLIBC_2.0)
>
> My guess is the dependencies come from python because of the results of the ldd
> command
> [x@x]$ ldd /usr/local/bin/mypython
> linux-vdso.so.1 => (0x00007fff84181000)
> libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0
> (0x0000003340000000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003d0ca00000)
> libdl.so.2 => /lib64/libdl.so.2 (0x0000003d0c200000)
> libutil.so.1 => /lib64/libutil.so.1 (0x0000003d17e00000)
> libm.so.6 => /lib64/libm.so.6 (0x0000003d0d200000)
> libc.so.6 => /lib64/libc.so.6 (0x0000003d0c600000)
> /lib64/ld-linux-x86-64.so.2 (0x0000003d0be00000)
>
>
> The files do exist on the system:
> [x@x]$ locate libm.so.6
> /lib64/libm.so.6
> [x@x]$ locate libc.so.6
> /lib64/libc.so.6
> [x@x]$ locate libdl.so.2
> /lib64/libdl.so.2
>
> They must have been installed via an RPM, because I can do a --whatprovides
> command on them. Any significance that I have to call out the exact path?
>
> [x@x]$ rpm -q --whatprovides libdl.so.2
> no package provides libdl.so.2
> [x@x$ rpm -q --whatprovides /lib64/libdl.so.2
> glibc-2.12-1.7.el6_0.3.x86_64
>
> Any thoughts on where to go from here?
Rpm is correct here - the dependencies /are/ really missing. You have a
64bit glibc but your package depends on 32bit glibc. Note the difference
in provides:
[pmatilai@localhost]$ rpm -q --provides glibc.i686|grep libdl|head -1
libdl.so.2
[pmatilai@localhost]$ rpm -q --provides glibc.x86_64|grep libdl|head -1
libdl.so.2()(64bit)
Where to go from here depends on your package: if you have a source for
it, you'll want to rebuild it separately for x86_64. If you're
(re)packaging some 3rd party binary so recompiling is not an option,
then you need to install a 32bit glibc for it ("yum install
<yourpackage.rpm>" would've figured this out for you automatically)
- Panu -
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
