Bug#388489: Processed: Cloning this bug
Aurelien Jarno <[EMAIL PROTECTED]> 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
Bug#388489: Processed: Cloning this bug
Goswin von Brederlow a écrit : Test multiarch: % mkdir /usr/lib/i486-linux-gnu % mv /usr/lib32/libz.* /usr/lib/i486-linux-gnu Wrong. The purpose of multiarch is to remove bi-arch packages. With multiarch if you want to install a 32-bit glibc on amd64, install the package from i386. Not libc6-i386. We can't lay an egg because we have no chicken and we can't breed a chicken because we have no eggs. The purpose of libc6-i386 is to cover the interim time till multiarch and it isn't to strictly deadlock everything at bi-arch. Well that's your opinion. It's not my opinion and also not the opinion of Tollef for example (we discussed about how to implement multiarch during Fosdem last year). Remeber that we already did have the libc6 package from i386 in use in ia32-libs (and still have). You wanted to have a special libc6-i386 package for amd64 and since you maintain glibc we respected that. We can add libc6 back to the list of packages for amd64 if you don't want to provide a transitional package that mimics multiarch. That would be a one line change. I am in favor of eventually dropping ia32-libs, because I consider this package has not its place in main. You can't rebuild it from sources. I has to go into testing. The ld.so.conf.d/i486-linux-gnu.conf file is essential so multiarch directories can be used already and to allow a smooth transition. 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. Until now the plan to transition to multiarch is the following: - apply patch to binutils - apply patch to gcc - split-out binaries from libc6 all those steps could be done in parallel - implement multiarch in dpkg. Then you can install libc6:i386 on an amd64 system. No need to make an other change, as libc6:i386 provide 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. Why do you want for libc6-i386 servers as a "transition package" while simply installing libc6:i386 will work? 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. 2) ia32-libs takes the libc6-i386 package I already explained I am not in favor of that. 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... -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388489: Processed: Cloning this bug
reopen 388489
severity wishlist
thanks
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow wrote:
>> reopen 388489
>> thanks
>>
>> Aurelien Jarno <[EMAIL PROTECTED]> writes:
>>
>>> Goswin von Brederlow wrote:
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Debian Bug Tracking System a écrit :
>>> retitle -1 libc6-i386: Missing /etc.ld.so.conf.d/i486-linux-gnu.conf
> There is no need for such a file. ld.so natively looks on all
> directories of bi (or tri)-arches directories. If you need to be
> convinced just run: strings /sbin/ldconfig | grep "^/lib"
>
> Clising the bug
Binutils doesn't. And in some cases binutils looks at ld.so.conf and
>>> It does. Well it was not the case on amd64, but it has been fixed two
>>> months ago in version 2.17-2 (see bug#369052).
>>>
>>> I am closing the bug, please only reopen the bug if you have a
>>> testcase to show what you claim.
>>
>> Then what is /etc/ld.so.conf.d/x86_64-linux-gnu.conf for? If 32bit
>> multiarch support doesn't need the conffile then 64bit multiarch would
>> need it even less, being the native bit-ness and all. Think about that
>> for a second.
>>
>> Meanwhile here is your testcase step by step:
>>
>> Create missing link so we can link (pending fix in ia32-libs):
>> % ln -s /usr/lib32/libfreetype.so.6 /usr/lib32/libfreetype.so
>>
>> Test /usr/lib32 setup:
>> % cat foo.c
>> extern int FT_Init_FreeType(void);
>> int main(void) { return FT_Init_FreeType(); }
>> % gcc -m32 -o foo foo.c -lfreetype
>
> So this works. Multiarch not being a requirement for Etch, I fail to
> see why the severity of this bug is serious.
Because the submitter reported it as such and nobody has adjusted it
since then.
>> Test multiarch:
>> % mkdir /usr/lib/i486-linux-gnu
>> % mv /usr/lib32/libz.* /usr/lib/i486-linux-gnu
>
> Wrong. The purpose of multiarch is to remove bi-arch packages. With
> multiarch if you want to install a 32-bit glibc on amd64, install the
> package from i386. Not libc6-i386.
We can't lay an egg because we have no chicken and we can't breed a
chicken because we have no eggs. The purpose of libc6-i386 is to cover
the interim time till multiarch and it isn't to strictly deadlock
everything at bi-arch.
Remeber that we already did have the libc6 package from i386 in use in
ia32-libs (and still have). You wanted to have a special libc6-i386
package for amd64 and since you maintain glibc we respected that. We
can add libc6 back to the list of packages for amd64 if you don't want
to provide a transitional package that mimics multiarch. That would be
a one line change.
The ld.so.conf.d/i486-linux-gnu.conf file is essential so multiarch
directories can be used already and to allow a smooth transition. 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.
I see 3 scenarios where I would consider this bug fixed:
1) you add the file
2) ia32-libs takes the libc6-i386 package
3) binutils adds the patch from #369064 and obsoletes the
/etc/ld.so.conf.d/arch-os-gnu.conf files
MfG
Goswin
