brltty: fix build on mips64el
PATCH 1/1 brltty: fix build on mips64el
Bump to version 5.6 has reintroduced the issue fixed by patch 854093 on version 5.5.
Indeed, third patch was merged upstream but it was then reverted:
https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416
Moreover, since commit 3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ
was renamed into MKREL. So, instead of patching again brltty, overwrite
LD to set the correct emulation depending on MIPS architecture as
already done in linux-tool-perf.mk.in.
Indeed, it seems that by default ld wants to link a 32 bits binary on
mips64el:
mips64el-linux-ld: Attempt to do relocatable link with elf64-tradlittlemips input and elf32-ntradlittlemips output
Fixes:
- http://autobuild.buildroot.org/results/31f682838b3d3b2c7103b5c51f2aba0b89d4f630
--- package/brltty/brltty.mk | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
package/brltty/brltty.mk +21 -0
@@ -15,6 +15,27 @@ BRLTTY_LICENSE_FILES = LICENSE-LGPL README BRLTTY_DEPENDENCIES = $(TARGET_NLS_DEPENDENCIES) host-autoconf host-pkgconf \ $(if $(BR2_PACKAGE_AT_SPI2_CORE),at-spi2-core) +# We need to pass an argument to ld for setting the emulation when +# building for MIPS architecture, otherwise the default one will always +# be used and the compilation for most variants will fail. +ifeq ($(BR2_mips),y) +BRLTTY_CONF_ENV += LD="$(TARGET_LD) -m elf32btsmip" +else ifeq ($(BR2_mipsel),y) +BRLTTY_CONF_ENV += LD="$(TARGET_LD) -m elf32ltsmip" +else ifeq ($(BR2_mips64),y) +ifeq ($(BR2_MIPS_NABI32),y) +BRLTTY_CONF_ENV += LD="$(TARGET_LD) -m elf32btsmipn32" +else +BRLTTY_CONF_ENV += LD="$(TARGET_LD) -m elf64btsmip" +endif +else ifeq ($(BR2_mips64el),y) +ifeq ($(BR2_MIPS_NABI32),y) +BRLTTY_CONF_ENV += LD="$(TARGET_LD) -m elf32ltsmipn32" +else +BRLTTY_CONF_ENV += LD="$(TARGET_LD) -m elf64ltsmip" +endif +endif + BRLTTY_CONF_OPTS = \ --disable-java-bindings \ --disable-lisp-bindings \
Signature · 1 line
2.17.1
PATCH 1/1 brltty: fix build on mips64el
Hi.
Quoted 10 lines · Fabrice Fontaine
Bump to version 5.6 has reintroduced the issue fixed by patch 854093 on version 5.5.
Indeed, third patch was merged upstream but it was then reverted:
https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416Moreover, since commit
3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ was renamed into MKREL. So, instead of patching again brltty, overwrite LD to set the correct emulation depending on MIPS architecture as already done in linux-tool-perf.mk.in.
Thanks Fabrice. ack and +1.
Signature · 2 lines
CYa, ?????
PATCH 1/1 brltty: fix build on mips64el
Dear Mario,
Le lun. 8 oct. 2018 ? 10:18, Mario Lang <[email protected]> a ?crit :
Quoted 9 lines
Hi.
Quoted 5 lines · Fabrice Fontaine
Bump to version 5.6 has reintroduced the issue fixed by patch 854093 on version 5.5.
Indeed, third patch was merged upstream but it was then reverted:
Quoted 9 lines
https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416
Quoted 5 lines
Moreover, since commit
3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ was renamed into MKREL. So, instead of patching again brltty, overwrite LD to set the correct emulation depending on MIPS architecture as already done in linux-tool-perf.mk.in.Thanks Fabrice. ack and +1.
Thanks for your review, however after the feedback from Arnout on first patch iteration (https://patchwork.ozlabs.org/patch/972614/), I've also sent a PR to brltty: https://github.com/brltty/brltty/pull/149.
Both solutions seems good to me.
Quoted 5 lines
--
CYa,
?????
Best Regards,
Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20181008/951e0d27/attachment.html>
PATCH 1/1 brltty: fix build on mips64el
Quoted 19 lines · Fabrice Fontaine
Dear Mario,
Le lun. 8 oct. 2018 ? 10:18, Mario Lang <[email protected]> a ?crit :Quoted 16 lines
Hi.
Quoted 5 lines · Fabrice Fontaine
Bump to version 5.6 has reintroduced the issue fixed by patch 854093 on version 5.5.
Indeed, third patch was merged upstream but it was then reverted:
https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416
Quoted 5 lines
Moreover, since commit
3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ was renamed into MKREL. So, instead of patching again brltty, overwrite LD to set the correct emulation depending on MIPS architecture as already done in linux-tool-perf.mk.in.
Quoted 6 lines
Quoted 2 lines
Thanks Fabrice. ack and +1.
Thanks for your review, however after the feedback from Arnout on first patch iteration (https://patchwork.ozlabs.org/patch/972614/), I've also sent a PR to brltty: https://github.com/brltty/brltty/pull/149.
Both solutions seems good to me.
As I have mentioned previously in this thread, switching to GCC unconditionally break compilation on OS X.
So PR 149 is likely not to be accepted.
IMO, the right way forward is to commit your patch to buildroot, as it fixes a problem specific to mips.
Signature · 2 lines
CYa, ?????
PATCH 1/1 brltty: fix build on mips64el
Quoted 21 lines · Mario Lang
Quoted 19 lines · Fabrice Fontaine
Dear Mario,
Le lun. 8 oct. 2018 ? 10:18, Mario Lang <[email protected]> a ?crit :Quoted 16 lines
Hi.
Quoted 5 lines · Fabrice Fontaine
Bump to version 5.6 has reintroduced the issue fixed by patch 854093 on version 5.5.
Indeed, third patch was merged upstream but it was then reverted:
https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416
Quoted 5 lines
Moreover, since commit
3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ was renamed into MKREL. So, instead of patching again brltty, overwrite LD to set the correct emulation depending on MIPS architecture as already done in linux-tool-perf.mk.in.
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
Thanks Fabrice. ack and +1.
Thanks for your review, however after the feedback from Arnout on first patch iteration (https://patchwork.ozlabs.org/patch/972614/),
That was actually the second iteration (and this patch is the third iteration,
but I replied to the second iteration a week after you already posted the third iteration...)
Quoted 7 lines
Quoted 3 lines
I've also
sent a PR to brltty: https://github.com/brltty/brltty/pull/149.
Both solutions seems good to me.As I have mentioned previously in this thread, switching to GCC unconditionally break compilation on OS X.
So PR 149 is likely not to be accepted.
No, Fabrice's patch is different from the one that was reverted: it will only
use the compiler with the -shared option if the compiler is GCC. Where it breaks on MacOS is when you try to call the non-GCC compiler with the -shared option.
PR 149 looks good to me. Since upstream is not terribly reactive, Fabrice,
could you generate the appropriate Buildroot patch based on that PR?
Regards,
Arnout
Quoted 3 lines
IMO, the right way forward is to commit your patch to buildroot, as it fixes a problem specific to mips.
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF