tags 722822 = wontfix thanks Upstream looked at this pointed out at the -L/usr/lib options are coming not from their build infrastructure, but from the helper scripts. For example:
roberto@miami:~/tmp$ xml2-config --libs -L/usr/lib -lxml2 So the candidate cuplrits include xml2-config, python2.7-config, pg_config, and perhaps others. Since I am not sure that the problem really is with those utilities either (it may be a lower level issue with the architecture), I am not going to clone/reassign this bug. Rather, I am tagging it as wontfix for the time being. Regards, -Roberto On Sat, Sep 14, 2013 at 11:32:36AM +0800, YunQiang Su wrote: > Package: quickfix > Version: 1.13.3+dfsg-6 > 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. -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
signature.asc
Description: Digital signature
