Re: ld.so for multiarch and multilib installed at same time
On Fri, Apr 25, 2014 at 06:49:49PM +0800, Yunqiang Su wrote:
>On Fri, Apr 25, 2014 at 5:58 PM, Steve McIntyre <steve@einval.com> wrote:
>> Yunqiang Su wrote:
>>>On amd64 system:
>>>
>>> libc6-i386 make /lib/ld-linux.so.2 link to /lib32/ld-linux.so.2 and link to
>>> /lib32/ld-2.18.so
>>>
>>>libc6:i386 make /lib/ld-linux.so.2 link to /lib/i386-linux-gnu/ld-2.18.so
>>>
>>>when these 2 packages installed at the same time
>>> /lib/ld-linux.so.2 is linked to /lib/i386-linux-gnu/ld-2.18.so
>>>
>>>And dpkg is happy about that this happens.
>>
>> What's responsible for making the links? Are they directly in the
>> package, or made by postinst etc.? Are the 2 packages sensible in
>> terms of multi-arch setup?
>
>ldso is the load of binary, it is the entrance of any binary execution.
>On any system, it is fixed
>
>please see:
>https://wiki.debian.org/Multiarch/LibraryPathOverview#ELF interpreter
Oh yes, I lnow that bit. I've got patches in ld.so in Debian and
upstream... :-)
>It is directly in these packages.
ACK. I was asking (specifically) more how the links are created in
those packages. Looking, you're correct and they're directly in the
package contents:
$ dpkg --contents libc6-i386_2.18-4_amd64.deb | grep -e ld-2. -e ld-linux.so
-rwxr-xr-x root/root 134308 2014-03-02 17:58 ./lib32/ld-2.18.so
lrwxrwxrwx root/root 0 2014-03-02 17:58 ./lib32/ld-linux.so.2 -> ld-2.18.so
lrwxrwxrwx root/root 0 2014-03-02 17:58 ./lib/ld-linux.so.2 -> /lib32/ld-linux.so.2
$ dpkg --contents libc6_2.18-4_i386.deb | grep -e ld-2. -e ld-linux.so
-rwxr-xr-x root/root 134380 2014-03-02 17:47 ./lib/i386-linux-gnu/ld-2.18.so
lrwxrwxrwx root/root 0 2014-03-02 17:47 ./lib/ld-linux.so.2 -> i386-linux-gnu/ld-2.18.so
lrwxrwxrwx root/root 0 2014-03-02 17:47 ./lib/i386-linux-gnu/ld-linux.so.2 -> ld-2.18.so
I'm not sure I understand how dpkg works here either... :-/
>>>On mips64el system:
>>>
>>>libc6-mips32 make /lib/ld.so.1 link to /lib/ld-2.18.so
>>> (yes, quite strange, mips system asks for use /lib as o32
>>>multilib path)
>>
>> Meh, it's not doing the braindead /lib32 thing. That shouldn't be a
>> problem. :-)
>
>lib32 is left for n32 multilib on mips* systems.
OK, cool.
>> Well, you're still trying to replace the same file (link) on
>> disk. dpkg is not going to be happy with that, unless they're
>> consistent for multi-arch.
>
>The problems is why on amd64, dpkg is happy about it?
No idea, I'm afraid. I was hoping I'd be able to help here, but...
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Welcome my son, welcome to the machine.
Reply to: