Re: sparc 4.11 tools build failure on CentOS 6.x
On 01/28/2014 10:04 PM, Alan Cudmore wrote:
I was just able to build the sparc-rtems4.11 toolchain on Centos 6.5 ,
64 bit
This was on a fresh Centos 6.x VM with all updates, no previous RTEMS
tools installed.
OK. I have solved it but it was a weird one. My PATH accidentally
had :: in it and that let . (the current directory) be in my PATH.
GCC creates a shell script called as which invokes the cross
assembler. It meant to get the native as but got the script for
the cross.
Having . in a PATH is bad and apparently :: gives you the same
effect in at least bash.
Should I file a PR to request that sb-check or the source builder
check this condition?
Alan
[alan@centosvm Desktop]$ sparc-rtems4.11-gcc -v
Using built-in specs.
COLLECT_GCC=sparc-rtems4.11-gcc
COLLECT_LTO_WRAPPER=/home/alan/Projects/rtems/4.11/libexec/gcc/sparc-rtems4.11/4.8.2/lto-wrapper
Target: sparc-rtems4.11
Configured with: ../gcc-4.8.2/configure
--prefix=/home/alan/Projects/rtems/4.11
--bindir=/home/alan/Projects/rtems/4.11/bin
--exec_prefix=/home/alan/Projects/rtems/4.11
--includedir=/home/alan/Projects/rtems/4.11/include
--libdir=/home/alan/Projects/rtems/4.11/lib
--libexecdir=/home/alan/Projects/rtems/4.11/libexec
--mandir=/home/alan/Projects/rtems/4.11/share/man
--infodir=/home/alan/Projects/rtems/4.11/share/info
--datadir=/home/alan/Projects/rtems/4.11/share --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=sparc-rtems4.11 --disable-libstdcxx-pch
--with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plugin --enable-languages=c,c++
Thread model: posix
gcc version 4.8.2 20131016 (RTEMS
4.11-RSB(2be445d2aafae21849c5d626b3787e2ab1ac846b)-1,gcc-4.8.2/newlib-2.1.0)
(GCC)
On 1/28/2014 10:38 PM, Chris Johns wrote:
On 29/01/2014 3:46 am, Joel Sherrill wrote:
Hi
Not sure what broke recently but something went wrong. :(
Can anyone build sparc-rtems4.11 tools with the rtems-source-builder
head?
Yes on FreeBSD 9 and on MacOS Mavrick
Build Set: Time 0:08:46.537755
/bin/sh ../../gcc-4.8.2/gcc/mkconfig.sh bconfig.h
/usr/bin/g++ -O2 -pipe
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/tmp/sb-joel/4.11/rtems-sparc/home/joel/rtems-4.11-work/tools/include
-c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.8.2/gcc
-I../../gcc-4.8.2/gcc/build -I../../gcc-4.8.2/gcc/../include
-I../../gcc-4.8.2/gcc/../libcpp/include
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/build/./gmp
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/gmp
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/build/./mpfr
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/mpfr
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/mpc/src
-I../../gcc-4.8.2/gcc/../libdecnumber
-I../../gcc-4.8.2/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-4.8.2/gcc/../libbacktrace\
-DBASEVER=\4.8.2\ -DDATESTAMP=\ 20131016\ \
-DREVISION=\\ \
-DDEVPHASE=\ (RTEMS
4.11-RSB(2be445d2aafae21849c5d626b3787e2ab1ac846b)-1,gcc-4.8.2/newlib-2.1.0)\
Same git hash I am using.
-DPKGVERSION=\(GCC) \ \
-DBUGURL=\http://gcc.gnu.org/bugs.html\ -o build/version.o
../../gcc-4.8.2/gcc/version.c
{standard input}: Assembler messages:
{standard input}:33: Error: unknown pseudo-op: `.value'
{standard input}:183: Error: unknown pseudo-op: `.value'
Anything in your path that could up set up things ?
Do the installed RPMs verify ?
Chris
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
--
Joel Sherrill, Ph.D. Director of Research Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35806
Support Available (256) 722-9985
Re: sparc 4.11 tools build failure on CentOS 6.x
On 30/01/2014 9:55 am, Joel Sherrill wrote: On 01/28/2014 10:04 PM, Alan Cudmore wrote: I was just able to build the sparc-rtems4.11 toolchain on Centos 6.5 , 64 bit This was on a fresh Centos 6.x VM with all updates, no previous RTEMS tools installed. OK. I have solved it but it was a weird one. My PATH accidentally had :: in it and that let . (the current directory) be in my PATH. GCC creates a shell script called as which invokes the cross assembler. It meant to get the native as but got the script for the cross. Having . in a PATH is bad and apparently :: gives you the same effect in at least bash. Should I file a PR to request that sb-check or the source builder check this condition? Yes or a patch :). This was asked for recently. I think sb-check is internally involved each build which means the path is checked each time. Chris ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: sparc 4.11 tools build failure on CentOS 6.x
On 1/29/2014 5:48 PM, Chris Johns wrote: On 30/01/2014 9:55 am, Joel Sherrill wrote: On 01/28/2014 10:04 PM, Alan Cudmore wrote: I was just able to build the sparc-rtems4.11 toolchain on Centos 6.5 , 64 bit This was on a fresh Centos 6.x VM with all updates, no previous RTEMS tools installed. OK. I have solved it but it was a weird one. My PATH accidentally had :: in it and that let . (the current directory) be in my PATH. GCC creates a shell script called as which invokes the cross assembler. It meant to get the native as but got the script for the cross. Having . in a PATH is bad and apparently :: gives you the same effect in at least bash. Should I file a PR to request that sb-check or the source builder check this condition? Yes or a patch :). You will be lucky to get a PR out of me. I feel swamped. This was asked for recently. I think sb-check is internally involved each build which means the path is checked each time. That's great. . in a directory is bad and I didn't realize that :: in a PATH would do that. Chris -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: sparc 4.11 tools build failure on CentOS 6.x
On 29/01/2014 3:46 am, Joel Sherrill wrote:
Hi
Not sure what broke recently but something went wrong. :(
Can anyone build sparc-rtems4.11 tools with the rtems-source-builder
head?
Yes on FreeBSD 9 and on MacOS Mavrick
Build Set: Time 0:08:46.537755
/bin/sh ../../gcc-4.8.2/gcc/mkconfig.sh bconfig.h
/usr/bin/g++ -O2 -pipe
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/tmp/sb-joel/4.11/rtems-sparc/home/joel/rtems-4.11-work/tools/include
-c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.8.2/gcc
-I../../gcc-4.8.2/gcc/build -I../../gcc-4.8.2/gcc/../include
-I../../gcc-4.8.2/gcc/../libcpp/include
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/build/./gmp
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/gmp
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/build/./mpfr
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/mpfr
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/mpc/src
-I../../gcc-4.8.2/gcc/../libdecnumber
-I../../gcc-4.8.2/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-4.8.2/gcc/../libbacktrace\
-DBASEVER=\4.8.2\ -DDATESTAMP=\ 20131016\ \
-DREVISION=\\ \
-DDEVPHASE=\ (RTEMS
4.11-RSB(2be445d2aafae21849c5d626b3787e2ab1ac846b)-1,gcc-4.8.2/newlib-2.1.0)\
Same git hash I am using.
-DPKGVERSION=\(GCC) \ \
-DBUGURL=\http://gcc.gnu.org/bugs.html\ -o build/version.o
../../gcc-4.8.2/gcc/version.c
{standard input}: Assembler messages:
{standard input}:33: Error: unknown pseudo-op: `.value'
{standard input}:183: Error: unknown pseudo-op: `.value'
Anything in your path that could up set up things ?
Do the installed RPMs verify ?
Chris
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
Re: sparc 4.11 tools build failure on CentOS 6.x
I was just able to build the sparc-rtems4.11 toolchain on Centos 6.5 ,
64 bit
This was on a fresh Centos 6.x VM with all updates, no previous RTEMS
tools installed.
Alan
[alan@centosvm Desktop]$ sparc-rtems4.11-gcc -v
Using built-in specs.
COLLECT_GCC=sparc-rtems4.11-gcc
COLLECT_LTO_WRAPPER=/home/alan/Projects/rtems/4.11/libexec/gcc/sparc-rtems4.11/4.8.2/lto-wrapper
Target: sparc-rtems4.11
Configured with: ../gcc-4.8.2/configure
--prefix=/home/alan/Projects/rtems/4.11
--bindir=/home/alan/Projects/rtems/4.11/bin
--exec_prefix=/home/alan/Projects/rtems/4.11
--includedir=/home/alan/Projects/rtems/4.11/include
--libdir=/home/alan/Projects/rtems/4.11/lib
--libexecdir=/home/alan/Projects/rtems/4.11/libexec
--mandir=/home/alan/Projects/rtems/4.11/share/man
--infodir=/home/alan/Projects/rtems/4.11/share/info
--datadir=/home/alan/Projects/rtems/4.11/share --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=sparc-rtems4.11 --disable-libstdcxx-pch
--with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plugin --enable-languages=c,c++
Thread model: posix
gcc version 4.8.2 20131016 (RTEMS
4.11-RSB(2be445d2aafae21849c5d626b3787e2ab1ac846b)-1,gcc-4.8.2/newlib-2.1.0)
(GCC)
On 1/28/2014 10:38 PM, Chris Johns wrote:
On 29/01/2014 3:46 am, Joel Sherrill wrote:
Hi
Not sure what broke recently but something went wrong. :(
Can anyone build sparc-rtems4.11 tools with the rtems-source-builder
head?
Yes on FreeBSD 9 and on MacOS Mavrick
Build Set: Time 0:08:46.537755
/bin/sh ../../gcc-4.8.2/gcc/mkconfig.sh bconfig.h
/usr/bin/g++ -O2 -pipe
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/tmp/sb-joel/4.11/rtems-sparc/home/joel/rtems-4.11-work/tools/include
-c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.8.2/gcc
-I../../gcc-4.8.2/gcc/build -I../../gcc-4.8.2/gcc/../include
-I../../gcc-4.8.2/gcc/../libcpp/include
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/build/./gmp
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/gmp
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/build/./mpfr
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/mpfr
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/mpc/src
-I../../gcc-4.8.2/gcc/../libdecnumber
-I../../gcc-4.8.2/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-4.8.2/gcc/../libbacktrace\
-DBASEVER=\4.8.2\ -DDATESTAMP=\ 20131016\ \
-DREVISION=\\ \
-DDEVPHASE=\ (RTEMS
4.11-RSB(2be445d2aafae21849c5d626b3787e2ab1ac846b)-1,gcc-4.8.2/newlib-2.1.0)\
Same git hash I am using.
-DPKGVERSION=\(GCC) \ \
-DBUGURL=\http://gcc.gnu.org/bugs.html\ -o build/version.o
../../gcc-4.8.2/gcc/version.c
{standard input}: Assembler messages:
{standard input}:33: Error: unknown pseudo-op: `.value'
{standard input}:183: Error: unknown pseudo-op: `.value'
Anything in your path that could up set up things ?
Do the installed RPMs verify ?
Chris
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
