Bug 66032 - RTEMS MIPS build fails on FreeBSD
Summary: RTEMS MIPS build fails on FreeBSD
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libgcc (show other bugs)
Version: 4.9.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-06 04:22 UTC by Chris Johns
Modified: 2019-01-29 10:49 UTC (History)
3 users (show)

See Also:
Host: x86_64-freebsd10.1
Target: mips-rtems4.11
Build: x86_64-freebsd10.1
Known to work:
Known to fail:
Last reconfirmed:


Attachments
RSB Report for RTEMS 4.1 MIPS failure on FreeBSD. (5.55 KB, text/plain)
2015-05-06 04:22 UTC, Chris Johns
Details
Use awk to create compile args as sed is not working on FreeBSD (822 bytes, patch)
2017-05-18 04:56 UTC, Chris Johns
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Johns 2015-05-06 04:22:05 UTC
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.
Comment 1 Andrew Pinski 2015-05-06 04:38:16 UTC
Have you tried GNU sed rather than BSD sed?
Comment 2 Chris Johns 2015-05-06 05:06:12 UTC
(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.
Comment 3 Chris Johns 2015-05-06 06:46:01 UTC
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.
Comment 4 Andrew Pinski 2016-08-27 19:07:17 UTC
Using GNU sed is required so closing as invalid.
Comment 5 Chris Johns 2017-05-18 04:53:26 UTC
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.
Comment 6 Chris Johns 2017-05-18 04:56:38 UTC
Created attachment 41380 [details]
Use awk to create compile args as sed is not working on FreeBSD
Comment 7 Chris Johns 2017-09-09 22:50:21 UTC
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.
Comment 8 joel.sherrill 2017-09-09 22:55:24 UTC
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.
Comment 9 Joel Sherrill 2017-09-09 23:06:51 UTC
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.
Comment 10 Chris Johns 2017-09-09 23:33:26 UTC
(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.
Comment 11 Sebastian Huber 2019-01-29 10:49:35 UTC
(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