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

Re: Linux Core Consortium

Ian Murdock <imurdock@progeny.com> writes:

> On Thu, 2004-12-09 at 09:07 +0100, Scott James Remnant wrote:
>> On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote:
>> > The main technical effect that I see would be that the names of some 
>> > dynamic libraries would change. And compatibility with the old names 
>> > could be maintained indefinitely if necessary.
>> > 
>> ?!??!?!?!?!?!?!"PO!(*"!$*_(!$*"($*!("*$_*!"*$("
>> That is all.
> Well, that's certainly constructive.
> Can someone provide an example of where the name of a dynamic
> library itself (i.e., the one in the file system, after the
> package is unpacked) would change? I'd be surprised if this was
> a big issue. The LSB/FHS should take care of file system level
> incompatibilities already (though Debian may put some things in
> /lib that RPM-based distros put in /usr/lib due to more strict policy
> about such things), so I'd think the main issue wouldn't so much be
> about the names of the dynamic libraries themselves, but the names of
> the packages they come in (acl vs. libacl1, as per my last message).

When multiarch hits all (core) libs will move around

/lib/* -> /lib/`gcc -dumpmachine`/
/usr/lib/* -> /usr/lib/`gcc -dumpmachine`/
/usr/X11R6/lib/* -> /usr/X11R6/lib/`gcc -dumpmachine`/

If you aim at having the same path to libs (which only broken rpath
needs) then this will be your nightmare.


PS: The above lib dirs are the best and only practical solution we
have for multiarch.

Reply to: