| Message ID | 20180920172809.19993-1-fontaine.fabrice@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,1/1] brltty: use gcc instead of ld to link shared objects | expand |
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: > 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 ? Thomas
Dear Thomas, Le jeu. 20 sept. 2018 à 21:01, Thomas Petazzoni < thomas.petazzoni@bootlin.com> 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: > > > 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 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. > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Best Regards, Fabrice <div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Dear Thomas,<br><br><div class="gmail_quote"><div dir="ltr">Le jeu. 20 sept. 2018 à 21:01, Thomas Petazzoni <<a href="mailto:thomas.petazzoni@bootlin.com">thomas.petazzoni@bootlin.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br> <br> On Thu, 20 Sep 2018 19:28:09 +0200, Fabrice Fontaine wrote:<br> > Bump to version 5.6 has reintroduced the issue fixed by patch 854093 on<br> > version 5.5.<br> > <br> > Indeed, third patch was merged upstream but it was then reverted:<br> > <a href="https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416" rel="noreferrer" target="_blank">https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416</a><br> > <br> > Moreover, since commit 3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ<br> > was renamed into MKREL. So, instead of patching again brltty, overwrite<br> > MKREL to use "gcc -shared -o" instead of "ld -r -o".<br> <br> Are you really sure gcc -shared -o does the same thing as ld -r -o ?<br></blockquote><div>I didn't think about it, I basically backported the behavior of third patch (upstream commit <span class="gmail-sha-block"><span class="gmail-sha gmail-user-select-contain">4c8aba42e246b96d10ffcbd57653682375499e46)</span></span>. The third patch applied to brltty 5.5 (<a href="https://patchwork.ozlabs.org/patch/854093/">https://patchwork.ozlabs.org/patch/854093/</a>) was replacing MKOBJ (<span class="gmail-blob-code-inner gmail-blob-code-marker-deletion">$(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 <a href="https://github.com/brltty/brltty/blob/4c8aba42e246b96d10ffcbd57653682375499e46/configure.ac">https://github.com/brltty/brltty/blob/4c8aba42e246b96d10ffcbd57653682375499e46/configure.ac</a>).</span></div><div><span class="gmail-blob-code-inner gmail-blob-code-marker-deletion">More information can be found here: <a href="https://github.com/brltty/brltty/pull/113">https://github.com/brltty/brltty/pull/113</a><br></span></div><div><span class="gmail-blob-code-inner gmail-blob-code-marker-deletion">However, I don't know why this commit was reverted one week later.<br></span></div><div><span class="gmail-blob-code-inner gmail-blob-code-marker-deletion">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.<br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Thomas<br> -- <br> Thomas Petazzoni, CTO, Bootlin<br> Embedded Linux and Kernel engineering<br> <a href="https://bootlin.com" rel="noreferrer" target="_blank">https://bootlin.com</a></blockquote><div></div><div>Best Regards,</div><div><br></div><div>Fabrice<br></div></div></div></div></div></div>
Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: > Dear Thomas, > > Le jeu. 20 sept. 2018 à 21:01, Thomas Petazzoni < > thomas.petazzoni@bootlin.com> 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: >> > >> 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 ? 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? > 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. 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@mielke.cc) is very responsive, maybe you have more luck trying to work this one out with him?
Dear Mario, Thomas, Le ven. 21 sept. 2018 à 08:34, Mario Lang <mlang@blind.guru> a écrit : > Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: > > > Dear Thomas, > > > > Le jeu. 20 sept. 2018 à 21:01, Thomas Petazzoni < > > thomas.petazzoni@bootlin.com> 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: > >> > > >> > 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 ? > > 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. > > 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. > > 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@mielke.cc) is very responsive, maybe you have more luck > trying to work this one out with him? > > -- > CYa, > ⡍⠁⠗⠊⠕ > Best Regards, Fabrice <div dir="ltr"><div dir="ltr"><div dir="ltr">Dear Mario, Thomas,<br><br><div class="gmail_quote"><div dir="ltr">Le ven. 21 sept. 2018 à 08:34, Mario Lang <mlang@blind.guru> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Fabrice Fontaine <<a href="mailto:fontaine.fabrice@gmail.com" target="_blank">fontaine.fabrice@gmail.com</a>> writes:<br> <br> > Dear Thomas,<br> ><br> > Le jeu. 20 sept. 2018 à 21:01, Thomas Petazzoni <<br> > <a href="mailto:thomas.petazzoni@bootlin.com" target="_blank">thomas.petazzoni@bootlin.com</a>> a écrit :<br> ><br> >> Hello,<br> >><br> >> On Thu, 20 Sep 2018 19:28:09 +0200, Fabrice Fontaine wrote:<br> >> > Bump to version 5.6 has reintroduced the issue fixed by patch 854093 on<br> >> > version 5.5.<br> >> ><br> >> > Indeed, third patch was merged upstream but it was then reverted:<br> >> ><br> >> <a href="https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416" rel="noreferrer" target="_blank">https://github.com/brltty/brltty/commit/9e7d62c869d3c1cbe12dda8b0291a4692c193416</a><br> >> ><br> >> > Moreover, since commit 3a2e3f6fa5ef0a210ffeba5ed05c79965d0cc3c7, MKOBJ<br> >> > was renamed into MKREL. So, instead of patching again brltty, overwrite<br> >> > MKREL to use "gcc -shared -o" instead of "ld -r -o".<br> >><br> >> Are you really sure gcc -shared -o does the same thing as ld -r -o ?<br> <br> ld fails to link on mipsel at least. What else should we do?<br> "ABI is incompatible with that of the selected emulation"<br> "Attempt to do relocatable link with elf64-tradlittlemips input and<br> elf32-ntradlittlemips output"<br></blockquote><div>After more investigations, it seems that this issue is raised only on mips64el (at least on autobuilders: <a href="http://autobuild.buildroot.org/?reason=brltty-5.6">http://autobuild.buildroot.org/?reason=brltty-5.6</a>).</div><div>On this target, by default, ld wants to link a 32 bits binary (I don't know why).</div><div>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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Hmm, maybe this is a HOST/TARGET mixup? But how?<br> <br> > I didn't think about it, I basically backported the behavior of third patch<br> > (upstream commit 4c8aba42e246b96d10ffcbd57653682375499e46). The third patch<br> > applied to brltty 5.5 (<a href="https://patchwork.ozlabs.org/patch/854093/" rel="noreferrer" target="_blank">https://patchwork.ozlabs.org/patch/854093/</a>) was<br> > replacing MKOBJ ($(LD) -r -o) by MKMOD defined as (CC)<br> > ${brltty_mkmod_gcc_make=-shared}<br> > BRLTTY_OPTIONS_LD2CC([${brltty_mkmod_ld_options}]) -o" with<br> > brltty_mkmod_ld_make="-shared" on linux (see<br> > <a href="https://github.com/brltty/brltty/blob/4c8aba42e246b96d10ffcbd57653682375499e46/configure.ac" rel="noreferrer" target="_blank">https://github.com/brltty/brltty/blob/4c8aba42e246b96d10ffcbd57653682375499e46/configure.ac</a><br> > ).<br> > More information can be found here:<br> > <a href="https://github.com/brltty/brltty/pull/113" rel="noreferrer" target="_blank">https://github.com/brltty/brltty/pull/113</a><br> > However, I don't know why this commit was reverted one week later.<br> > Mario, you told us in the review of the first patch that the upstream<br> > author decided to "fix" the issue in a different way but actually the issue<br> > is not fixed. Do you know why this commit was reverted? If needed, I can<br> > create an issue to get more info.<br> <br> It was reverted because it failed to build on Mac OS X, and Mac OS X was<br> deemed more important then cross-compiling on Linux.<br> <br> Upstream (dave@mielke.cc) is very responsive, maybe you have more luck<br> trying to work this one out with him?<br> <br> -- <br> CYa,<br> ⡍⠁⠗⠊⠕<br></blockquote><div>Best Regards,</div><div><br></div><div>Fabrice<br></div></div></div></div></div>
On 27/09/2018 23:55, Fabrice Fontaine wrote: > Dear Mario, Thomas, > > Le ven. 21 sept. 2018 à 08:34, Mario Lang <mlang@blind.guru> a écrit : > > Fabrice Fontaine <fontaine.fabrice@gmail.com > <mailto:fontaine.fabrice@gmail.com>> writes: > > > Dear Thomas, > > > > Le jeu. 20 sept. 2018 à 21:01, Thomas Petazzoni < > > thomas.petazzoni@bootlin.com <mailto:thomas.petazzoni@bootlin.com>> 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: > >> > > >> > 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... > 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. > 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. > > 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 > > Upstream (dave@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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot >
diff --git a/package/brltty/brltty.mk b/package/brltty/brltty.mk index 21f6877bb8..615950800d 100644 --- a/package/brltty/brltty.mk +++ b/package/brltty/brltty.mk @@ -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 \
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 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> --- Changes v1 -> v2: - Fix patch (missing -o) package/brltty/brltty.mk | 3 +++ 1 file changed, 3 insertions(+)