Bug#722788: labrea link with -L/usr/lib
❦ 15 septembre 2013 17:54 CEST, YunQiang Su wzss...@gmail.com :
Some pointers would be appreciated, maybe on wiki.debian.org. While
fixing it on HAProxy can be done just in debian/rules, I cannot do the
same thing for labrea. I need to patch configure and this is something
that I don't like to do.
The pattern `-L${prefix}/lib` seems to happen often. Are we going to
patch all upstream sources for this problem while this worked for years
without any problem? The `-L${prefix}/lib` is convenient because it
allows a user to install the lib in its home.
Thanks for you to point it out to me. Do you have any better idea to deal with
problem for both of these situation?
Unfortunately, no. Does this have been discussed in some mailing list?
Does the bug really happens for real? Doesn't system paths used before
user-specified paths?
You can tag it as won't-fix if you'd like to.
If without multilib packages installed or install some libraries
installed manually,
this package can be built successfully.
Does the problem happens if the user only install stuff with apt-get?
--
Use library functions.
- The Elements of Programming Style (Kernighan Plauger)
signature.asc
Description: PGP signature
Bug#722788: labrea link with -L/usr/lib
On Mon, Sep 16, 2013 at 5:47 PM, Vincent Bernat ber...@debian.org wrote:
❦ 15 septembre 2013 17:54 CEST, YunQiang Su wzss...@gmail.com :
Some pointers would be appreciated, maybe on wiki.debian.org. While
fixing it on HAProxy can be done just in debian/rules, I cannot do the
same thing for labrea. I need to patch configure and this is something
that I don't like to do.
The pattern `-L${prefix}/lib` seems to happen often. Are we going to
patch all upstream sources for this problem while this worked for years
without any problem? The `-L${prefix}/lib` is convenient because it
allows a user to install the lib in its home.
Thanks for you to point it out to me. Do you have any better idea to deal
with
problem for both of these situation?
Unfortunately, no. Does this have been discussed in some mailing list?
Does the bug really happens for real? Doesn't system paths used before
user-specified paths?
You can tag it as won't-fix if you'd like to.
If without multilib packages installed or install some libraries
installed manually,
this package can be built successfully.
Does the problem happens if the user only install stuff with apt-get?
yes, it will. if user install libc6-dev-mips32, there will be some thing like
libc.so, libm.so etc in /usr/lib.
x86 series (i386, amd64, x32) don't do it like this, they put i386
stuff to lib32
and x32 stuff to libx32, amd64 stuff to lib64.
Unfortunately, mips series don't do it like x86 series.
--
Use library functions.
- The Elements of Programming Style (Kernighan Plauger)
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722788: labrea link with -L/usr/lib
❦ 16 septembre 2013 12:47 CEST, YunQiang Su wzss...@gmail.com : Does the bug really happens for real? Doesn't system paths used before user-specified paths? You can tag it as won't-fix if you'd like to. If without multilib packages installed or install some libraries installed manually, this package can be built successfully. Does the problem happens if the user only install stuff with apt-get? yes, it will. if user install libc6-dev-mips32, there will be some thing like libc.so, libm.so etc in /usr/lib. x86 series (i386, amd64, x32) don't do it like this, they put i386 stuff to lib32 and x32 stuff to libx32, amd64 stuff to lib64. Unfortunately, mips series don't do it like x86 series. Shouldn't the linker favor /usr/lib64 over /usr/lib in this case? I thought that it would be possible but since there is no `-lsystem` option (like `-isystem`), this may be because the default path is not special. -- /* Am I fucking pedantic or what? */ 2.2.16 /usr/src/linux/drivers/scsi/qlogicpti.h signature.asc Description: PGP signature
Bug#722788: labrea link with -L/usr/lib
On Tue, Sep 17, 2013 at 2:46 AM, Vincent Bernat ber...@debian.org wrote: ❦ 16 septembre 2013 12:47 CEST, YunQiang Su wzss...@gmail.com : Does the bug really happens for real? Doesn't system paths used before user-specified paths? You can tag it as won't-fix if you'd like to. If without multilib packages installed or install some libraries installed manually, this package can be built successfully. Does the problem happens if the user only install stuff with apt-get? yes, it will. if user install libc6-dev-mips32, there will be some thing like libc.so, libm.so etc in /usr/lib. x86 series (i386, amd64, x32) don't do it like this, they put i386 stuff to lib32 and x32 stuff to libx32, amd64 stuff to lib64. Unfortunately, mips series don't do it like x86 series. Shouldn't the linker favor /usr/lib64 over /usr/lib in this case? I I prefer libo32 over lib indeed, while SGI's specification ask for it. It's so sadly. thought that it would be possible but since there is no `-lsystem` option (like `-isystem`), this may be because the default path is not special. -- /* Am I fucking pedantic or what? */ 2.2.16 /usr/src/linux/drivers/scsi/qlogicpti.h -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722788: labrea link with -L/usr/lib
❦ 14 septembre 2013 05:29 CEST, YunQiang Su wzss...@gmail.com :
This package has one or more -L/usr/lib in its build system,
which will make it ftbfs if there is libraries under /usr/lib,
while is not the default architecture, mips* for example.
On mips* systems, /usr/lib is defined as place to hold O32
libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
Beside the way, on the multiarch system like Debian, user may install
libraries under /usr/lib by hand.
Please use the default search path if you can, and please consider fix
this.
I will try to fix this bug, while if you can help to fix it,
It will be very appreciative.
Hi!
Some pointers would be appreciated, maybe on wiki.debian.org. While
fixing it on HAProxy can be done just in debian/rules, I cannot do the
same thing for labrea. I need to patch configure and this is something
that I don't like to do.
The pattern `-L${prefix}/lib` seems to happen often. Are we going to
patch all upstream sources for this problem while this worked for years
without any problem? The `-L${prefix}/lib` is convenient because it
allows a user to install the lib in its home.
Does the bug really happens for real? Doesn't system paths used before
user-specified paths?
--
Use recursive procedures for recursively-defined data structures.
- The Elements of Programming Style (Kernighan Plauger)
signature.asc
Description: PGP signature
Bug#722788: labrea link with -L/usr/lib
On Sun, Sep 15, 2013 at 9:59 PM, Vincent Bernat ber...@debian.org wrote:
❦ 14 septembre 2013 05:29 CEST, YunQiang Su wzss...@gmail.com :
This package has one or more -L/usr/lib in its build system,
which will make it ftbfs if there is libraries under /usr/lib,
while is not the default architecture, mips* for example.
On mips* systems, /usr/lib is defined as place to hold O32
libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.
Beside the way, on the multiarch system like Debian, user may install
libraries under /usr/lib by hand.
Please use the default search path if you can, and please consider fix
this.
I will try to fix this bug, while if you can help to fix it,
It will be very appreciative.
Hi!
Some pointers would be appreciated, maybe on wiki.debian.org. While
fixing it on HAProxy can be done just in debian/rules, I cannot do the
same thing for labrea. I need to patch configure and this is something
that I don't like to do.
The pattern `-L${prefix}/lib` seems to happen often. Are we going to
patch all upstream sources for this problem while this worked for years
without any problem? The `-L${prefix}/lib` is convenient because it
allows a user to install the lib in its home.
Thanks for you to point it out to me. Do you have any better idea to deal with
problem for both of these situation?
Does the bug really happens for real? Doesn't system paths used before
user-specified paths?
You can tag it as won't-fix if you'd like to.
If without multilib packages installed or install some libraries
installed manually,
this package can be built successfully.
--
Use recursive procedures for recursively-defined data structures.
- The Elements of Programming Style (Kernighan Plauger)
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722788: labrea link with -L/usr/lib
Package: labrea Version: 2.5-stable-3 X-Debbugs-CC: wzss...@gmail.com This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. On mips* systems, /usr/lib is defined as place to hold O32 libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. Beside the way, on the multiarch system like Debian, user may install libraries under /usr/lib by hand. Please use the default search path if you can, and please consider fix this. I will try to fix this bug, while if you can help to fix it, It will be very appreciative. The attachement is the buildlog of this package on mips64el platform. labrea_2.5-stable-3_mips64el.build.xz Description: Binary data
