Bug#715038: add mips64(el) mipsn32(el) support to eglibc
- To: Aurelien Jarno <aurelien@aurel32.net>
- Cc: 715038@bugs.debian.org
- Subject: Bug#715038: add mips64(el) mipsn32(el) support to eglibc
- From: Yunqiang Su <wzssyqa@gmail.com>
- Date: Thu, 5 Jun 2014 23:34:37 +0800
- Message-id: <[🔎] CAKcpw6XKfvuzOi-rGx==E6QsDj+Bi6JKQTNi8R_iqkYa11M=bw@mail.gmail.com>
- Reply-to: Yunqiang Su <wzssyqa@gmail.com>, 715038@bugs.debian.org
- In-reply-to: <CAKcpw6XJ+x2KEt9cZrgHhmHiFLZ=ehkFd5f2B3+P1jiSrn2FYQ@mail.gmail.com>
- References: <CAKcpw6UX_W1zbPkNN-qtB9ee_KvFw8JPpJiD-NO9jeEjkJNSOA@mail.gmail.com> <CAKcpw6UcW1ny9jqxi8-M+LbGX_32sP8aL_5HK21dViLPuCcT4A@mail.gmail.com> <CAKcpw6XZSH=1k2cLr64noc_=W8KoWWBaAQdKXMe4Y58ZQKKm-w@mail.gmail.com> <CAKcpw6WP78cYH=7iAEGdkvN8wWo1hGJE55g3ifyrq2=Hm5X8pA@mail.gmail.com> <20140507150230.GT5346@hall.aurel32.net> <CAKcpw6UcSO7_6+GMkeky+pGU2w6-Prxei1UgSWqJiKHCBx=5KA@mail.gmail.com> <CAKcpw6XJ+x2KEt9cZrgHhmHiFLZ=ehkFd5f2B3+P1jiSrn2FYQ@mail.gmail.com>
Hi, as I asked that guys, they insist on using /usr/lib but not /usr/libo32. :-(
Then, maybe this patch should be OK.
please consider it.
On Tue, May 20, 2014 at 4:24 AM, Yunqiang Su <wzssyqa@gmail.com> wrote:
> I refreshed this patch with 2.18-6.
>
> On Thu, May 8, 2014 at 10:53 AM, Yunqiang Su <wzssyqa@gmail.com> wrote:
>> On Wed, May 7, 2014 at 11:02 PM, Aurelien Jarno <aurelien@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 <wzssyqa@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 <wzssyqa@gmail.com> wrote:
>>>> >> I refresh this patch with 2.18-3
>>>> >>
>>>> >> On Mon, Oct 7, 2013 at 9:50 AM, YunQiang Su <wzssyqa@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
>>> aurelien@aurel32.net http://www.aurel32.net
>>
>>
>>
>> --
>> Yunqiang Su
>
>
>
> --
> Yunqiang Su
--
Yunqiang Su
Reply to: