[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64



On 04-Oct-24 23:24, Kurt Roeckx wrote:
> On Sun, Oct 24, 2004 at 10:18:15PM +0200, Andreas Jochens wrote:
> > 
> > This patch is harmless with respect to any LSB requirement.
> > The name of the dynamic loader, which is coded into every binary
> > can only be changed in the gcc package. This patch does not change 
> > that.
> 
> I don't know what you all changed in the gcc-3.4 archive.  But
> this is what I now get with something I just compiled:
> 
> ldd test
>         libc.so.6 => /lib/libc.so.6 (0x0000002a9566d000)
>         /lib/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x0000002a95556000)
> 
> While with the pure64 archive with either gcc-3.3 of 3.4 it's
> still pointing to /lib64/ld-linux-x86-64.so.2

I patched the gcc-3.4 package in the amd64/gcc-3.4 archive to get that
result. For the patch I used please look at BTS #277852. I recompiled
the complete amd64/gcc-3.4 archive with that patch and without the 
'/lib64' and '/usr/lib64' symlinks in place. I still have to reupload
most of the recompiled packages to alioth but you should be able to
debootstrap a new chroot from the amd64/gcc-3.4 archive and do a 
'rm /lib64' without making the system unusable.

> > which installs a symlink '/lib64/ld-lsb-x86-64.so.2'
> > which points to '/lib/ld-linux-x86-64-so.2' (actually, the current 
>                                        ^
> 
> Should probably atleast be a .

Yes, of course.

> [...]  We should also make sure that programs
> build on an other distro can be run on debian so I think we also
> need to have a "/lib64/ld-linux-x86-64.so.2" provided in some
> way.

I fully agree with that. However, we do not have such a symlink yet.
The pure64 archive has a patched 'base-files' package which creates
such a symlink, but the maintainer of 'base-files' rejected that patch
because he said it should be done by the 'glibc' package and I think his
decision is correct. Logically it would belong in the 'libc6' package.
It tried to put the symlink there, but this caused the system to stop
working during updates of the 'libc6' package. We could easily have that
symlink if we decided to make our binaries independent of the '/lib64'
directory.

Still, this particular patch is harmless in all these respects. The
patch which really changes something is the patch to gcc which changes
the name which is coded into every binary.

Regards
Andreas Jochens



Reply to: