Hi,
On 12/05/2022 11:27, Michael Tremer wrote:
Hello,
If you need a clean build and you don’t have the capacity to run one by yourself (which you should of course always have :D), then you can download the root files from the nightly builds: https://nightly.ipfire.org
I don't have any problem with capacity to do a clean build. My problem is that when I do a clean build after having done a git pull to have my next repository synced with all the changes from the IPFire one that boost now creates modified files in the rootfile in log without me changing anything related to boost.
I have done a git pull origin next with my next repository and then run ./make clean followed by ./make build and boost still came up with changes for the rootfile. Those are the changes that I did a patch for but that Peter then found broke his build system.
Regards, Adolf
I sometimes do this to easily get root files that differ between architectures, because there is no need then to compile things myself again. I can just download the log file and edit it as I need.
If you haven’t already done so, you can also sign up to the nightly build mailing list and you will get a notification when a build finishes or fails. The fails are very often related to the root files, so it is good to know what went wrong were.
https://lists.ipfire.org/mailman/listinfo/nightly-builds
-Michael
On 8 May 2022, at 22:05, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Peter,
Found an interesting difference between my existing repo and the new one I created. Although it created the 310 versions in the build directory and added them to the log file for boost the cdrom section passed without any problem or error, so even though the build created the 310 version files nothing was flagged in this new git clone.
Probably this is what was happening until a while ago when it started to flag up the boost rootfile on my existing system.
If new lines have been added top the boost logfile I would expect that even if the cdrom section passed that it would flag up "Changes in boost_1_76_0 check rootfile!" but it did not.
Regards,
Adolf.
On 08/05/2022 16:10, Adolf Belka wrote:
Hi Peter,
I realised that I could create a new clone of IPFire next without getting rid of the old one so I did that.
I made no changes to anything and ran a build and it has just built boost, including creating the 310 files
+usr/lib/libboost_python310-mt-x64.so +usr/lib/libboost_python310-mt-x64.so.1.76.0 +usr/lib/libboost_python310-x64.so +usr/lib/libboost_python310-x64.so.1.76.0
+usr/lib/cmake/boost_python-1.76.0/libboost_python-variant-mt-x64-shared-py3.10.cmake +usr/lib/cmake/boost_python-1.76.0/libboost_python-variant-x64-shared-py3.10.cmake
So for me using ipfire clones git it is building the 310 versions and therefore expects to see the .so.1.76.0 lines in the rootfile when it gets to the cdrom stage. The 310 versions are in the build directory and not the 38 ones
Regards,
Adolf.
On 06/05/2022 15:55, Adolf Belka wrote:
Hi Peter,
I have attached at the end of this email the _build.ipfire.log section just for boost from my system. There are sections where it can be seen to be compiling the 310 versions of the libraries. Maybe you could compare that log file with what is created on your build machine for boost. Maybe that can help indicate why yours builds the 38 versions and mine the 310 versions.
Regards,
Adolf.
On 06/05/2022 15:40, Adolf Belka wrote:
Hi Peter,
I saw that you had reverted this change because it didn't work on your build. That is interesting.
Until about a week ago I also had no problems with boost but now with the existing rootfiles each time I do a build in the boost log file it now creates the 310 version and removes the 38 version
+usr/lib/libboost_python310-mt-x64.so +usr/lib/libboost_python310-mt-x64.so.1.76.0 +usr/lib/libboost_python310-x64.so +usr/lib/libboost_python310-x64.so.1.76.0
-usr/lib/libboost_python38-mt-x64.so.1.76.0 -usr/lib/libboost_python38-x64.so.1.76.0
and today when I did a build I got an additional two + lines for the boost rootfile
+usr/lib/cmake/boost_python-1.76.0/libboost_python-variant-mt-x64-shared-py3.10.cmake +usr/lib/cmake/boost_python-1.76.0/libboost_python-variant-x64-shared-py3.10.cmake
These two I did not have before today. Not sure what is happening here.
Because of the above + lines when I get to the cdrom stage I get the following error message
tar: usr/lib/libboost_python38-mt-x64.so.1.76.0: Cannot stat: No such file or directory tar: usr/lib/libboost_python38-x64.so.1.76.0: Cannot stat: No such file or directory tar: Exiting with failure status due to previous errors make: *** [cdrom:156: /usr/src/log/cdrom] Error 2I had thought that because my build was having boost create these files that the same would be happening with everyone else's builds but it looks like not.
The question then is why has it started to do the new rootfiles, which make some sense because they are 310 versions and we are on python-3.10 but why didn't it do it before and why only on my build.
Other than doing a git pull before each build, that I normally do, I haven't done anything else that I can think of to cause this but I may also have done something unintentionally and unknowingly.
So at the moment I need to have the 310 versions in my boost rootfiles or all builds fail at the cdrom stage but I will not create any patches for them while we investigate what is happening.
Any suggestions for what I should look for on my system would be appreciated.
If I have to clear my local git repository and start again with a fresh git clone, then I will do so but would prefer not to because starting again will mean my first build is much longer but, hey ho, if that is needed I will do it.
Regards,
Adolf.
On 04/05/2022 21:43, Peter Müller wrote:
Good catch, thank you!
Reviewed-by: Peter Müller peter.mueller@ipfire.org
> - In Jan 2022 I updated python from 3.8 to 3.10 but I missed that boost had rootfile > entries with python38 in it. > - Running a build just now for another package it got flagged up that the rootfile for > boost had been changed and the logfile now had the entries with python310 instead of > python38 > - Not clear why it only flagged this up now but this patch is to correct that error > - Running find-dependencies on both the pyton38 and python310 versions of the libraries > flagged nothing as being linked to either, so probably lucky with this being missed > first time around. > - Boost will need to be shipped with a Core Update > > Signed-off-by: Adolf Belka adolf.belka@ipfire.org > --- > config/rootfiles/common/aarch64/boost | 8 ++++---- > config/rootfiles/common/armv6l/boost | 8 ++++---- > config/rootfiles/common/x86_64/boost | 8 ++++---- > 3 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/config/rootfiles/common/aarch64/boost b/config/rootfiles/common/aarch64/boost > index 49ff120ab..015dc1458 100644 > --- a/config/rootfiles/common/aarch64/boost > +++ b/config/rootfiles/common/aarch64/boost > @@ -16250,10 +16250,10 @@ usr/lib/libboost_nowide-a64.so.1.76.0 > usr/lib/libboost_prg_exec_monitor-mt-a64.so.1.76.0 > #usr/lib/libboost_prg_exec_monitor-a64.so > usr/lib/libboost_prg_exec_monitor-a64.so.1.76.0 > -#usr/lib/libboost_python38-mt-a64.so > -usr/lib/libboost_python38-mt-a64.so.1.76.0 > -#usr/lib/libboost_python38-a64.so > -usr/lib/libboost_python38-a64.so.1.76.0 > +#usr/lib/libboost_python310-mt-a64.so > +usr/lib/libboost_python310-mt-a64.so.1.76.0 > +#usr/lib/libboost_python310-a64.so > +usr/lib/libboost_python310-a64.so.1.76.0 > #usr/lib/libboost_random-mt-a64.so > usr/lib/libboost_random-mt-a64.so.1.76.0 > #usr/lib/libboost_random-a64.so > diff --git a/config/rootfiles/common/armv6l/boost b/config/rootfiles/common/armv6l/boost > index 80cc4063a..79e9ed3d7 100644 > --- a/config/rootfiles/common/armv6l/boost > +++ b/config/rootfiles/common/armv6l/boost > @@ -16250,10 +16250,10 @@ usr/lib/libboost_nowide-mt-a32.so.1.76.0 > usr/lib/libboost_prg_exec_monitor-a32.so.1.76.0 > #usr/lib/libboost_prg_exec_monitor-mt-a32.so > usr/lib/libboost_prg_exec_monitor-mt-a32.so.1.76.0 > -#usr/lib/libboost_python38-a32.so > -usr/lib/libboost_python38-a32.so.1.76.0 > -#usr/lib/libboost_python38-mt-a32.so > -usr/lib/libboost_python38-mt-a32.so.1.76.0 > +#usr/lib/libboost_python310-a32.so > +usr/lib/libboost_python310-a32.so.1.76.0 > +#usr/lib/libboost_python310-mt-a32.so > +usr/lib/libboost_python310-mt-a32.so.1.76.0 > #usr/lib/libboost_random-a32.so > usr/lib/libboost_random-a32.so.1.76.0 > #usr/lib/libboost_random-mt-a32.so > diff --git a/config/rootfiles/common/x86_64/boost b/config/rootfiles/common/x86_64/boost > index 357dc2d1d..77eef1d0b 100644 > --- a/config/rootfiles/common/x86_64/boost > +++ b/config/rootfiles/common/x86_64/boost > @@ -16250,10 +16250,10 @@ usr/lib/libboost_nowide-x64.so.1.76.0 > usr/lib/libboost_prg_exec_monitor-mt-x64.so.1.76.0 > #usr/lib/libboost_prg_exec_monitor-x64.so > usr/lib/libboost_prg_exec_monitor-x64.so.1.76.0 > -#usr/lib/libboost_python38-mt-x64.so > -usr/lib/libboost_python38-mt-x64.so.1.76.0 > -#usr/lib/libboost_python38-x64.so > -usr/lib/libboost_python38-x64.so.1.76.0 > +#usr/lib/libboost_python310-mt-x64.so > +usr/lib/libboost_python310-mt-x64.so.1.76.0 > +#usr/lib/libboost_python310-x64.so > +usr/lib/libboost_python310-x64.so.1.76.0 > #usr/lib/libboost_random-mt-x64.so > usr/lib/libboost_random-mt-x64.so.1.76.0 > #usr/lib/libboost_random-x64.so