| Message ID | 20180416065014.29385-3-raj.khem@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/4] libssp-nonshared: Add recipe | expand |
This is, I suspect, the cause of nativesdk-perl failing on the autobuilder: TOPDIR/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-perl/5.24.1-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/../../libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/7.3.0/ld: cannot find -lssp_nonshared TOPDIR/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-perl/5.24.1-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/../../libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/7.3.0/ld: cannot find -lssp collect2: error: ld returned 1 exit status makefile:391: recipe for target 'lib/buildcustomize.pl' failed http://errors.yoctoproject.org/Errors/Details/176127/ Ross On 16 April 2018 at 07:50, Khem Raj <raj.khem@gmail.com> wrote: > libssp is implemented fully in glibc as well as in musl > so we really do not need the gcc version of this library > except may be for mingw, where we keep it enabled anyway > gcc in OE is built with the knowledge that C library > already provides libssp implementation, we should therefore > not need the gcc implementation of same. > > libssp_nonshared piece is a detail which is needed when gcc > is the compiler, in glibc this is part of libc_nonshared.a > already and libc_nonshared.a is linked always when linking > with -lc becuase libc.so in glibc is actually a linker script > > GROUP ( /usr/lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /usr/lib/ld-linux-x86-64.so.2 ) ) > > which automatically links in the needed runtime bits, this however > is not the case for musl, where core SSP APIs are implemented in full > but compiler specific runtime isn't, for this we add a new package > called libssp_nonshared which generate the needed runtime stub > and gcc is already carrying patch to link to libssp_nonshared.a > on musl > > This should fix a long standing problem where static PIE executable > were not buildable with OE since it was conflicting SSP implementation > one from C library and the other one from gcc and we end up with > duplicate symbol errors during linking. > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > --- > meta/recipes-devtools/gcc/gcc-7.3.inc | 4 +++- > meta/recipes-devtools/gcc/gcc-runtime.inc | 4 +++- > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-devtools/gcc/gcc-7.3.inc b/meta/recipes-devtools/gcc/gcc-7.3.inc > index d968c322d2..7e52afc643 100644 > --- a/meta/recipes-devtools/gcc/gcc-7.3.inc > +++ b/meta/recipes-devtools/gcc/gcc-7.3.inc > @@ -93,10 +93,12 @@ FORTRAN = "" > JAVA = "" > > LTO = "--enable-lto" > +SSP ?= "--disable-libssp" > +SSP_mingw = "--enable-libssp" > > EXTRA_OECONF_BASE = "\ > ${LTO} \ > - --enable-libssp \ > + ${SSP} \ > --enable-libitm \ > --disable-bootstrap \ > --disable-libmudflap \ > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc > index 97365a21dc..b4e5539575 100644 > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc > @@ -24,8 +24,10 @@ RUNTIMELIBITM_nios2 = "" > RUNTIMELIBITM_microblaze = "" > RUNTIMELIBITM_riscv32 = "" > RUNTIMELIBITM_riscv64 = "" > +RUNTIMELIBSSP ?= "" > +RUNTIMELIBSSP_mingw ?= "libssp" > > -RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \ > +RUNTIMETARGET = "libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \ > ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', '', d)} \ > " > RUNTIMETARGET_append_x86 = " libmpx" > -- > 2.17.0 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Sun, 2018-04-15 at 23:50 -0700, Khem Raj wrote: > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc > b/meta/recipes-devtools/gcc/gcc-runtime.inc > index 97365a21dc..b4e5539575 100644 > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc > @@ -24,8 +24,10 @@ RUNTIMELIBITM_nios2 = "" > RUNTIMELIBITM_microblaze = "" > RUNTIMELIBITM_riscv32 = "" > RUNTIMELIBITM_riscv64 = "" > +RUNTIMELIBSSP ?= "" > +RUNTIMELIBSSP_mingw ?= "libssp" > > -RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic > ${RUNTIMELIBITM} \ > +RUNTIMETARGET = "libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \ > ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], > 'libquadmath', '', d)} \ > " > RUNTIMETARGET_append_x86 = " libmpx" This last piece looks like you removed libssp for everywhere, glibc included except mingw? Is the source file you included in the new recipe the same as the one in the gcc source but linked differently? If so, I'd be tempted to build that gcc-runtime with a musl specific do_compile addition... I assume this is post 2.5 material as its fairly invasive changes at the tail end of a release... Cheers, Richard
On Tue, Apr 17, 2018 at 3:42 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Sun, 2018-04-15 at 23:50 -0700, Khem Raj wrote: >> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc >> b/meta/recipes-devtools/gcc/gcc-runtime.inc >> index 97365a21dc..b4e5539575 100644 >> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc >> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc >> @@ -24,8 +24,10 @@ RUNTIMELIBITM_nios2 = "" >> RUNTIMELIBITM_microblaze = "" >> RUNTIMELIBITM_riscv32 = "" >> RUNTIMELIBITM_riscv64 = "" >> +RUNTIMELIBSSP ?= "" >> +RUNTIMELIBSSP_mingw ?= "libssp" >> >> -RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic >> ${RUNTIMELIBITM} \ >> +RUNTIMETARGET = "libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \ >> ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], >> 'libquadmath', '', d)} \ >> " >> RUNTIMETARGET_append_x86 = " libmpx" > > This last piece looks like you removed libssp for everywhere, glibc > included except mingw? > yes, since the needed bits for ssp are already provided via libc.so there should not be a need for it needing libssp on glibc based systems, I think its due to the libssp patch we are carrying in gcc, I will take a look at that and limit it to just musl tuples > Is the source file you included in the new recipe the same as the one > in the gcc source but linked differently? If so, I'd be tempted to > build that gcc-runtime with a musl specific do_compile addition... > > I assume this is post 2.5 material as its fairly invasive changes at > the tail end of a release... > yes this is for 2.6 we may backport it later if needed. > Cheers, > > Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 4/17/18 3:12 AM, Burton, Ross wrote: > This is, I suspect, the cause of nativesdk-perl failing on the autobuilder: > > TOPDIR/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-perl/5.24.1-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/../../libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/7.3.0/ld: > cannot find -lssp_nonshared > TOPDIR/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-perl/5.24.1-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/../../libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/7.3.0/ld: > cannot find -lssp > collect2: error: ld returned 1 exit status > makefile:391: recipe for target 'lib/buildcustomize.pl' failed > > http://errors.yoctoproject.org/Errors/Details/176127/ > Sent a V2, which should fix it. https://patchwork.openembedded.org/patch/150197/ > Ross > > On 16 April 2018 at 07:50, Khem Raj <raj.khem@gmail.com> wrote: >> libssp is implemented fully in glibc as well as in musl >> so we really do not need the gcc version of this library >> except may be for mingw, where we keep it enabled anyway >> gcc in OE is built with the knowledge that C library >> already provides libssp implementation, we should therefore >> not need the gcc implementation of same. >> >> libssp_nonshared piece is a detail which is needed when gcc >> is the compiler, in glibc this is part of libc_nonshared.a >> already and libc_nonshared.a is linked always when linking >> with -lc becuase libc.so in glibc is actually a linker script >> >> GROUP ( /usr/lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /usr/lib/ld-linux-x86-64.so.2 ) ) >> >> which automatically links in the needed runtime bits, this however >> is not the case for musl, where core SSP APIs are implemented in full >> but compiler specific runtime isn't, for this we add a new package >> called libssp_nonshared which generate the needed runtime stub >> and gcc is already carrying patch to link to libssp_nonshared.a >> on musl >> >> This should fix a long standing problem where static PIE executable >> were not buildable with OE since it was conflicting SSP implementation >> one from C library and the other one from gcc and we end up with >> duplicate symbol errors during linking. >> >> Signed-off-by: Khem Raj <raj.khem@gmail.com> >> --- >> meta/recipes-devtools/gcc/gcc-7.3.inc | 4 +++- >> meta/recipes-devtools/gcc/gcc-runtime.inc | 4 +++- >> 2 files changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/meta/recipes-devtools/gcc/gcc-7.3.inc b/meta/recipes-devtools/gcc/gcc-7.3.inc >> index d968c322d2..7e52afc643 100644 >> --- a/meta/recipes-devtools/gcc/gcc-7.3.inc >> +++ b/meta/recipes-devtools/gcc/gcc-7.3.inc >> @@ -93,10 +93,12 @@ FORTRAN = "" >> JAVA = "" >> >> LTO = "--enable-lto" >> +SSP ?= "--disable-libssp" >> +SSP_mingw = "--enable-libssp" >> >> EXTRA_OECONF_BASE = "\ >> ${LTO} \ >> - --enable-libssp \ >> + ${SSP} \ >> --enable-libitm \ >> --disable-bootstrap \ >> --disable-libmudflap \ >> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc >> index 97365a21dc..b4e5539575 100644 >> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc >> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc >> @@ -24,8 +24,10 @@ RUNTIMELIBITM_nios2 = "" >> RUNTIMELIBITM_microblaze = "" >> RUNTIMELIBITM_riscv32 = "" >> RUNTIMELIBITM_riscv64 = "" >> +RUNTIMELIBSSP ?= "" >> +RUNTIMELIBSSP_mingw ?= "libssp" >> >> -RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \ >> +RUNTIMETARGET = "libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \ >> ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', '', d)} \ >> " >> RUNTIMETARGET_append_x86 = " libmpx" >> -- >> 2.17.0 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
diff --git a/meta/recipes-devtools/gcc/gcc-7.3.inc b/meta/recipes-devtools/gcc/gcc-7.3.inc index d968c322d2..7e52afc643 100644 --- a/meta/recipes-devtools/gcc/gcc-7.3.inc +++ b/meta/recipes-devtools/gcc/gcc-7.3.inc @@ -93,10 +93,12 @@ FORTRAN = "" JAVA = "" LTO = "--enable-lto" +SSP ?= "--disable-libssp" +SSP_mingw = "--enable-libssp" EXTRA_OECONF_BASE = "\ ${LTO} \ - --enable-libssp \ + ${SSP} \ --enable-libitm \ --disable-bootstrap \ --disable-libmudflap \ diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc index 97365a21dc..b4e5539575 100644 --- a/meta/recipes-devtools/gcc/gcc-runtime.inc +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc @@ -24,8 +24,10 @@ RUNTIMELIBITM_nios2 = "" RUNTIMELIBITM_microblaze = "" RUNTIMELIBITM_riscv32 = "" RUNTIMELIBITM_riscv64 = "" +RUNTIMELIBSSP ?= "" +RUNTIMELIBSSP_mingw ?= "libssp" -RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \ +RUNTIMETARGET = "libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \ ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', '', d)} \ " RUNTIMETARGET_append_x86 = " libmpx"
libssp is implemented fully in glibc as well as in musl so we really do not need the gcc version of this library except may be for mingw, where we keep it enabled anyway gcc in OE is built with the knowledge that C library already provides libssp implementation, we should therefore not need the gcc implementation of same. libssp_nonshared piece is a detail which is needed when gcc is the compiler, in glibc this is part of libc_nonshared.a already and libc_nonshared.a is linked always when linking with -lc becuase libc.so in glibc is actually a linker script GROUP ( /usr/lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /usr/lib/ld-linux-x86-64.so.2 ) ) which automatically links in the needed runtime bits, this however is not the case for musl, where core SSP APIs are implemented in full but compiler specific runtime isn't, for this we add a new package called libssp_nonshared which generate the needed runtime stub and gcc is already carrying patch to link to libssp_nonshared.a on musl This should fix a long standing problem where static PIE executable were not buildable with OE since it was conflicting SSP implementation one from C library and the other one from gcc and we end up with duplicate symbol errors during linking. Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-devtools/gcc/gcc-7.3.inc | 4 +++- meta/recipes-devtools/gcc/gcc-runtime.inc | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) -- 2.17.0 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core