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

Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly]

Gunnar Wolf <gwolf@gwolf.cx> writes:

> Goswin von Brederlow dijo [Tue, Jan 13, 2004 at 09:41:52AM +0100]:
> > (...)
> > That means apt/dpkg has to be changed and then all libraries that
> > get ported to 64bit. The autobuilder foramd64 can easily check for
> > files in /lib, /lib64, /usr/lib and /usr/lib64 and verify that an ABI
> > line is set correctly.
> ...But this is just too ugly. Not only it breaks tradition and makes
> for a longer search path for libraries, but it also looks
> terrible. Would you accept, say, having 32-bit libraries in /lib and
> 64-bit ones in /lib/64? I might even suggest it being the other way
> around, as 64-bit libraries will hopefully be more common. 

No, /lib and /lib64 is the way everyone else does it. I see no reason
to use /lib/64 just because it looks nicer. Unless there is a good
argument to change the current layout SuSe, RH and everyone else left
won't follow and thats not acceptable.

> Now... Excuse me if I am asking for something obvious or stupid, or
> that has been asked before (just point that out to me): What happens
> when someone has both versions of a library? When a program searches
> for the library, how will it know if it must use the 32 or the 64 bit
> version? Will the soname be different, or the loader checks for ABI
> compatibility? 

mrvn@opteron:~$ ldd /bin/df
        libc.so.6 => /lib64/libc.so.6 (0x0000002a9566c000)
        /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)
mrvn@opteron:~$ ldd /bin/umount 
        libc.so.6 => /lib/libc.so.6 (0x55558000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Different ld-linux use different libraries.

> (yes, I do all of my programming in scripting languages, and am mostly
> unexposed to nasty ABI stuff)


Reply to: