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@e7a01fbe81fa:~/src$ find /usr -name expat.h > /usr/include/expat.h > minna@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel