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.kuehn...@embedded-brains.de>
>> Date:
>> 4/18/23, 12:16
>>
>> To:
>> chr...@rtems.org, devel@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.kuehn...@embedded-brains.de>
>>> Date:
>>> 4/18/23, 11:54
>>>
>>> To:
>>> chr...@rtems.org, devel@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, chr...@rtems.org wrote:
>>>> From: Chris Johns<chr...@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.kuehn...@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@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.kuehn...@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@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
