[rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake
Frank Kühndel
frank.kuehndel at embedded-brains.de
Wed Apr 19 13:26:31 UTC 2023
Hello Chris,
thanks for the introduction to package build. On AlmaLinux the file
rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build/gdb/config.log
(attached) contains this error:
~~~~
configure:21340: gcc -O2 -g -pipe
-I/home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include
-o conftest -g -O2
-L/home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib
conftest.c -lm -ldl -lexpat >&5
conftest.c:53:10: fatal error: expat.h: No such file or directory
#include "expat.h"
^~~~~~~~~
compilation terminated.
~~~~
The include file and the library would be in
rtems-source-builder/rtems/build/tmp/sb-1000-staging/include/expat.h
rtems-source-builder/rtems/build/tmp/sb-1000-staging/lib/libexpat.a
rtems-source-builder/rtems/build/tmp/sb-1000-staging/lib/libexpat.la
The directories mentioned in the gcc-invokation contain only
84 -rw-r--r-- 1 minna users 84084 Apr 19 13:19
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include/gmp.h
and
6952 -rw-r--r-- 1 minna users 7115648 Apr 19 13:19
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/libgmp.a
4 -rwxr-xr-x 1 minna users 968 Apr 19 13:19
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/libgmp.la
4 drwxr-xr-x 2 minna users 4096 Apr 19 13:19
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/pkgconfig
4 -rw-r--r-- 1 minna users 257 Apr 19 13:19
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/pkgconfig/gmp.pc
Just for the records:
PARAM_ARCH="mips"
PARAM_RTEMS_VERSION="6"
PARAM_RSB_GIT_COMMIT="origin/master"
GIT_HEAD="ae00c59541f21d8c459a33774efade80085c9b4a"
CONT_OS_VERSION_ID="8.7"
CONT_OS_ID="almalinux"
Let me know if you need more information. If you have a patch, I will be
happy to feed our CI with it.
Greetings,
Frank
On 4/19/23 01:48, Chris Johns wrote:
> Subject:
> Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by
> mistake
> From:
> Chris Johns <chrisj at rtems.org>
> Date:
> 4/19/23, 01:48
>
> To:
> Frank Kühndel <frank.kuehndel at embedded-brains.de>, devel at rtems.org
>
>
> Hi Frank,
>
> Thanks for reporting this and looking into it. MIPS seems to need extra help.
>
> I will try and answer the question you raised earlier about what is happening
> with the packages being built. It is a little involved...
>
> Packages we build like gcc and gdb are adding GMP and MPFR into their builds for
> reasons internal to their projects. We have handled this with a per package
> approach. I added GMP as an internal package (more on this later) a while ago
> and gcc symlink'ed in the packages it needed from sources local to that project.
> The gcc approach recently broke due to GMP on MacOS aarch64 failing to pass its
> self test unless you disabled the assembler support. As a result I moved the
> MPFR build out of gcc to an internal package build where we can control what
> happens.
>
> Internal packages in the RSB was added when staging was added. Staging is a
> function of building vertical stacks of packages. For example GDB sits above
> expat and gmp and so those are built and staged before GDB is built. No part of
> a build can be installed into the prefix until all the pieces build. If you did
> install pieces as the build progressed you would end up with weird and broken
> installs under a prefix if the build failed. You also end up with side effects
> of anything in the prefix effecting the build. An internal package is staged to
> a special path that is not copied to the prefix. An internal package is built,
> staged and used but never installed.
>
> I feel over time we will move all symlink'ed packages other than newlib out of
> the gcc build tree because we can control the build and they are used in more
> than one tool.
>
> Back to this failure. Can you please look in the config.log to see if the reason
> for the failure can be seen?
>
> Chris
>
> On 18/4/2023 10:51 pm, Frank Kühndel wrote:
>> Hello Chris,
>>
>> I indeed looked into the wrong build. Analyzing the correct results
>> unfortunately reveals that the issue persists in the current build the way I
>> described it in my earlier mail. I checked
>>
>> git head "ae00c59541f21d8c459a33774efade80085c9b4a" and MIPS for
>>
>> * "openSUSE Leap 15.4" -- failed
>> * "Fedora Linux 37 (Container Image)" -- failed
>> * "AlmaLinux 8.7 (Stone Smilodon)" -- failed
>> * "Debian GNU/Linux 11 (bullseye)" -- OK
>> * "Ubuntu 22.04.2 LTS" -- OK
>> * "Ubuntu 20.04.5 LTS" -- OK
>>
>> This is an excerpt from AlmaLinux build log:
>>
>> ../source-builder/sb-set-builder --rtems-version 6 --prefix /opt/
>> rtems/6 --with_cxx --with_objc --jobs=12 --trace --log
>> /home/minna/src/rtems6-devtools-mips-6+git.2312.ae00c59541.x86_64_sb-set-builder.log 6/rtems-mips
>> Python: 3.6.8 (default, Feb 21 2023, 16:34:36) [GCC 8.5.0 20210514 (Red Hat
>> 8.5.0-16)]
>>
>> [...]
>> checking whether to use expat... yes
>> checking for libexpat... no
>> configure: error: expat is missing or unusable
>> make[2]: *** [Makefile:11803: configure-gdb] Error 1
>> make[2]: Leaving directory
>> '/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'
>> make[1]: *** [Makefile:1004: all] Error 2
>> make[1]: Leaving directory
>> '/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'
>> shell cmd failed: /bin/sh -ex
>> /home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/do-build
>> error: building mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1
>> See error report: rsb-report-mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1.txt
>> Note: In some cases the error appears only in
>> the complete build log (see --log option)
>>
>> As I wrote before, this is only to inform you in case your are interested. I do
>> not need a fix.
>>
>> Sorry again for the confusion and greetings,
>> Frank
>>
>> On 4/18/23 12:16, Frank Kühndel wrote:
>>> Subject:
>>> Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake
>>> From:
>>> Frank Kühndel<frank.kuehndel at embedded-brains.de>
>>> Date:
>>> 4/18/23, 12:16
>>>
>>> To:
>>> chrisj at rtems.org,devel at rtems.org
>>>
>>>
>>> Hello Chris,
>>>
>>> I mistakenly looked into to the wrong build. I am currently checking this
>>> again. This is most likely an error of mine.
>>>
>>> Sorry for the confusion
>>> Frank
>>>
>>> On 4/18/23 11:54, Frank Kühndel wrote:
>>>> Subject:
>>>> Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake
>>>> From:
>>>> Frank Kühndel<frank.kuehndel at embedded-brains.de>
>>>> Date:
>>>> 4/18/23, 11:54
>>>>
>>>> To:
>>>> chrisj at rtems.org,devel at rtems.org
>>>>
>>>>
>>>> Hello Chris,
>>>>
>>>> first of all, I do not use MIPS. So I have no troubles if it builds or not. I
>>>> only want to report an observation from our continuous integration (CI) server.
>>>>
>>>> In the past the MIPS builds failed due to the fact that the packages
>>>> (lib)gmp-devel and (lib)expat-devel where not installed in the containers. A
>>>> minor nuisance because all other RTEMS tools do build without these. I never
>>>> understood why in case of MIPS the host must provide native packages given
>>>> the fact that "gmp" and "expat" are apparently configured in the MIPS "bset".
>>>>
>>>> You recent patch thankfully improved the situation. Our CI builds MIPS on
>>>> Debian and Ubuntu, now. I do not fully understand why but I believe those
>>>> where the distros where the native gmp-devel packet was needed before your
>>>> patch.
>>>>
>>>> For Alamalinux, Fedora and OpenSUSE the MIPS build still fails (apparently
>>>> for the same reason they failed before your patch):
>>>>
>>>> [...]
>>>> checking whether to use expat... yes
>>>> checking for libexpat... no
>>>> configure: error: expat is missing or unusable
>>>> make[2]: *** [Makefile:11803: configure-gdb] Error 1
>>>> make[2]: Leaving directory
>>>> '/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'
>>>> make[1]: *** [Makefile:1004: all] Error 2
>>>> make[1]: Leaving directory
>>>> '/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'
>>>> shell cmd failed: /bin/sh -ex
>>>> /home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/do-build
>>>> error: building mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1
>>>> See error report: rsb-report-mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1.txt
>>>> Note: In some cases the error appears only in
>>>> the complete build log (see --log option)
>>>>
>>>>
>>>> This is the end of the build log from Alamlinux 8.7. The error logs from the
>>>> other distributions are identical.
>>>>
>>>> As I indicated before, you do not need to look into this or fix this issue
>>>> for me as I do not use MIPS and I can easily add the required
>>>> (lib)expat-devel packet to those containers. I just write because I thought
>>>> you maybe interested in knowing this detail.
>>>>
>>>> Greetings
>>>> Frank
>>>>
>>>>
>>>> On 4/15/23 00:56,chrisj at rtems.org wrote:
>>>>> From: Chris Johns<chrisj at rtems.org>
>>>>>
>>>>> - Build GNU sed for hosts that it is not installed on for the MIPS
>>>>> tools.
>>>>> ---
>>>>> rtems/config/tools/rtems-default-tools.bset | 3 ++-
>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/rtems/config/tools/rtems-default-tools.bset
>>>>> b/rtems/config/tools/rtems-default-tools.bset
>>>>> index 0291786..35c9235 100644
>>>>> --- a/rtems/config/tools/rtems-default-tools.bset
>>>>> +++ b/rtems/config/tools/rtems-default-tools.bset
>>>>> @@ -6,7 +6,7 @@
>>>>> # available
>>>>> #
>>>>> %define _internal_gsed_path %{_tmpinternal}
>>>>> -%defineifnot with_rtems_gmp textproc/gsed-internal
>>>>> +%defineifnot with_rtems_gsed textproc/gsed-internal
>>>>> # GNU tools need texinfo for makeinfo to build documentation
>>>>> %define _internal_texinfo_path %{_tmpinternal}
>>>>> @@ -21,6 +21,7 @@
>>>>> %{with_rtems_dtc}
>>>>> %{with_rtems_expat}
>>>>> %{with_rtems_gmp}
>>>>> +%{with_rtems_gsed}
>>>>> %{with_rtems_texinfo}
>>>>> %{with_rtems_gdb}
>>>>> %{with_rtems_binutils}
>>>>> -- 2.37.1
>>>> --
>>>> embedded brains GmbH & Co. KG
>>>> Herr Frank KÜHNDEL
>>>> Dornierstr. 4
>>>> 82178 Puchheim
>>>> Germany
>>>> email:frank.kuehndel at embedded-brains.de
>>>> phone: +49-89-18 94 741 - 23
>>>> mobile: +49-176-15 22 06 - 11
>>>>
>>>> Registergericht: Amtsgericht München
>>>> Registernummer: HRA 117265
>>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>>> Unsere Datenschutzerklärung finden Sie hier:
>>>> https://embedded-brains.de/datenschutzerklaerung/
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>> --
>>> embedded brains GmbH & Co. KG
>>> Herr Frank KÜHNDEL
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email:frank.kuehndel at embedded-brains.de
>>> phone: +49-89-18 94 741 - 23
>>> mobile: +49-176-15 22 06 - 11
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRA 117265
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: text/x-log
Size: 91666 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230419/5de5eba9/attachment-0001.bin>
More information about the devel
mailing list