gcc errors while building core-image-sato-sdk

gcc errors while building core-image-sato-sdk

[Damian, Alexandru]

[-- Attachment #1.1: Type: text/plain, Size: 335 bytes --]

Hi guys,

From time to time I get errors building gcc (although I didn't trigger a
rebuild!) when runnign
bitbake core-image-sato-sdk

The error is attached:
/home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/temp/log.do_configure.20668

What is causing this, is this a know bug ?

Cheers,
Alex

[-- Attachment #1.2: Type: text/html, Size: 366 bytes --]

[-- Attachment #2: log.do_configure.20668 --]
[-- Type: application/octet-stream, Size: 9743 bytes --]

DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 'common-linux', 'common-glibc', 'i586-linux', 'common']
DEBUG: Executing shell function do_configure
configure.ac:33: error: Please use exactly Autoconf 2.64 instead of 2.68.
config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:33: the top level
autom4te: m4 failed with exit status: 1
NOTE: Running /home/ddalex/ssd/yocto/build/tmp/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/configure  --build=x86_64-linux 		  --host=i586-poky-linux 		  --target=i586-poky-linux 		  --prefix=/usr 		  --exec_prefix=/usr 		  --bindir=/usr/bin 		  --sbindir=/usr/sbin 		  --libexecdir=/usr/libexec 		  --datadir=/usr/share 		  --sysconfdir=/etc 		  --sharedstatedir=/com 		  --localstatedir=/var 		  --libdir=/usr/lib 		  --includedir=/usr/include 		  --oldincludedir=/usr/include 		  --infodir=/usr/share/info 		  --mandir=/usr/share/man 		  --disable-silent-rules 		  --disable-dependency-tracking 		  --with-libtool-sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86                  --with-gnu-ld                 --enable-shared                 --enable-languages=c,c++                 --enable-threads=posix                 --disable-multilib                 --enable-c99                 --enable-long-long                 --enable-symvers=gnu                 --enable-libstdcxx-pch                 --program-prefix=i586-poky-linux- 		--without-local-prefix                 --enable-target-optspace                  --enable-lto 			--enable-libssp 			--disable-bootstrap 			--disable-libgomp 			--disable-libmudflap 			--with-system-zlib 			--with-linker-hash-style=gnu 			--with-ppl=no 			--with-cloog=no 			--enable-checking=release 			--enable-cheaders=c_global                                        --with-sysroot=/     --with-build-sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86     --with-gxx-include-dir=/usr/include/c++/                                   --enable-nls --enable-__cxa_atexit 
checking build system type... x86_64-pc-linux-gnu
checking host system type... i586-poky-linux-gnu
checking target system type... i586-poky-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /bin/sed
checking for gawk... gawk
checking for libitm support... yes
checking for i586-poky-linux-gcc... i586-poky-linux-gcc  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i586-poky-linux-gcc  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86 accepts -g... yes
checking for i586-poky-linux-gcc  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86 option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether i586-poky-linux-g++  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86 accepts -g... yes
checking for i586-poky-linux-gnatbind... no
checking for gnatbind... no
checking for i586-poky-linux-gnatmake... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for objdir... .libs
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... yes
*** This configuration is not supported in the following subdirectories:
     zlib gnattools target-libada target-libgfortran target-libgo target-libffi target-zlib target-libjava target-libobjc target-libgomp target-libmudflap target-boehm-gc
    (Any other directories should still work fine.)
checking for default BUILD_CONFIG... 
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... no
checking for runtest... no
checking for ar... (cached) i586-poky-linux-ar
checking for i586-poky-linux-ar... (cached) i586-poky-linux-ar
checking for as... (cached) i586-poky-linux-as
checking for i586-poky-linux-as... (cached) i586-poky-linux-as
checking for i586-poky-linux-dlltool... no
checking for ld... (cached) i586-poky-linux-ld --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86
checking for i586-poky-linux-ld... (cached) i586-poky-linux-ld --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86
checking for i586-poky-linux-lipo... no
checking for nm... (cached) i586-poky-linux-nm
checking for i586-poky-linux-nm... (cached) i586-poky-linux-nm
checking for ranlib... (cached) i586-poky-linux-ranlib
checking for i586-poky-linux-ranlib... (cached) i586-poky-linux-ranlib
checking for strip... (cached) i586-poky-linux-strip
checking for i586-poky-linux-strip... (cached) i586-poky-linux-strip
checking for i586-poky-linux-windres... no
checking for i586-poky-linux-windmc... no
checking for objcopy... (cached) i586-poky-linux-objcopy
checking for i586-poky-linux-objcopy... (cached) i586-poky-linux-objcopy
checking for objdump... (cached) i586-poky-linux-objdump
checking for i586-poky-linux-objdump... (cached) i586-poky-linux-objdump
checking for i586-poky-linux-readelf... i586-poky-linux-readelf
checking for cc... (cached) i586-poky-linux-gcc  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86
checking for gcc... (cached) i586-poky-linux-gcc  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86
checking for c++... (cached) i586-poky-linux-g++  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86
checking for g++... (cached) i586-poky-linux-g++  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86
checking for cxx... (cached) i586-poky-linux-g++  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86
checking for gxx... (cached) i586-poky-linux-g++  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86
checking for gcc... (cached) i586-poky-linux-gcc  -m32   -march=i586 --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86
checking for i586-poky-linux-gcj... no
checking for gfortran... (cached) gfortran
checking for i586-poky-linux-gccgo... no
checking for i586-poky-linux-dlltool... no
checking for i586-poky-linux-lipo... no
checking for i586-poky-linux-readelf... i586-poky-linux-readelf
checking for i586-poky-linux-windres... no
checking for i586-poky-linux-windmc... no
checking where to find the target ar... pre-installed in /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2
checking where to find the target as... pre-installed in /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2
checking where to find the target cc... pre-installed
checking where to find the target c++... pre-installed
checking where to find the target c++ for libstdc++... pre-installed
checking where to find the target dlltool... pre-installed
checking where to find the target gcc... pre-installed
checking where to find the target gcj... pre-installed
checking where to find the target gfortran... pre-installed
checking where to find the target gccgo... pre-installed
checking where to find the target ld... pre-installed in /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2
checking where to find the target lipo... pre-installed
checking where to find the target nm... pre-installed in /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2
checking where to find the target objdump... pre-installed in /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2
checking where to find the target ranlib... pre-installed in /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2
checking where to find the target readelf... pre-installed
checking where to find the target strip... pre-installed in /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2
checking where to find the target windres... pre-installed
checking where to find the target windmc... pre-installed
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether -fkeep-inline-functions is supported... yes
configure: creating ./config.status
config.status: creating Makefile
DEBUG: Shell function do_configure finished
DEBUG: Executing python function do_qa_configure
NOTE: Checking autotools environment for common misconfiguration
ERROR: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities.
Rerun configure task after fixing this. The path was '/home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc'
DEBUG: Python function do_qa_configure finished
ERROR: Function failed: do_qa_configure

Re: gcc errors while building core-image-sato-sdk

[Mihai Lindner]

On 7/4/2012 3:55 PM, Damian, Alexandru wrote:
> Hi guys,
> 
> From time to time I get errors building gcc (although I didn't trigger a rebuild!) when runnign
> bitbake core-image-sato-sdk
> 
> The error is attached:
> /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/temp/log.do_configure.20668
> 
> What is causing this, is this a know bug ?
> 
> Cheers,
> Alex
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 

To get a hint on why it fails, check in /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log if there's "CROSS COMPILE Badness:" or "is unsafe for cross-compilation".

#$ grep -e 'CROSS COMPILE Badness:' -e 'is unsafe for cross-compilation' /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log

`bitbake` will fail if `grep` has results.

-- 
Mihai Lindner
Yocto Project

Re: gcc errors while building core-image-sato-sdk

[Richard Purdie]

On Wed, 2012-07-04 at 17:32 +0300, Mihai Lindner wrote:
> On 7/4/2012 3:55 PM, Damian, Alexandru wrote:
> > Hi guys,
> > 
> > From time to time I get errors building gcc (although I didn't trigger a rebuild!) when runnign
> > bitbake core-image-sato-sdk
> > 
> > The error is attached:
> > /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/temp/log.do_configure.20668
> > 
> > What is causing this, is this a know bug ?
> > 
> > Cheers,
> > Alex
> > 
> > 
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> > 
> 
> To get a hint on why it fails, check
> in /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1
> +svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log if there's "CROSS COMPILE Badness:" or "is unsafe for cross-compilation".
>
> #$ grep -e 'CROSS COMPILE Badness:' -e 'is unsafe for
> cross-compilation' /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log
>
> `bitbake` will fail if `grep` has results.

It might be slightly more complex than this. gcc is ugly in that the
compile task executes a ton of separate configure processes and it could
be tripping up on the above expression on any one of those config.log
files.

Once you find the config.log, report back on which one it is and what
the message says and then we can work through how to fix it.

Cheers,

Richard

Re: gcc errors while building core-image-sato-sdk

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 4138 bytes --]

The question wasn't why it fails, but why sometimes it goes through, why
sometimes fail, and why is it retriggered
without any changes to the config or files (run 5 times the
core-image-sato-sdk build in a row, and at least once it will fail).

I don't trust systems that are not deterministic :).

This being said:

grep -C5 -e 'CROSS COMPILE Badness:' -e 'is unsafe for cross-compilation'
/home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log
| return ldopen ();
|   ;
|   return 0;
| }
configure:8836: i586-poky-linux-gcc  -m32   -march=i586
--sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86 -o conftest
-pipe -g -feliminate-unused-debug-types   -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed conftest.c -L/usr/lib/cmplrs/cc2.11 -lmld >&5
/home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld:
warning: library search path "/usr/lib/cmplrs/cc2.11" is unsafe for
cross-compilation
/home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld:
cannot find -lmld
collect2: error: ld returned 1 exit status
configure:8836: $? = 1
configure: failed program was:
| /* confdefs.h */
--
| return ldopen ();
|   ;
|   return 0;
| }
configure:8836: i586-poky-linux-gcc  -m32   -march=i586
--sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86 -o conftest
-pipe -g -feliminate-unused-debug-types   -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed conftest.c -L/usr/lib/cmplrs/cc3.11 -lmld >&5
/home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld:
warning: library search path "/usr/lib/cmplrs/cc3.11" is unsafe for
cross-compilation
/home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld:
cannot find -lmld
collect2: error: ld returned 1 exit status
configure:8836: $? = 1
configure: failed program was:
| /* confdefs.h */


On Wed, Jul 4, 2012 at 5:45 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Wed, 2012-07-04 at 17:32 +0300, Mihai Lindner wrote:
> > On 7/4/2012 3:55 PM, Damian, Alexandru wrote:
> > > Hi guys,
> > >
> > > From time to time I get errors building gcc (although I didn't trigger
> a rebuild!) when runnign
> > > bitbake core-image-sato-sdk
> > >
> > > The error is attached:
> > >
> /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/temp/log.do_configure.20668
> > >
> > > What is causing this, is this a know bug ?
> > >
> > > Cheers,
> > > Alex
> > >
> > >
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> > >
> >
> > To get a hint on why it fails, check
> > in /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1
> >
> +svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log
> if there's "CROSS COMPILE Badness:" or "is unsafe for cross-compilation".
> >
> > #$ grep -e 'CROSS COMPILE Badness:' -e 'is unsafe for
> > cross-compilation'
> /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log
> >
> > `bitbake` will fail if `grep` has results.
>
> It might be slightly more complex than this. gcc is ugly in that the
> compile task executes a ton of separate configure processes and it could
> be tripping up on the above expression on any one of those config.log
> files.
>
> Once you find the config.log, report back on which one it is and what
> the message says and then we can work through how to fix it.
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 5181 bytes --]

Re: gcc errors while building core-image-sato-sdk

[Richard Purdie]

On Wed, 2012-07-04 at 17:50 +0300, Damian, Alexandru wrote:
> The question wasn't why it fails, but why sometimes it goes through,
> why sometimes fail, and why is it retriggered
> without any changes to the config or files (run 5 times the
> core-image-sato-sdk build in a row, and at least once it will fail).
>
> I don't trust systems that are not deterministic :).

The check runs at the end of the do_configure task.

The config.log is generated by do_compile. If do_configure is re-run,
you'll hit the failure.

> This being said:
> 
> grep -C5 -e 'CROSS COMPILE Badness:' -e 'is unsafe for
> cross-compilation' /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log
> | return ldopen ();
> |   ;
> |   return 0;
> | }
> configure:8836: i586-poky-linux-gcc  -m32   -march=i586
> --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86 -o
> conftest -pipe -g -feliminate-unused-debug-types   -Wl,-O1
> -Wl,--hash-style=gnu -Wl,--as-needed conftest.c
> -L/usr/lib/cmplrs/cc2.11 -lmld >&5
> /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld: warning: library search path "/usr/lib/cmplrs/cc2.11" is unsafe for cross-compilation
> /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld: cannot find -lmld
> collect2: error: ld returned 1 exit status
> configure:8836: $? = 1
> configure: failed program was:
> | /* confdefs.h */

So we need it to stop looking for libmld whatever that is. Hopefully
there is a --disable-xxxx option we can pass in?

Cheers,

Richard

Re: gcc errors while building core-image-sato-sdk

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 2607 bytes --]

I guess the problem is no lmld, (skips over), Mihai says that

- library search path "/usr/lib/cmplrs/cc2.11" is unsafe for
cross-compilation

is the cause.


I'm unable to trace back the cc2.11 file name (path).



Let's take it bit by bit, we have two issues here.
1. - why the configure hangs from time to time (what is that c2.11 ??)

2. - why sometimes it triggers massive rebuild even if nothing is changed.

Regarding point 2, does anybody else sees it ?

Alex

On Wed, Jul 4, 2012 at 6:02 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Wed, 2012-07-04 at 17:50 +0300, Damian, Alexandru wrote:
> > The question wasn't why it fails, but why sometimes it goes through,
> > why sometimes fail, and why is it retriggered
> > without any changes to the config or files (run 5 times the
> > core-image-sato-sdk build in a row, and at least once it will fail).
> >
> > I don't trust systems that are not deterministic :).
>
> The check runs at the end of the do_configure task.
>
> The config.log is generated by do_compile. If do_configure is re-run,
> you'll hit the failure.
>
> > This being said:
> >
> > grep -C5 -e 'CROSS COMPILE Badness:' -e 'is unsafe for
> > cross-compilation'
> /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log
> > | return ldopen ();
> > |   ;
> > |   return 0;
> > | }
> > configure:8836: i586-poky-linux-gcc  -m32   -march=i586
> > --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86 -o
> > conftest -pipe -g -feliminate-unused-debug-types   -Wl,-O1
> > -Wl,--hash-style=gnu -Wl,--as-needed conftest.c
> > -L/usr/lib/cmplrs/cc2.11 -lmld >&5
> >
> /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld:
> warning: library search path "/usr/lib/cmplrs/cc2.11" is unsafe for
> cross-compilation
> >
> /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld:
> cannot find -lmld
> > collect2: error: ld returned 1 exit status
> > configure:8836: $? = 1
> > configure: failed program was:
> > | /* confdefs.h */
>
> So we need it to stop looking for libmld whatever that is. Hopefully
> there is a --disable-xxxx option we can pass in?
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 3373 bytes --]

Re: gcc errors while building core-image-sato-sdk

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3273 bytes --]

On Wed, Jul 04, 2012 at 06:06:55PM +0300, Damian, Alexandru wrote:
> I guess the problem is no lmld, (skips over), Mihai says that
> 
> - library search path "/usr/lib/cmplrs/cc2.11" is unsafe for
> cross-compilation

It's one of issues I sometimes see during gcc upgrades.. and it was
there with e.g. gcc-4.6.3 too 
http://build.shr-project.org/tests/jama/gcc-issue/gcc.issue (from Jan
14)

> is the cause.
> 
> 
> I'm unable to trace back the cc2.11 file name (path).
> 
> 
> 
> Let's take it bit by bit, we have two issues here.
> 1. - why the configure hangs from time to time (what is that c2.11 ??)
> 
> 2. - why sometimes it triggers massive rebuild even if nothing is changed.
> 
> Regarding point 2, does anybody else sees it ?
> 
> Alex
> 
> On Wed, Jul 4, 2012 at 6:02 PM, Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
> 
> > On Wed, 2012-07-04 at 17:50 +0300, Damian, Alexandru wrote:
> > > The question wasn't why it fails, but why sometimes it goes through,
> > > why sometimes fail, and why is it retriggered
> > > without any changes to the config or files (run 5 times the
> > > core-image-sato-sdk build in a row, and at least once it will fail).
> > >
> > > I don't trust systems that are not deterministic :).
> >
> > The check runs at the end of the do_configure task.
> >
> > The config.log is generated by do_compile. If do_configure is re-run,
> > you'll hit the failure.
> >
> > > This being said:
> > >
> > > grep -C5 -e 'CROSS COMPILE Badness:' -e 'is unsafe for
> > > cross-compilation'
> > /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log
> > > | return ldopen ();
> > > |   ;
> > > |   return 0;
> > > | }
> > > configure:8836: i586-poky-linux-gcc  -m32   -march=i586
> > > --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86 -o
> > > conftest -pipe -g -feliminate-unused-debug-types   -Wl,-O1
> > > -Wl,--hash-style=gnu -Wl,--as-needed conftest.c
> > > -L/usr/lib/cmplrs/cc2.11 -lmld >&5
> > >
> > /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld:
> > warning: library search path "/usr/lib/cmplrs/cc2.11" is unsafe for
> > cross-compilation
> > >
> > /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld:
> > cannot find -lmld
> > > collect2: error: ld returned 1 exit status
> > > configure:8836: $? = 1
> > > configure: failed program was:
> > > | /* confdefs.h */
> >
> > So we need it to stop looking for libmld whatever that is. Hopefully
> > there is a --disable-xxxx option we can pass in?
> >
> > Cheers,
> >
> > Richard
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: gcc errors while building core-image-sato-sdk

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 4164 bytes --]

I guess the root of the problem is when the autotools start up - we're
having autoconf 2.68,
which is not liked by gcc 4.7.1

configure.ac:33: error: Please use exactly Autoconf 2.64 instead of 2.68.
config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:33: the top level
autom4te: m4 failed with exit status: 1


I'm gonna downgrade to autoconf 2.64 and see what happens.

Alex

On Wed, Jul 4, 2012 at 6:21 PM, Martin Jansa <martin.jansa@gmail.com> wrote:

> On Wed, Jul 04, 2012 at 06:06:55PM +0300, Damian, Alexandru wrote:
> > I guess the problem is no lmld, (skips over), Mihai says that
> >
> > - library search path "/usr/lib/cmplrs/cc2.11" is unsafe for
> > cross-compilation
>
> It's one of issues I sometimes see during gcc upgrades.. and it was
> there with e.g. gcc-4.6.3 too
> http://build.shr-project.org/tests/jama/gcc-issue/gcc.issue (from Jan
> 14)
>
> > is the cause.
> >
> >
> > I'm unable to trace back the cc2.11 file name (path).
> >
> >
> >
> > Let's take it bit by bit, we have two issues here.
> > 1. - why the configure hangs from time to time (what is that c2.11 ??)
> >
> > 2. - why sometimes it triggers massive rebuild even if nothing is
> changed.
> >
> > Regarding point 2, does anybody else sees it ?
> >
> > Alex
> >
> > On Wed, Jul 4, 2012 at 6:02 PM, Richard Purdie <
> > richard.purdie@linuxfoundation.org> wrote:
> >
> > > On Wed, 2012-07-04 at 17:50 +0300, Damian, Alexandru wrote:
> > > > The question wasn't why it fails, but why sometimes it goes through,
> > > > why sometimes fail, and why is it retriggered
> > > > without any changes to the config or files (run 5 times the
> > > > core-image-sato-sdk build in a row, and at least once it will fail).
> > > >
> > > > I don't trust systems that are not deterministic :).
> > >
> > > The check runs at the end of the do_configure task.
> > >
> > > The config.log is generated by do_compile. If do_configure is re-run,
> > > you'll hit the failure.
> > >
> > > > This being said:
> > > >
> > > > grep -C5 -e 'CROSS COMPILE Badness:' -e 'is unsafe for
> > > > cross-compilation'
> > >
> /home/ddalex/ssd/yocto/build/tmp/work/i586-poky-linux/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/build.i586-poky-linux.i586-poky-linux/gcc/config.log
> > > > | return ldopen ();
> > > > |   ;
> > > > |   return 0;
> > > > | }
> > > > configure:8836: i586-poky-linux-gcc  -m32   -march=i586
> > > > --sysroot=/home/ddalex/ssd/yocto/build/tmp/sysroots/qemux86 -o
> > > > conftest -pipe -g -feliminate-unused-debug-types   -Wl,-O1
> > > > -Wl,--hash-style=gnu -Wl,--as-needed conftest.c
> > > > -L/usr/lib/cmplrs/cc2.11 -lmld >&5
> > > >
> > >
> /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld:
> > > warning: library search path "/usr/lib/cmplrs/cc2.11" is unsafe for
> > > cross-compilation
> > > >
> > >
> /home/ddalex/ssd/yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld:
> > > cannot find -lmld
> > > > collect2: error: ld returned 1 exit status
> > > > configure:8836: $? = 1
> > > > configure: failed program was:
> > > > | /* confdefs.h */
> > >
> > > So we need it to stop looking for libmld whatever that is. Hopefully
> > > there is a --disable-xxxx option we can pass in?
> > >
> > > Cheers,
> > >
> > > Richard
> > >
> > >
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> > >
>
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>

[-- Attachment #2: Type: text/html, Size: 6053 bytes --]

Re: gcc errors while building core-image-sato-sdk

[Khem Raj]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/4/2012 11:51 PM, Damian, Alexandru wrote:
> I guess the root of the problem is when the autotools start up -
> we're having autoconf 2.68, which is not liked by gcc 4.7.1
> 

thats a red herring. You should instead find out why is it trying to
autoreconf

> configure.ac:33: error: Please use exactly Autoconf 2.64 instead of
> 2.68. config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is
> expanded from... configure.ac:33: the top level autom4te: m4 failed
> with exit status: 1
> 
> 
> I'm gonna downgrade to autoconf 2.64 and see what happens.
> 

it wont help.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/18ywACgkQuwUzVZGdMxTGgQCfV0OhuBE+gaoqYyq8oCpyKUP1
K8gAniKed69w0iLjnZznAeGOoS8ovt9H
=x3RK
-----END PGP SIGNATURE-----

Re: gcc errors while building core-image-sato-sdk

[Richard Purdie]

On Thu, 2012-07-05 at 13:03 -0700, Khem Raj wrote:
> On 7/4/2012 11:51 PM, Damian, Alexandru wrote:
> > I guess the root of the problem is when the autotools start up -
> > we're having autoconf 2.68, which is not liked by gcc 4.7.1
> > 
> 
> thats a red herring. You should instead find out why is it trying to
> autoreconf
> 
> > configure.ac:33: error: Please use exactly Autoconf 2.64 instead of
> > 2.68. config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is
> > expanded from... configure.ac:33: the top level autom4te: m4 failed
> > with exit status: 1
> > 
> > 
> > I'm gonna downgrade to autoconf 2.64 and see what happens.
> > 
> 
> it wont help.

I merged a couple of gcc changes fairly quickly to address a variety of
problems people started hitting (including the autobuilder). The svn
nature of the recipe is causing a few issues with the subversion 1.7
change. I am wondering if we should just point it to the svn checkout
tarball by default and leave the svn url for use when updating only and
populating the mirror?

Cheers,

Richard

Re: gcc errors while building core-image-sato-sdk

[Khem Raj]

On Fri, Jul 6, 2012 at 1:55 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> I merged a couple of gcc changes fairly quickly to address a variety of
> problems people started hitting (including the autobuilder). The svn
> nature of the recipe is causing a few issues with the subversion 1.7
> change. I am wondering if we should just point it to the svn checkout
> tarball by default and leave the svn url for use when updating only and
> populating the mirror?

or we can use git instead of svn. http://gcc.gnu.org/git/?p=gcc.git

Re: gcc errors while building core-image-sato-sdk

[Saul Wold]

On 07/06/2012 09:00 AM, Khem Raj wrote:
> On Fri, Jul 6, 2012 at 1:55 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>>
>> I merged a couple of gcc changes fairly quickly to address a variety of
>> problems people started hitting (including the autobuilder). The svn
>> nature of the recipe is causing a few issues with the subversion 1.7
>> change. I am wondering if we should just point it to the svn checkout
>> tarball by default and leave the svn url for use when updating only and
>> populating the mirror?
>
> or we can use git instead of svn. http://gcc.gnu.org/git/?p=gcc.git
>
That sounds like a good idea.

Sau!

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>

Re: gcc errors while building core-image-sato-sdk

[Khem Raj]

On Fri, Jul 6, 2012 at 10:23 AM, Saul Wold <sgw@linux.intel.com> wrote:
> On 07/06/2012 09:00 AM, Khem Raj wrote:
>>
>> On Fri, Jul 6, 2012 at 1:55 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>>
>>>
>>> I merged a couple of gcc changes fairly quickly to address a variety of
>>> problems people started hitting (including the autobuilder). The svn
>>> nature of the recipe is causing a few issues with the subversion 1.7
>>> change. I am wondering if we should just point it to the svn checkout
>>> tarball by default and leave the svn url for use when updating only and
>>> populating the mirror?
>>
>>
>> or we can use git instead of svn. http://gcc.gnu.org/git/?p=gcc.git
>>
> That sounds like a good idea.

I have queued up a patch in the eglibc 2.16 pull tree for it
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/eglibc-2.16&id=d81a98a5c13256f6f14c5b7921492c293dd9587b

>
> Sau!
>
>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>