brltty: use gcc instead of ld to link shared objects
PATCH v2 1/1 brltty: use gcc instead of ld to link shared objects
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 MKREL to use "gcc -shared -o" instead of "ld -r -o".
Fixes:
- http://autobuild.buildroot.org/results/31f682838b3d3b2c7103b5c51f2aba0b89d4f630
---
Changes v1 -> v2:
- Fix patch (missing -o)
package/brltty/brltty.mk | 3 +++ 1 file changed, 3 insertions(+)
package/brltty/brltty.mk +3 -0
@@ -15,6 +15,9 @@ BRLTTY_LICENSE_FILES = LICENSE-LGPL README BRLTTY_DEPENDENCIES = $(TARGET_NLS_DEPENDENCIES) host-autoconf host-pkgconf \ $(if $(BR2_PACKAGE_AT_SPI2_CORE),at-spi2-core) +BRLTTY_CONF_ENV = \ + brltty_cv_prog_make_object_relocatable="$(TARGET_CC) -shared -o" + BRLTTY_CONF_OPTS = \ --disable-java-bindings \ --disable-lisp-bindings \
Signature · 1 line
2.17.1
PATCH v2 1/1 brltty: use gcc instead of ld to link shared objects
Hello,
Quoted 9 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 MKREL to use "gcc -shared -o" instead of "ld -r -o".
Are you really sure gcc -shared -o does the same thing as ld -r -o ?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
PATCH v2 1/1 brltty: use gcc instead of ld to link shared objects
Dear Thomas,
Le jeu. 20 sept. 2018 ? 21:01, Thomas Petazzoni <
[email protected]> a ?crit :
Quoted 8 lines
Hello,
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 8 lines
https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416
Quoted 4 lines
Moreover, since commit
3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ was renamed into MKREL. So, instead of patching again brltty, overwrite MKREL to use "gcc -shared -o" instead of "ld -r -o".Are you really sure gcc -shared -o does the same thing as ld -r -o ?
I didn't think about it, I basically backported the behavior of third patch (upstream commit 4c8aba42e246b96d10ffcbd57653682375499e46). The third patch applied to brltty 5.5 (https://patchwork.ozlabs.org/patch/854093/) was replacing MKOBJ ($(LD) -r -o) by MKMOD defined as (CC) ${brltty_mkmod_gcc_make=-shared} BRLTTY_OPTIONS_LD2CC([${brltty_mkmod_ld_options}]) -o" with brltty_mkmod_ld_make="-shared" on linux (see
https://github.com/brltty/brltty/blob/4c8aba42e246b96d10ffcbd57653682375499e46/configure.ac
).
More information can be found here:
https://github.com/brltty/brltty/pull/113
However, I don't know why this commit was reverted one week later. Mario, you told us in the review of the first patch that the upstream author decided to "fix" the issue in a different way but actually the issue is not fixed. Do you know why this commit was reverted? If needed, I can create an issue to get more info.
Quoted 6 lines
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Best Regards,
Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180920/86bb4c11/attachment.html>
PATCH v2 1/1 brltty: use gcc instead of ld to link shared objects
Quoted 20 lines · Fabrice Fontaine
Dear Thomas,
Le jeu. 20 sept. 2018 ? 21:01, Thomas Petazzoni <
thomas.petazzoni at bootlin.com> a ?crit :Quoted 15 lines
Hello,
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 4 lines
Moreover, since commit
3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ was renamed into MKREL. So, instead of patching again brltty, overwrite MKREL to use "gcc -shared -o" instead of "ld -r -o".Are you really sure gcc -shared -o does the same thing as ld -r -o ?
ld fails to link on mipsel at least. What else should we do? "ABI is incompatible with that of the selected emulation" "Attempt to do relocatable link with elf64-tradlittlemips input and elf32-ntradlittlemips output"
Hmm, maybe this is a HOST/TARGET mixup? But how?
Quoted 8 lines
I didn't think about it, I basically backported the behavior of third patch (upstream commit
4c8aba42e246b96d10ffcbd57653682375499e46). The third patch applied to brltty 5.5 (https://patchwork.ozlabs.org/patch/854093/) was replacing MKOBJ ($(LD) -r -o) by MKMOD defined as (CC) ${brltty_mkmod_gcc_make=-shared}BRLTTY_OPTIONS_LD2CC([${brltty_mkmod_ld_options}])-o" with brltty_mkmod_ld_make="-shared" on linux (see
https://github.com/brltty/brltty/blob/4c8aba42e246b96d10ffcbd57653682375499e46/configure.ac
Quoted 8 lines
).
More information can be found here:
https://github.com/brltty/brltty/pull/113
However, I don't know why this commit was reverted one week later. Mario, you told us in the review of the first patch that the upstream author decided to "fix" the issue in a different way but actually the issue is not fixed. Do you know why this commit was reverted? If needed, I can create an issue to get more info.
It was reverted because it failed to build on Mac OS X, and Mac OS X was deemed more important then cross-compiling on Linux.
Upstream (dave at mielke.cc) is very responsive, maybe you have more luck trying to work this one out with him?
Signature · 2 lines
CYa, ?????
PATCH v2 1/1 brltty: use gcc instead of ld to link shared objects
Dear Mario, Thomas,
Le ven. 21 sept. 2018 ? 08:34, Mario Lang <[email protected]> a ?crit :
Quoted 22 lines
Quoted 9 lines · Fabrice Fontaine
Dear Thomas,
Le jeu. 20 sept. 2018 ? 21:01, Thomas Petazzoni <
thomas.petazzoni at bootlin.com> a ?crit :Quoted 4 lines
Hello,
Quoted 1 line · Fabrice Fontaine
Bump to version 5.6 has reintroduced the issue fixed by patch 854093
on
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
version 5.5.
Indeed, third patch was merged upstream but it was then reverted:
https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Moreover, since commit
3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ was renamed into MKREL. So, instead of patching again brltty,overwrite
Quoted 9 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
MKREL to use "gcc -shared -o" instead of "ld -r -o".
Are you really sure gcc -shared -o does the same thing as ld -r -o ?
ld fails to link on mipsel at least. What else should we do? "ABI is incompatible with that of the selected emulation" "Attempt to do relocatable link with elf64-tradlittlemips input and elf32-ntradlittlemips output"
After more investigations, it seems that this issue is raised only on mips64el (at least on autobuilders:
http://autobuild.buildroot.org/?reason=brltty-5.6).
On this target, by default, ld wants to link a 32 bits binary (I don't know why).
This issue can be fixed by setting LD="$(TARGET_LD) -melf64ltsmip". However, I don't know if this a better solution, it seems like a workaround to a toolchain issue.
Quoted 27 lines
Hmm, maybe this is a HOST/TARGET mixup? But how?
Quoted 1 line
I didn't think about it, I basically backported the behavior of third
patch
Quoted 1 line
(upstream commit
4c8aba42e246b96d10ffcbd57653682375499e46). The thirdpatch
Quoted 6 lines
applied to brltty 5.5 (https://patchwork.ozlabs.org/patch/854093/) was replacing MKOBJ ($(LD) -r -o) by MKMOD defined as (CC) ${brltty_mkmod_gcc_make=-shared}
BRLTTY_OPTIONS_LD2CC([${brltty_mkmod_ld_options}])-o" with brltty_mkmod_ld_make="-shared" on linux (seehttps://github.com/brltty/brltty/blob/4c8aba42e246b96d10ffcbd57653682375499e46/configure.ac
Quoted 6 lines
).
More information can be found here:
https://github.com/brltty/brltty/pull/113
However, I don't know why this commit was reverted one week later. Mario, you told us in the review of the first patch that the upstream author decided to "fix" the issue in a different way but actually theissue
Quoted 2 lines
is not fixed. Do you know why this commit was reverted? If needed, I can create an issue to get more info.
It was reverted because it failed to build on Mac OS X, and Mac OS X was deemed more important then cross-compiling on Linux.
Quoted 7 lines
Upstream (dave at mielke.cc) is very responsive, maybe you have more luck trying to work this one out with him?
--
CYa,
?????
Best Regards,
Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180927/2d68f9a5/attachment.html>
PATCH v2 1/1 brltty: use gcc instead of ld to link shared objects
Quoted 20 lines · Fabrice Fontaine
Dear Mario, Thomas,
Le?ven. 21 sept. 2018 ??08:34, Mario Lang <[email protected]> a ?crit?:
Fabrice Fontaine <[email protected] <mailto:[email protected]>> writes: > Dear Thomas, > > Le jeu. 20 sept. 2018 ? 21:01, Thomas Petazzoni < > thomas.petazzoni at bootlin.com <mailto:[email protected]>> a ?crit : > >> Hello, >> >> On Thu, 20 Sep 2018 19:28:09 +0200, Fabrice Fontaine wrote: >> > 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 8 lines
>>
https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416
>> >
>> > Moreover, since commit 3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ
>> > was renamed into MKREL. So, instead of patching again brltty, overwrite
>> > MKREL to use "gcc -shared -o" instead of "ld -r -o".
>>
>> Are you really sure gcc -shared -o does the same thing as ld -r -o ? I'm a bit confused... ld -r creates a relocatable object file (partial
linking), while ld -shared creates a shared library. According to the gcc man page, gcc -shared to create a relocatable object file as well, i.e. they are equivalent. However, in the spec file, I see that -shared is just passed to the linker as -shared, not as -r...
Quoted 11 lines
ld fails to link on mipsel at least.? What else should we do? "ABI is incompatible with that of the selected emulation" "Attempt to do relocatable link with elf64-tradlittlemips input and elf32-ntradlittlemips output"
After more investigations, it seems that this issue is raised only on mips64el (at least on autobuilders: http://autobuild.buildroot.org/?reason=brltty-5.6).
On this target, by default, ld wants to link a 32 bits binary (I don't know why). This issue can be fixed by setting LD="$(TARGET_LD) -melf64ltsmip". However, I don't know if this a better solution, it seems like a workaround to a toolchain issue.
In general, it is possible that additional options have to be passed to ld to
make sure it creates the correct type of ELF file. The toolchain-wrapper makes sure that the correct options are passed. Calling ld directly bypasses those.
Quoted 20 lines
Hmm, maybe this is a HOST/TARGET mixup?? But how?
> I didn't think about it, I basically backported the behavior of third patch > (upstream commit
4c8aba42e246b96d10ffcbd57653682375499e46). The third patch > applied to brltty 5.5 (https://patchwork.ozlabs.org/patch/854093/) was > replacing MKOBJ ($(LD) -r -o) by MKMOD defined as (CC)
> ${brltty_mkmod_gcc_make=-shared}
>BRLTTY_OPTIONS_LD2CC([${brltty_mkmod_ld_options}])-o" with
> brltty_mkmod_ld_make="-shared" on linux (see
>
https://github.com/brltty/brltty/blob/4c8aba42e246b96d10ffcbd57653682375499e46/configure.ac
> ).
> More information can be found here:
> https://github.com/brltty/brltty/pull/113
> However, I don't know why this commit was reverted one week later. > Mario, you told us in the review of the first patch that the upstream > author decided to "fix" the issue in a different way but actually the issue > is not fixed. Do you know why this commit was reverted? If needed, I can > create an issue to get more info.
Quoted 2 lines
It was reverted because it failed to build on Mac OS X, and Mac OS X was deemed more important then cross-compiling on Linux.
What might work is to add a condition for MKREL like already exists for MKSHR:
if test "${GCC}" = "yes"
then
brltty_cv_prog_make_object_relocatable="\$(CC) -shared -o"
else
brltty_cv_prog_make_object_relocatable="\$(LD) -r -o"
fi Regards,
Arnout
Quoted 17 lines
Upstream (dave at mielke.cc) is very responsive, maybe you have more luck trying to work this one out with him?
--
CYa,
? ?????Best Regards,
Fabrice
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
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