From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] boost: Fix rootfile entries that referred to python3.8 instead of 3.10
Date: Thu, 12 May 2022 13:33:00 +0200 [thread overview]
Message-ID: <707d4f4d-5d74-44a3-2f87-9cbffb215421@ipfire.org> (raw)
In-Reply-To: <24C70DAE-D9B5-4910-BE96-5FAC94D9F769@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 10747 bytes --]
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(a)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 2
>>>>>
>>>>> I 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(a)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(a)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
>
next prev parent reply other threads:[~2022-05-12 11:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9ec697a6-9a87-535a-be15-9e322b44a9aa@ipfire.org>
2022-05-08 14:10 ` Adolf Belka
2022-05-08 21:05 ` Adolf Belka
2022-05-12 9:27 ` Michael Tremer
2022-05-12 11:33 ` Adolf Belka [this message]
2022-05-04 11:14 Adolf Belka
2022-05-04 19:43 ` Peter Müller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=707d4f4d-5d74-44a3-2f87-9cbffb215421@ipfire.org \
--to=adolf.belka@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox