gcc-target 5.1: fix for libcc1
cover gcc-target 5.1: fix for libcc1
The following changes since commit dd09fab685de2eaf04aa5ab60f8220b89c1deae9:
tune-core2.inc: set X86ARCH32 to i686 (instead of i586) (2015-07-02 23:08:27 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/gcc
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/gcc
Robert Yang (2):
gcc: remove EXTRA_OECONF_INTERMEDIATE
gcc-target 5.1: fix for libcc1
meta/recipes-devtools/gcc/gcc-4.8.inc | 10 ---- meta/recipes-devtools/gcc/gcc-4.9.inc | 10 ---- meta/recipes-devtools/gcc/gcc-5.1.inc | 11 +---- ...ibcc1-fix-libcc1-s-install-path-and-rpath.patch | 51 ++++++++++++++++++++ meta/recipes-devtools/gcc/gcc-configure-common.inc | 1 - meta/recipes-devtools/gcc/gcc-target.inc | 5 ++ meta/recipes-devtools/gcc/gcc_5.1.bb | 6 +++ 7 files changed, 63 insertions(+), 31 deletions(-) create mode 100644 meta/recipes-devtools/gcc/gcc-5.1/0039-libcc1-fix-libcc1-s-install-path-and-rpath.patch
Signature · 1 line
1.7.9.5
PATCH 1/2 gcc: remove EXTRA_OECONF_INTERMEDIATE
The gcc-intermediate had been gone, so remove EXTRA_OECONF_INTERMEDIATE.
--- meta/recipes-devtools/gcc/gcc-4.8.inc | 10 ---------- meta/recipes-devtools/gcc/gcc-4.9.inc | 10 ---------- meta/recipes-devtools/gcc/gcc-5.1.inc | 10 ---------- meta/recipes-devtools/gcc/gcc-configure-common.inc | 1 - 4 files changed, 31 deletions(-)
meta/recipes-devtools/gcc/gcc-4.8.inc +0 -10
@@ -107,16 +107,6 @@ EXTRA_OECONF_INITIAL = "\ --enable-decimal-float=no \ " -EXTRA_OECONF_INTERMEDIATE = "\ - --disable-libmudflap \ - --disable-libgomp \ - --disable-libquadmath \ - --with-system-zlib \ - --disable-lto \ - --disable-plugin \ - --disable-libssp \ -" - EXTRA_OECONF_append_libc-uclibc = " --disable-decimal-float " EXTRA_OECONF_PATHS = "\
meta/recipes-devtools/gcc/gcc-4.9.inc +0 -10
@@ -117,16 +117,6 @@ EXTRA_OECONF_INITIAL = "\ --enable-decimal-float=no \ " -EXTRA_OECONF_INTERMEDIATE = "\ - --disable-libmudflap \ - --disable-libgomp \ - --disable-libquadmath \ - --with-system-zlib \ - --disable-lto \ - --disable-plugin \ - --disable-libssp \ -" - EXTRA_OECONF_append_libc-uclibc = " --disable-decimal-float " EXTRA_OECONF_PATHS = "\
meta/recipes-devtools/gcc/gcc-5.1.inc +0 -10
@@ -107,16 +107,6 @@ EXTRA_OECONF_INITIAL = "\ --enable-decimal-float=no \ " -EXTRA_OECONF_INTERMEDIATE = "\ - --disable-libmudflap \ - --disable-libgomp \ - --disable-libquadmath \ - --with-system-zlib \ - --disable-lto \ - --disable-plugin \ - --disable-libssp \ -" - EXTRA_OECONF_append_libc-uclibc = " --disable-decimal-float " EXTRA_OECONF_PATHS = "\
meta/recipes-devtools/gcc/gcc-configure-common.inc +0 -1
@@ -25,7 +25,6 @@ OPTSPACE = '${@bb.utils.contains("SPECIAL_ARCH_LIST", "${TARGET_ARCH}", "", "--e EXTRA_OECONF_BASE ?= "" EXTRA_OECONF_PATHS ?= "" EXTRA_OECONF_INITIAL ?= "" -EXTRA_OECONF_INTERMEDIATE ?= "" GCCMULTILIB ?= "--disable-multilib" GCCTHREADS ?= "posix"
Signature · 1 line
1.7.9.5
PATCH 2/2 gcc-target 5.1: fix for libcc1
In reply to Robert YangFixed:
* gcc 5 introduces a plugin libcc1.so, which is used by gdb, the target gcc didn't build it in the past because gcc_cv_objdump is null, and the error was:
gcc-5.1.0/libcc1/configure: line 14531: -T: command not found
This only happens for tar gcc as the code shows:
if test x$build = x$host; then
export_sym_check="objdump${exeext} -T" elif test x$host = x$target; then
export_sym_check="$gcc_cv_objdump -T"
else
export_sym_check=
fi
* Install libcc1.so and libcc1plugin.so to $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) as lto-plugin did.
* Use sed command to fix bad RPATH iussue.
[YOCTO #7956]
--- meta/recipes-devtools/gcc/gcc-5.1.inc | 1 + ...ibcc1-fix-libcc1-s-install-path-and-rpath.patch | 51 ++++++++++++++++++++ meta/recipes-devtools/gcc/gcc-target.inc | 5 ++ meta/recipes-devtools/gcc/gcc_5.1.bb | 6 +++ 4 files changed, 63 insertions(+) create mode 100644 meta/recipes-devtools/gcc/gcc-5.1/0039-libcc1-fix-libcc1-s-install-path-and-rpath.patch
meta/recipes-devtools/gcc/gcc-5.1.inc +1 -0
@@ -70,6 +70,7 @@ SRC_URI = "\ file://0036-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch \ file://0037-pr65779.patch \ file://0038-fix-g++-sysroot.patch \ + file://0039-libcc1-fix-libcc1-s-install-path-and-rpath.patch \ " #S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${SNAP}"
meta/recipes-devtools/gcc/gcc-5.1/0039-libcc1-fix-libcc1-s-install-path-and-rpath.patch new file +51 -0
51 lines not on this page · raw message
meta/recipes-devtools/gcc/gcc-target.inc +5 -0
@@ -10,6 +10,11 @@ EXTRA_OECONF_PATHS = "\ EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu" +# libcc1 requres gcc_cv_objdump when cross build, but gcc_cv_objdump is +# set in subdir gcc, so subdir libcc1 can't use it, export it here to +# fix the problem. +export gcc_cv_objdump = "${TARGET_PREFIX}objdump" + EXTRA_OECONF_GCC_FLOAT = "${@get_gcc_float_setting(bb, d)}" PACKAGES = "\
meta/recipes-devtools/gcc/gcc_5.1.bb +6 -0
@@ -5,3 +5,9 @@ require gcc-target.inc # | gcc-4.8.1-r0/gcc-4.8.1/gcc/cp/decl.c:7438:(.text.unlikely+0x2fa): relocation truncated to fit: R_ARM_THM_CALL against symbol `fancy_abort(char const*, int, char const*)' defined in .glue_7 section in linker stubs # | gcc-4.8.1-r0/gcc-4.8.1/gcc/cp/decl.c:7442:(.text.unlikely+0x318): additional relocation overflows omitted from the output ARM_INSTRUCTION_SET_armv4 = "arm" + +do_configure_prepend() { + # Easiest way to stop bad RPATHs getting into the library since we have a + # broken libtool here + sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/' ${S}/libcc1/configure +}
Signature · 1 line
1.7.9.5
Quoted 4 lines · Robert Yang
* Install libcc1.so and libcc1plugin.so to $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) as lto-plugin
did.
Why are plugin libraries going into $libexecdir? libexecdir is for "binaries that the user doesn't directly execute", not for libraries or plugins.
Ross
Quoted 10 lines · Ross
On 6 July 2015 at 11:35, Robert Yang <[email protected] <mailto:[email protected]>> wrote:
* Install libcc1.so and libcc1plugin.so to $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) as lto-plugin did.
Why are plugin libraries going into $libexecdir? libexecdir is for "binaries that the user doesn't directly execute", not for libraries or plugins.
Hi Ross,
I put libcc1plugin.so into $libexecdir is because lto-plugin is there, do you know more about why lto-plugin is in $libexecdir, please ?
// Robert
Quoted 2 lines
Ross
Quoted 3 lines · Robert Yang
I put libcc1plugin.so into $libexecdir is because lto-plugin is there, do you know more about why lto-plugin is in $libexecdir, please ?
No, you'd have to look at the git history to see what the reason was. I'm not convinced there'll be a good reason. :)
Ross
Quoted 9 lines · Ross
Quoted 3 lines · Robert Yang
I put libcc1plugin.so into $libexecdir is because lto-plugin is there, do you know more about why lto-plugin is in $libexecdir, please ?
No, you'd have to look at the git history to see what the reason was. I'm not convinced there'll be a good reason. :)
these plugins have external implications thats why they are where they are, see
https://sourceware.org/ml/gdb-patches/2014-12/msg00358.html
Quoted 9 lines
Ross
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core