Created attachment 35473 [details] RSB Report for RTEMS 4.1 MIPS failure on FreeBSD. Build RTEMS 4.11 MIP tool set fails on FreeBSD. The attached log file shows the error. The configure command line is: ../gcc-4.9.2/configure --prefix=/opt/work/rtems/4.11 --bindir=/opt/work/rtems/4.11/bin --exec_prefix=/opt/work/rtems/4.11 --includedir=/opt/work/rtems/4.11/include --libdir=/opt/work/rtems/4.11/lib --libexecdir=/opt/work/rtems/4.11/libexec --mandir=/opt/work/rtems/4.11/share/man --infodir=/opt/work/rtems/4.11/share/info --datadir=/opt/work/rtems/4.11/share --build=x86_64-freebsd10.1 --host=x86_64-freebsd10.1 --target=m32r-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++ newlib is the newlib-2.2.0-20150423 snapshot provided by Jeff this week. I tracked the issue down to the sed commands that handle the file sets for each multilib variant but I started to get lost. Sed is not a natural language for me and I do not a linux box around to see what is expected.
Have you tried GNU sed rather than BSD sed?
(In reply to Andrew Pinski from comment #1) > Have you tried GNU sed rather than BSD sed? No and a good idea. I will. FYI I tend to keep the machines used for testing builds clean and minimal to minimised the interactions. It makes supporting users easier.
Built GNU sed from source and added to my path: ruru rtems $ sed --version GNU sed version 4.2 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, to the extent permitted by law. The build was successful.
Using GNU sed is required so closing as invalid.
I have decided to revisit this bug and see what the issue is. I cannot see how to reopen the issue? Using GNU sed on FreeBSD is not straight forward. It requires either building by hand to a custom prefix with special paths or adding links to the packaged GNU sed executable called `gsed` and that could effect other parts of the system. The GCC Makefiles use `sed` directly so it cannot be specified to configure or make. I tracked the issue down to `libgcc/config/t-hardfd` and the make call ` hardfp_defines_for`. For reasons I could not figure out the FreeBSD sed does not like `|` in the branch `(sf|df)`. I have no idea why. Maybe someone who understands this part of sed better than me can spot the problem. As a result I implemented the functionality in awk. I attach a patch I have tested on FreeBSD 11.0 and debian 8.7 with the mips-rtems4.12 target with no errors.
Created attachment 41380 [details] Use awk to create compile args as sed is not working on FreeBSD
Is this bug the same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097 As that bug states this issue is present on darwin and the patch I posted fixes the issues on that host.
Yes. I think they are exactly the same. --joel On Sep 9, 2017, at 5:50 PM, chrisj at rtems dot org <gcc-bugzilla@gcc.gnu.org<mailto:gcc-bugzilla@gcc.gnu.org>> wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032 --- Comment #7 from Chris Johns <chrisj at rtems dot org> --- Is this bug the same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097 As that bug states this issue is present on darwin and the patch I posted fixes the issues on that host.
Yes. I believe it is the same bug. Use of GNU sed specifics on a system without GNU sed. I don't know if that changes the resolution.
(In reply to Joel Sherrill from comment #9) > Yes. I believe it is the same bug. Use of GNU sed specifics on a system > without GNU sed. > > I don't know if that changes the resolution. For this bug that is true however the other bug is still open and so the issue is not resolved so I hope there is a chance someone with a suitable level of sed knowledge may take a look to see if the use can be made to be universal or highlight a bug in BSD sed. I had a look but I could not determine if the issue is in the sed expressions used or BSD sed.
(In reply to Chris Johns from comment #10) > (In reply to Joel Sherrill from comment #9) > > Yes. I believe it is the same bug. Use of GNU sed specifics on a system > > without GNU sed. > > > > I don't know if that changes the resolution. > > For this bug that is true however the other bug is still open and so the > issue is not resolved so I hope there is a chance someone with a suitable > level of sed knowledge may take a look to see if the use can be made to be > universal or highlight a bug in BSD sed. I had a look but I could not > determine if the issue is in the sed expressions used or BSD sed. I opened a FreeBSD bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235293