Bug#388489: Processed: Cloning this bug
Aurelien Jarno <aurelien@aurel32.net> writes:
> Goswin von Brederlow a écrit :
> What do you mean by "smooth transition"? Could you explain to others
> what do you have in mind, it seems you have your own view on how to
> implement and how to do the transition to multiarch.
My plan is to provide an environment where packages can already switch
to multiarch and can be used as is (see fakeroot below) or with the
help of a simple apt/dpkg-deb wrapper even though some slow moving
packages like glibc neccessarily are behind on converting. Making
libc6-i386 behave just like libc6:i386 means that we don't have to
stop everything till glibc is converted.
> Until now the plan to transition to multiarch is the following:
> - apply patch to binutils
> - apply patch to gcc
The multiarch includes are already searched by gcc.
When I move /usr/lib32/libc.{a,so} to /usr/lib/i486-linux-gnu and
patch binutils then gcc -m32 works just fine. Without binutils patch
it says "/usr/bin/ld: cannot find -lc". Doesn't even need a gcc
recompile.
What patch is missing?
> - split-out binaries from libc6
and move libnss* and gconv to multiarch dirs.
> all those steps could be done in parallel
>
> - implement multiarch in dpkg.
That can be done in parallel too. And it can be tested with simple
libs like zlib without the need to have glibc fully ready.
> Then you can install libc6:i386 on an amd64 system. No need to make an
> other change, as libc6:i386 provide
Every other library can also be changed to multiarch in
parallel. Provided ld looks there.
A prime candidate for this is fakeroot which comes with libs for
multiple archs. Since nothing gets compiled against those libs the
binutils bug doesn't matter there. The ideal package to test and use
the runtime stuff for multiarch. It only needs support from the ld,
meaning libc6-i386 on amd64.
>> The
>> ld.so.conf.d/i486-linux-gnu.conf files only logical place is in the
>> libc6[-i386] packages and the multiarch libc6 oni386 already has to
>> conflict with libc6-i386 on amd64 (reverse for libc6-amd64). If
>> ld.so.conf.d/i486-linux-gnu.conf is in any other package then that
>> just further complicates the dependencies and conflicts in the future.
>
> Why do you want to add a conflict there? There is no need now. But if
> you add the file, there will be a need to do that.
Both libc6:i386 and libc6-i386 provide the ld. Without proper
conflicts, replaces, provides you get an overwrite error. So I don't
add a conflict where there isn't already is one.
> Why do you want for libc6-i386 servers as a "transition package" while
> simply installing libc6:i386 will work?
Because we don't have a (usable) libc6:i386 in the archive yet and
with the goal of multiarch it is not there to stay. So it is
temporary, transitional. That's just what it is.
The current libc6:i386 does not look in the multiarch dirs for its
plugins so it can not be converted by the apt/dpkg-deb wrapper
automatically. It needs to be patched and recompiled for that. Most
other packages can be converted on the fly. The closer libc6-i386
mimics a multiarch libc6:i386 the better people can test multiarch
with the wrapper or convert their own libs.
>> I see 3 scenarios where I would consider this bug fixed:
>>
>> 1) you add the file
>
> From my point of view this will complexify the transition to
> multiarch, because you will need to add conflicts.
The ld already neccessitates the conflict so no change there.
>> 2) ia32-libs takes the libc6-i386 package
>
> I already explained I am not in favor of that.
And I prefer it that way too as long as it doesn't hinder me.
>> 3) binutils adds the patch from #369064 and obsoletes the
>> /etc/ld.so.conf.d/arch-os-gnu.conf files
>
> I don't see how it would fix the "problem". This patch only add the
> native multiarch directory (ie i486-linux-gnu on i386,
> x86_64-linux-gnu on amd64, etc...) to the search path. Not the 32- or
> 64-bit counterpart one. Well I haven't looked in deep in your latest
> patch...
Please read that bug again. It adds the native multiarch dir to every
output format. The native dir for that format. Elf 32bit i486 gets
i486-linux-gnu as dir. Elf 64bit amd64 gets x86_64-linux-gnu as
dir. Exactly as we want it. It is easy to miss because binutils still
uses i386 so /usr/lib/i386-linux-gnu is used. The second patch
corrects that too.
In fact this is better than ld.so.conf.d since only linking 32bit code
would look in i486-linux-gnu and only 64bit code in x86_64-linux-gnu.
No '/usr/bin/ld: skipping incompatible
/usr/lib/x86_64-linux-gnu/libc.so when searching for -lc' warnings.
MfG
Goswin
Reply to: