Bug#388489: Processed: Cloning this bug
reopen 388489
severity wishlist
thanks
Aurelien Jarno <aurelien@aurel32.net> writes:
> Goswin von Brederlow wrote:
>> reopen 388489
>> thanks
>>
>> Aurelien Jarno <aurelien@aurel32.net> writes:
>>
>>> Goswin von Brederlow wrote:
>>>> Aurelien Jarno <aurelien@aurel32.net> 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
Reply to: