Opened on 04/08/20 at 14:25:11

Closed on 04/28/20 at 08:41:36

#3944 closed defect (fixed)

qoriq_e500 BSP bset fails

Reported by: Joel Sherrill Owned by: Sebastian Huber
Priority: normal Milestone: 5.1
Component: bsps Version: 5
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

Looks like curl isn't building for the qoriq_e500 bset. This seems like a weird outlier. Any ideas?

checking for gethostbyname for Minix 3... no
checking for gethostbyname for eCos... no
checking for gethostbyname for AmigaOS bsdsocket.library... no
checking for gethostbyname in -lnetwork... no
checking for gethostbyname in -lnet... no
configure: error: couldn't find libraries for gethostbyname()
shell cmd failed: /bin/sh -ex  /home/joel/rtems-work/rtems-source-builder/rtems/build/curl-v7.65.1-powerpc-rtems5-1/do-build
error: building curl-v7.65.1-powerpc-rtems5-1

Change History (14)

comment:1 Changed on 04/09/20 at 08:00:17 by Sebastian Huber

I tried to reproduce this issue and ended up with this local problem:

configure:3441: powerpc-rtems5-gcc --version >&5
powerpc-rtems5-gcc (GCC) 10.0.1 20200407 (experimental) [master revision fd83c39a6be:52ecef68e56:eed9b787db9ab73968ad4e799de5ce3c2eeb2c6c]
Copyright (C) 2020 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.

configure:3452: $? = 0
configure:3441: powerpc-rtems5-gcc -v >&5
Using built-in specs.
COLLECT_GCC=powerpc-rtems5-gcc
COLLECT_LTO_WRAPPER=/opt/rtems/5/lib/gcc/powerpc-rtems5/10.0.1/lto-wrapper
Target: powerpc-rtems5
Configured with: /home/EB/sebastian_h/archive/gcc-git/configure --prefix=/opt/rtems/5 --target=powerpc-rtems5  --verbose --with-gnu-as --with-gnu-ld --with-newlib --disable-libstdcxx-pch --disable-nls --disable-lto --disable-plugin --without-included-gettext --disable-wi
n32-registry --enable-version-specific-runtime-libs --enable-threads --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-newlib-io-c99-formats --enable-libgomp --enable-languages=c,c++
Thread model: rtems
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200407 (experimental) [master revision fd83c39a6be:52ecef68e56:eed9b787db9ab73968ad4e799de5ce3c2eeb2c6c] (GCC) 
configure:3452: $? = 0
configure:3441: powerpc-rtems5-gcc -V >&5
powerpc-rtems5-gcc: error: unrecognized command-line option '-V'
powerpc-rtems5-gcc: fatal error: no input files
compilation terminated.
configure:3452: $? = 1
configure:3441: powerpc-rtems5-gcc -qversion >&5
powerpc-rtems5-gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'?
powerpc-rtems5-gcc: fatal error: no input files
compilation terminated.
configure:3452: $? = 1
configure:3472: checking whether the C compiler works
configure:3494: powerpc-rtems5-gcc -mcpu=8540 -meabi -msdata=sysv -fno-common -mstrict-align -mspe -mabi=spe -mfloat-gprs=double -O2 -g -ffunction-sections -fdata-sections   conftest.c  >&5
powerpc-rtems5-gcc: error: unrecognized command-line option '-mspe'
powerpc-rtems5-gcc: error: unrecognized command-line option '-mabi=spe'
powerpc-rtems5-gcc: error: unrecognized command-line option '-mfloat-gprs=double'

The build picks up the installed compiler and not the new one of the build set. I think this is a known issue. The compiler is not in my $PATH. It was picked up by the default prefix. I will try it again with an empty prefix.

comment:2 Changed on 04/09/20 at 10:18:04 by Sebastian Huber

The configure check doesn't use the linker garbage collection and this leads to undefined symbols:

configure:6802: powerpc-rtems5-gcc -o conftest -qrtems -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/powerpc-rtems5/lib/ -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/powerpc-rtems5/qoriq_e500/lib/ --specs bsp_specs -mcpu=8540 -meabi -msdata=sysv -fno-common -mstrict-align -mspe -mabi=spe -mfloat-gprs=double -O2 -g -ffunction-sections -fdata-sections  -I/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/powerpc-rtems5/qoriq_e500/lib/include -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/powerpc-rtems5/qoriq_e500/lib -mcpu=8540 -meabi -msdata=sysv -mstrict-align -mspe -mabi=spe -mfloat-gprs=double  -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000/ftp/curl/build/rtems/bset-test/lib conftest.c -lbsd -lm -lz -lrtemsdefaultconfig >&5
/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/bin/../lib/gcc/powerpc-rtems5/7.5.0/../../../../powerpc-rtems5/bin/ld: /scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/powerpc-rtems5/qoriq_e500/lib/libbsd.a(ofw_subr.c.18.o): in function `_bsd_ofw_parse_bootargs':
/scratch/git-rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/powerpc-rtems5-qoriq_e500-default/../../freebsd/sys/dev/ofw/ofw_subr.c:207: undefined reference to `boot_parse_cmdline'
/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/bin/../lib/gcc/powerpc-rtems5/7.5.0/../../../../powerpc-rtems5/bin/ld: /scratch/git-rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/powerpc-rtems5-qoriq_e500-default/../../freebsd/sys/dev/ofw/ofw_subr.c:207: undefined reference to `boothowto'
/scratch/git-rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/powerpc-rtems5-qoriq_e500-default/../../freebsd/sys/dev/ofw/ofw_subr.c:207:(.text._bsd_ofw_parse_bootargs+0x4a): unresolvable R_PPC_SDAREL16 relocation against symbol `boothowto'
/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/bin/../lib/gcc/powerpc-rtems5/7.5.0/../../../../powerpc-rtems5/bin/ld: /scratch/git-rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/powerpc-rtems5-qoriq_e500-default/../../freebsd/sys/dev/ofw/ofw_subr.c:207: undefined reference to `boothowto'
/scratch/git-rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/powerpc-rtems5-qoriq_e500-default/../../freebsd/sys/dev/ofw/ofw_subr.c:207:(.text._bsd_ofw_parse_bootargs+0x5a): unresolvable R_PPC_SDAREL16 relocation against symbol `boothowto'

comment:3 Changed on 04/09/20 at 12:01:34 by Sebastian Huber

I think the root cause for this and similar issues is that we have no reliable way to get the essential tool flags of an installed BSP. The new build system is supposed to fix this.

Last edited on 04/09/20 at 12:01:58 by Sebastian Huber (previous) (diff)

comment:4 Changed on 04/12/20 at 16:13:52 by Sebastian Huber

Why don't we add -Wl,--gc-sections to the standard linker flags?

comment:5 in reply to:  1 Changed on 04/28/20 at 05:13:43 by Chris Johns

Replying to Sebastian Huber:

The build picks up the installed compiler and not the new one of the build set. I think this is a known issue. The compiler is not in my $PATH. It was picked up by the default prefix. I will try it again with an empty prefix.

I am not sure how the PATH is being set. The prepend path is set here ...
​https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/setbuilder.py#n422
... and this is the staging area. The build module does not play with the path and the defaults handles the prepend and postpend and extras ...
​https://git.rtems.org/rtems-source-builder/tree/source-builder/defaults.mc#n267
I am confused. Maybe using --trace and inspecting the variables would highlight the issue.

Is there something in gcc causing the prefix to used?

comment:6 in reply to:  4 Changed on 04/28/20 at 05:15:38 by Chris Johns

Replying to Sebastian Huber:

Why don't we add -Wl,--gc-sections to the standard linker flags?

Is this issue closed? I have been building the kernel and libbsd with the RSB as separate steps for the e500 and e6500_32 are did not see any failures.

comment:7 Changed on 04/28/20 at 05:29:54 by Sebastian Huber

The error was in curl. I sent a patch to fix this issue:
​https://lists.rtems.org/pipermail/devel/2020-April/059305.html

comment:8 Changed on 04/28/20 at 06:29:26 by Chris Johns

Can we close the ticket?

comment:9 Changed on 04/28/20 at 06:50:26 by Sebastian Huber

The patch is not checked in, you wanted to adjust it a bit:
​https://lists.rtems.org/pipermail/devel/2020-April/059311.html

comment:10 Changed on 04/28/20 at 06:51:40 by Sebastian Huber

I can send also a v2 if you like, I just found it would be easier if you adjust it yourself.

comment:11 Changed on 04/28/20 at 07:35:53 by Chris Johns

Oh, I am sorry. I will have a look.

comment:12 Changed on 04/28/20 at 07:50:25 by Chris Johns

Does rtems_waf need the change as well? Is libbsd fixed?

comment:13 Changed on 04/28/20 at 07:55:04 by Sebastian Huber

Th rtems_waf and thus libbsd have another workaround to enable the linker garbage collection.

comment:14 Changed on 04/28/20 at 08:41:36 by Chris Johns <chrisj@…>

Resolution: → fixed
Status: assigned → closed

In 13e4dfd/rtems-source-builder:

rtems-bsb: Use linker garbage collection for BSP based builds

Close #3944.

Note: See TracTickets for help on using tickets.