MIPS build requires native expat lib (Was: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake)
Chris Johns
chrisj at rtems.org
Thu Apr 20 23:48:15 UTC 2023
On 21/4/2023 2:53 am, Frank Kühndel wrote:
> Hi Chris,
>
> I compared the successful Debian-11 MIPS build with the failing AlmaLinux MIPS
> build.
>
> The Debian 11 container has a native "expat.h" and "libexpat.a" installed (and
> the source-builder uses
> "rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include/gmp.h"):
This is what I suspected. It seems like the paths are not right for the internal
staged libraries and I suspect my test systems has the header installed.
>
> ~~~~
> minna at e7a01fbe81fa:~/src$ find /usr -name expat.h
> /usr/include/expat.h
> minna at e7a01fbe81fa:~/src$ find /usr -name libexpat.\*
> /usr/lib/x86_64-linux-gnu/libexpat.so
> /usr/lib/x86_64-linux-gnu/libexpat.a
> ~~~~
>
> With other words, the build on Debian is only successful because it uses the
> native "expat" from the OS. On Almalinux it is not installed so it fails. (The
> "expat" on Debian must be pulled in by some dependency from other needed packages.)
>
> The "6/rtems-mips.bset" build "gmp" and "gdb" twice but "expat" only once. In
> "tools/rtems-default-tools.bset" "gmp", "expat" and "gdb" are build the first time:
The expat build is not internal and so this could be related. I made changes to
fix the internal builds and that may have broken the external staged build.
This raises a couple of questions:
1. Should expat be built if present on the system?
2. Should expat be an internal build?
Expat was added before I supported internal builds.
>
> ~~~~
> %{with_rtems_dtc}
> %{with_rtems_expat}
> %{with_rtems_gmp}
> %{with_rtems_gsed}
> %{with_rtems_texinfo}
> %{with_rtems_gdb}
> %{with_rtems_binutils}
> %{with_rtems_gcc}
> %{with_rtems_tools}
> ~~~~
>
> According to the log, after executing "tools/rtems-tools-6.cfg" there is a
> clean-up and all the above tools are cleaned away, including "gmp", "expat" and
> "gdb", for example "expat":
>
> ~~~~
> cleaning: expat-2.4.8-x86_64-linux-gnu-1
> [...]
> cleanup:
> /home/minna/src/rtems-source-builder/rtems/build/tmp/expat-2.4.8-x86_64-linux-gnu-1-1000
> removing:
> /home/minna/src/rtems-source-builder/rtems/build/tmp/expat-2.4.8-x86_64-linux-gnu-1-1000
> cleanup:
> /home/minna/src/rtems-source-builder/rtems/build/expat-2.4.8-x86_64-linux-gnu-1
> removing:
> /home/minna/src/rtems-source-builder/rtems/build/expat-2.4.8-x86_64-linux-gnu-1
> cleanup:
> /home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-default-tools
> removing:
> /home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-default-tools
> ~~~~
>
> This is why it cannot be found later on and it is not in the remaining files.
> Afterwards "tools/rtems-mipstx39-gdb.bset" build "gmp" and "gdb" again but not
> "expat":
>
> ~~~~
> devel/gmp-6.2.1
> tools/rtems-gdb-13.1
> ~~~~
>
> This is the reason why this second "gdb" build finds "gmp" in
> "rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include/gmp.h" but not "expat.h". Yet, a copy of the whole stuff from the earlier "tools/rtems-default-tools.bset" build is still in the "rtems-source-builder/rtems/build/tmp/sb-1000-staging" tree. (Yet, it looks like that at the end of the "tools/rtems-mipstx39-gdb.bset", the files from second "gmp" build would overwrite the ones from first build in the "sb-1000-staging" tree.
>
> So I believe I am closer to the root of the problem now but I do not know what
> needs to be fixed.
All good. I think I have something solid to work on. I just need to find some
time to do this. It is important so it is high on my unfunded list.
Chris
More information about the devel
mailing list