Bug#388489: Processed: Cloning this bug

2006-09-22 Thread Goswin von Brederlow
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



Bug#388489: Processed: Cloning this bug

2006-09-22 Thread Goswin von Brederlow
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  

Test multiarch:
% mkdir /usr/lib/i486-linux-gnu
% mv /usr/lib32/libz.* /usr/lib/i486-linux-gnu
% gcc -m32 -o foo foo.c -lfreetype
/usr/bin/ld: warning: libz.so.1, needed by 
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib32/libfreetype.so, not found 
(try using -rpath or -rpath-link)
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib32/libfreetype.so: undefined 
reference to `inflate'
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib32/libfreetype.so: undefined 
reference to `inflateReset'
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib32/libfreetype.so: undefined 
reference to `inflateEnd'
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib32/libfreetype.so: undefined 
reference to `inflateInit2_'
collect2: ld returned 1 exit status

Fix it:
% echo "/usr/lib/i486-linux-gnu" >>/etc/ld.so.conf.d/i486-linux-gnu.conf
% gcc -m32 -o foo foo.c -lfreetype

>> thus ld.so.conf.d/*.
>>
>> Or what is the point of the ld.so.conf.d files at all?
>
> The purpose of the ld.so.conf.d files is to provide an easy way to add
> search directories for some packages (eg atlas), which is a lot easier
> than modifying the ld.so.conf directly.
>
> It is also a way for future multiarch support to add a search path,
> hence the /etc.ld.so.conf.d/(host-triplet).conf in libc6. But it has
> nothing to do with bi-arch or tri-arch which are directly handled in
> the toolchain.

Which is exactly what I am asking for. That
/etc.ld.so.conf.d/(host-triplet).conf is missing in libc6-i386.

Notice that I do ask for that multiarch host triplet file
specificaly. Not for any bi/tri-arch support. I believed requesting
that file would be clear enough indication that the multiarch dirs are
ment but you seem to have misunderstood that completly.

The libc6 on amd64 ships /etc/ld.so.conf.d/x86_64-linux-gnu.conf

% cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf 
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

The libc6-i386 should ship /etc/ld.so.conf.d/i486-linux-gnu.conf

% cat /etc/ld.so.conf.d/i486-linux-gnu.conf 
# Multiarch support
/lib/i486-linux-gnu
/usr/lib/i486-linux-gnu

That is all I'm asking.

MfG
Goswin



Bug#388489: Processed: Cloning this bug

2006-09-21 Thread Aurelien Jarno

Goswin von Brederlow wrote:

reopen 388489
thanks

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.



thus ld.so.conf.d/*.

Or what is the point of the ld.so.conf.d files at all?


The purpose of the ld.so.conf.d files is to provide an easy way to add 
search directories for some packages (eg atlas), which is a lot easier 
than modifying the ld.so.conf directly.


It is also a way for future multiarch support to add a search path, 
hence the /etc.ld.so.conf.d/(host-triplet).conf in libc6. But it has 
nothing to do with bi-arch or tri-arch which are directly handled in the 
toolchain.


--
  .''`.  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

2006-09-21 Thread Goswin von Brederlow
reopen 388489
thanks

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
thus ld.so.conf.d/*.

Or what is the point of the ld.so.conf.d files at all?

MfG
Goswin