Skip to contentSkip to conversation

gcc-configure-common.inc: Stop gcc looking at build system paths

PATCH In review Richard Purdie 2 participants 3 messages Apr 15, 2012 – Apr 16, 2012

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 gcc-configure-common.inc: Stop gcc looking at build system paths

There were puzzling failures when you make a force recompile of any gcc component. The error was in do_configure with cross-compilation badness being detected in config.log files.

gcc is different in that many of the config.log files are generated during the do_compile phase. This means this host contamination issue has always been present but only shows up on a rebuild.

The fix is to force the appropriate configuration variable to "none required" then gcc won't look in the bad locations.

[YOCTO #2279]

---

meta/recipes-devtools/gcc/gcc-configure-common.inc +4 -0
index 7a96e91..9542dc9 100644
@@ -107,6 +107,10 @@ do_configure () {
 	export CXXFLAGS_FOR_BUILD="${BUILD_CXXFLAGS}"
 	export LDFLAGS_FOR_BUILD="${BUILD_LDFLAGS}"
 	export ARCH_FLAGS_FOR_TARGET="${ARCH_FLAGS_FOR_TARGET}"
+	# We need to set this else there is cross-compilation badness
+	# in the config.log files (which might not get generated until do_compile
+	# hence being missed by the insane do_configure check).
+	export gcc_cv_collect2_libs="none required"
 	(cd ${S} && gnu-configize) || die "failure running gnu-configize"
 
 	oe_runconf
#1 lore raw
Quoted 1 line · Richard Purdie

gcc_cv_collect2_libs

is it the /usr/lib/cmplrs/cc2.11 access issue ?
in that case the fix it fine. However if its something in LTO then we need to dig deeper

#2 lore raw
Quoted 5 lines · Khem Raj
Quoted 1 line · Richard Purdie

gcc_cv_collect2_libs

is it the /usr/lib/cmplrs/cc2.11 access issue ?

It is.

Quoted 2 lines

in that case the fix it fine. However if its something in LTO then we need to dig deeper

Its not lto related.

Cheers,

Richard