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

Re: multiarch/bi-arch status (ETA) question

* Lennart Sorensen (lsorense@csclub.uwaterloo.ca) wrote:
> On Tue, Jul 05, 2005 at 03:21:41PM -0400, David Wood wrote:
> > I'm just trying to understand what people's objections to multiarch are. I 
> > didn't understand what Hugo said in answer to that. I meant that it 
> > sounded like his answers (the problems he brought up) were things that 
> > multiarch would fix, not problems with multiarch itself.
> The main objection is to change locations of files in a way that is
> incompatible with existing software on linux.

Pfft, give me a break.  Guess we'll never move anything ever again.
That's just not how it works.

> > Would they not work properly with the symlink in place?
> is /usr/lib/i386-linux a symlink back to /usr/lib or what?  /usr/lib
> can't be a symlink to /usr/lib/i386-linux after all.  So if programs on
> i386 look for things in /usr/lib and programs on amd64 look in /usr/lib,
> which one gets to keep the location and which one MUST move?

Actually you can put a symlink in /usr/lib to the actual library in
/usr/lib/i386-linux, if necessary.

> Sure you can recode ld-linux.so to look in /lib/<arch> and
> /usr/lib/<arch> which I have seen done years ago on solaris systems
> using various path lookup tricks and such.

'tricks' isn't exactly an appropriate word for this given that's how
things are looked up today.

> > And if that failed (is this really possible?), why not use a bind mount? 
> > Or a hard link? (Well, maybe you don't like hard links, but without 
> > multiarch, bind mounts in chroots are a fact of life anyway.)
> The problem is you have multiple architectures that all want the same
> filenames in the same location.  bind mounts and symlinks won't solve
> that unfortunately.  Changing the ld loader might, but even then
> anything else that has a hardcoded path needs fixing.

That'd be why we need multiarch, yes.  The symlinks can be used to solve
the problem when you can be sure of the answer, and as I recall there
was a proposal to have a 'default' for the system which would answer the
question when there's multiple options on the system.

> > I feel a little crazy here. Is there something really basic I'm missing?
> > 
> > What do you mean not compatible? With the linkage of the legacy directory 
> > to the new one, where would the incompatibility come from?
> Both amd64 and i386 programs want the legacy location.  They can't both
> be symlinks.  And if you place the arch stuff as a subdir of the
> original location it can't be a bind mount or symlink at all.

You can certainly have a symlink from /usr/lib/libx.so.1 ->
/usr/lib/i386-linux/libx.so.1, and if you have to pick one when there's
multiple options available then you'll just have to pick one and that's
life.  Generally things that require this kind of hackery should be
fixed regardless.

> > A library would work unmodified in the old location, and then over time it 
> > can be modified to work in the new one.
> But is the old location file going to be i386 or amd64 architecture?

Depends on the 'default' setting of the box.

> Some other distributions have made their amd64 stuff use /usr/lib64/
> instead, which we are compatible with using a symlink, but it's
> considered a rather unclean solution by many.

Right, which is why there's multiarch...



Attachment: signature.asc
Description: Digital signature

Reply to: