On Mon, Jun 9, 2014 at 10:11 PM, Aurelien Jarno <aurel...@aurel32.net> wrote: > On Thu, Jun 05, 2014 at 11:34:37PM +0800, Yunqiang Su wrote: >> Hi, as I asked that guys, they insist on using /usr/lib but not /usr/libo32. >> :-( > > Who are the guys? What is the argument on using /usr/lib instead of > /usr/libo32?
https://lists.debian.org/debian-mips/2013/06/msg00006.html > >> Then, maybe this patch should be OK. > > I don't think it is ok. I don't feel comfortable in using the same > directory for the system and biarch libraries. It means we won't be able > to search among 64-bit libraries without looking at o32 libraries. > >> please consider it. > > What I propose is to merge all the non-biarch stuff, as a first step. > Actually it might be already enough as o32 libraries can already be > installed using multiarch. > Then let's drop multilib support from eglibc? > >> On Tue, May 20, 2014 at 4:24 AM, Yunqiang Su <wzss...@gmail.com> wrote: >> > I refreshed this patch with 2.18-6. >> > >> > On Thu, May 8, 2014 at 10:53 AM, Yunqiang Su <wzss...@gmail.com> wrote: >> >> On Wed, May 7, 2014 at 11:02 PM, Aurelien Jarno <aurel...@aurel32.net> >> >> wrote: >> >>> On Fri, Apr 25, 2014 at 10:25:55PM +0800, Yunqiang Su wrote: >> >>>> On Fri, Apr 25, 2014 at 10:25 PM, Yunqiang Su <wzss...@gmail.com> wrote: >> >>>> > I refresh this patch with 2.18-4, and >> >>>> > >> >>>> > let libc6 breaks: >> >>>> > >> >>>> > libc6-mips64 [mips64 mips64el], >> >>>> > libc6-mipsn32 [mipsn32 mipsn32el], >> >>>> > libc6-mips32 [mips mipsel], >> >>>> > >> >>>> > >> >>>> > On Thu, Feb 27, 2014 at 9:20 AM, Yunqiang Su <wzss...@gmail.com> >> >>>> > wrote: >> >>>> >> I refresh this patch with 2.18-3 >> >>>> >> >> >>>> >> On Mon, Oct 7, 2013 at 9:50 AM, YunQiang Su <wzss...@gmail.com> >> >>>> >> wrote: >> >>>> >>> I refresh the patches with 2.17-93. >> >>>> >>> It's time to consider to merge it. >> >>>> >>> >> >>>> >>> Now we have about 7000 packages build successfully already. >> >>>> >>> This architecture may be in debian-ports in near future. >> >>> >> >>> Please find my comments about this patch below. >> >>> >> >>>> [ snip ] >> >>> >> >>>> diff -urN a/debian/rules.d/build.mk b/debian/rules.d/build.mk >> >>>> --- a/debian/rules.d/build.mk 2014-03-02 15:01:31.000000000 +0000 >> >>>> +++ b/debian/rules.d/build.mk 2014-04-25 14:14:27.708058521 +0000 >> >>>> @@ -233,7 +233,7 @@ >> >>>> # the multiarch ld.so doesn't look at the (non-standard) /lib32, >> >>>> so we >> >>>> # need path compatibility when biarch and multiarch packages are >> >>>> both >> >>>> # installed. >> >>>> - case $(call xx,slibdir) in /lib32 | /lib64 | /libx32) \ >> >>>> + case $(call xx,slibdir) in /lib32 | /lib64 | /libx32 | /lib) \ >> >>>> mkdir -p debian/tmp-$(curpass)/etc/ld.so.conf.d; \ >> >>>> >> >>>> conffile="debian/tmp-$(curpass)/etc/ld.so.conf.d/zz_$(curpass)-biarch-compat.conf"; >> >>>> \ >> >>>> echo "# Legacy biarch compatibility support" > $$conffile; \ >> >>> >> >>> Why do you need this change? This will create a ld.so.conf entry even >> >>> for /lib, while ld.so should always be configured to look for /lib and >> >>> /lib/$(DEB_HOST_ARCH_MULTIARCH) without even an ld.so.conf entry. >> >>> Moreover, with this change such a file would be created for all >> >>> architectures, not only mips64. >> >>> >> >>> Please look why ld.so doesn't look to /lib by default. >> >> >> >> It looks /lib. I dropped this snip. >> >> >> >>> >> >>>> diff -urN a/debian/rules.d/build.mk.orig b/debian/rules.d/build.mk.orig >> >>>> --- a/debian/rules.d/build.mk.orig 1970-01-01 00:00:00.000000000 >> >>>> +0000 >> >>>> +++ b/debian/rules.d/build.mk.orig 2014-04-25 14:14:27.708058521 >> >>>> +0000 >> >>> >> >>>> [ snip ] >> >>> >> >>> Please don't include such an orig file in your patch. >> >>> >> >>>> [ snip ] >> >>> >> >>>> diff -urN a/debian/rules.d/control.mk.orig >> >>>> b/debian/rules.d/control.mk.orig >> >>>> --- a/debian/rules.d/control.mk.orig 1970-01-01 00:00:00.000000000 >> >>>> +0000 >> >>>> +++ b/debian/rules.d/control.mk.orig 2014-04-25 14:14:27.708058521 >> >>>> +0000 >> >>> >> >>> Same here >> >>> >> >>>> [ snip ] >> >>> >> >>>> diff -urN a/debian/rules.d/debhelper.mk b/debian/rules.d/debhelper.mk >> >>>> --- a/debian/rules.d/debhelper.mk 2014-03-02 15:01:31.000000000 >> >>>> +0000 >> >>>> +++ b/debian/rules.d/debhelper.mk 2014-04-25 14:14:27.708058521 >> >>>> +0000 >> >>>> @@ -223,7 +223,7 @@ >> >>>> pass="" \ >> >>>> suffix="" \ >> >>>> ;; \ >> >>>> - *:/lib32 | *:/lib64 | *:/libx32 | *:/lib/arm-linux-gnueabi*) \ >> >>>> + *:/lib32 | *:/lib64 | *:/libx32 | *:/lib | >> >>>> *:/lib/arm-linux-gnueabi*) \ >> >>> >> >>> I guess it's because the multilib o32 version is installed in /lib, >> >>> right? But see below. >> >>> >> >> >> >> Yes >> >> >> >>> >> >>>> templates="libc libc-dev" \ >> >>>> pass="-alt" \ >> >>>> suffix="-$(curpass)" \ >> >>>> @@ -240,6 +240,9 @@ >> >>>> if [ "$$s" != "$$t" ] ; then \ >> >>>> cp $$s $$t ; \ >> >>>> fi ; \ >> >>>> + if [ "$$suffix" = "-mips32" ] ; then \ >> >>>> + sed -e '/ld.so.conf.d /etc/d' -i $$t; \ >> >>>> + fi ; \ >> >>> >> >>> What is that supposed to do? >> >> >> >> This is used to avoid installing zz_mips32-biarch-compat.conf >> >> for /lib and /usr/lib . >> >> >> >> $$t is debian/libc6-mips32.install here. >> >> >> >>> >> >>>> sed -e "s#TMPDIR#debian/tmp-$$curpass#g" -i $$t; \ >> >>>> sed -e "s#RTLDDIR#$$rtlddir#g" -i $$t; \ >> >>>> sed -e "s#SLIBDIR#$$slibdir#g" -i $$t; \ >> >>> >> >>> >> >>>> [ snip ] >> >>> >> >>>> diff -urN a/debian/sysdeps/mips64el.mk b/debian/sysdeps/mips64el.mk >> >>>> --- a/debian/sysdeps/mips64el.mk 1970-01-01 00:00:00.000000000 >> >>>> +0000 >> >>>> +++ b/debian/sysdeps/mips64el.mk 2014-04-25 14:14:27.712058556 >> >>>> +0000 >> >>>> @@ -0,0 +1,54 @@ >> >>>> +libc_add-ons = ports nptl $(add-ons) >> >>>> +libc_rtlddir = /lib64 >> >>>> + >> >>>> +# build 32-bit (n32) alternative library >> >>>> +EGLIBC_PASSES += mipsn32 >> >>>> +DEB_ARCH_REGULAR_PACKAGES += libc6-mipsn32 libc6-dev-mipsn32 >> >>>> +mipsn32_add-ons = ports nptl $(add-ons) >> >>>> +mipsn32_configure_target = mips64el-linux-gnuabin32 >> >>>> +mipsn32_CC = $(CC) -mabi=n32 -mno-plt >> >>>> +mipsn32_CXX = $(CXX) -mabi=n32 -mno-plt >> >>>> +libc6-mipsn32_shlib_dep = libc6-mipsn32 (>= $(shlib_dep_ver)) >> >>>> +mipsn32_rtlddir = /lib32 >> >>>> +mipsn32_slibdir = /lib32 >> >>>> +mipsn32_libdir = /usr/lib32 >> >>>> +mipsn32_extra_config_options := $(extra_config_options) >> >>>> --disable-profile >> >>>> + >> >>>> +# build 32-bit (o32) alternative library >> >>>> +EGLIBC_PASSES += mips32 >> >>>> +DEB_ARCH_REGULAR_PACKAGES += libc6-mips32 libc6-dev-mips32 >> >>>> +mips32_add-ons = ports nptl $(add-ons) >> >>>> +mips32_configure_target = mipsel-linux-gnu >> >>>> +mips32_CC = $(CC) -mabi=32 -mno-plt >> >>>> +mips32_CXX = $(CXX) -mabi=32 -mno-plt >> >>>> +libc6-mips32_shlib_dep = libc6-mips32 (>= $(shlib_dep_ver)) >> >>>> +mips32_rtlddir = /lib >> >>>> +mips32_slibdir = /lib >> >>>> +mips32_libdir = /usr/lib >> >>> >> >>> For what I understand there, the o32 library is installed in /lib, which >> >>> might conflict with the system libraries on some aspects. Wouldn't it be >> >>> better to install it in for example in /libo32 instead? Of course >> >>> rtlddir would stay in /lib to be conform with the ABI. >> >> >> >> I agree with you about this, while some guys think install to /lib is >> >> required. >> >> https://lists.debian.org/debian-mips/2013/06/msg00006.html >> >> >> >> Let's try to explain to them again? >> >> >> >>> >> >>> Note that it is only for the multilib packages, so basically the >> >>> toolchain (libc + compiler). mips o32 multiarch packages will of course >> >>> be installed in /usr/lib/mips-linux-gnu. >> >>> >> >>> The same is also the case for the other mipsn32/mips64 .mk files. >> >>> >> >>> -- >> >>> Aurelien Jarno GPG: 4096R/1DDD8C9B >> >>> aurel...@aurel32.net http://www.aurel32.net >> >> >> >> >> >> >> >> -- >> >> Yunqiang Su >> > >> > >> > >> > -- >> > Yunqiang Su >> >> >> >> -- >> Yunqiang Su >> > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
