[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] Debian Bullseye build fails, Re: HTCondor 8.8.11 Released
- Date: Tue, 3 Nov 2020 17:16:29 -0600
- From: Tim Theisen <tim@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] Debian Bullseye build fails, Re: HTCondor 8.8.11 Released
I am working on getting HTCondor building for sid/bullseye.
For the focal build, it was gcc 9.3.0.
On 10/26/20 3:17 AM, Steffen Grunewald wrote:
> On Fri, 2020-10-23 at 14:38:04 +0200, Steffen Grunewald wrote:
>> On Fri, 2020-10-23 at 13:13:42 +0200, Steffen Grunewald wrote:
>>> In a Buster build, I get
>>> -- Configuring for Debian package on Debian-10--amd64
>>> while for Bullseye, this reads
>>> -- Configuring for Debian package on Debian---amd64
>>> - apparently "testing" doesn't have all the /etc/os-release information in
>>> place yet?
>>> ... but this leads, in astraight manner, to
>>> -- SYSTEM_NAME: Debian-
>>> -- Boost components: python;unit_test_framework
>>> CMake Error at /usr/lib/x86_64-linux-gnu/cmake/BoostDetectToolset-1.71.0.cmake:8 (list):
>>> list index: 1 out of range (-1, 0)
>>> Call Stack (most recent call first):
>>> /usr/lib/x86_64-linux-gnu/cmake/boost_python-1.71.0/boost_python-config.cmake:24 (include)
>>> /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:117 (find_package)
>>> /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:182 (boost_find_component)
>>> /usr/share/cmake-3.18/Modules/FindBoost.cmake:448 (find_package)
>>> externals/bundles/boost/1.66.0/CMakeLists.txt:88 (find_package)
>>> Is there a way to outsmart Debian version detection? Unlike Ubuntu Focal, Bullseye
>>> isn't official yet...
>> It was a wise choice for the naming of Debian unstable: that Sid guy has the
>> potential to destroy everything.
>> build/cmake/macros/SystemSpecificInformations.cmake seems to be the place to go.
>> I'm not familiar with CMake syntax, but there's a special case where /etc/issue
>> has "Debian .*/sid" in it (and no version number like officially released distros).
>> It should be sufficient to use something like 99.9 in that case, and only if there's
>> no "sid" match in the "Debian" line use the existing code from lines 171ff.
> I did it, and indeed got a 'Debian-99' string, but unfortunately this did not resolve
> the primary issue.
> Having a closer look into BoostDetectToolset-1.71.0.cmake, this seems to be an issue
> with identifying the GCC - but why didn't this show up for others? In particular,
> why didn't this stop the "focal" build? Since there's no build log publicly available,
> perhaps Tim can tell me which GCC version had been used?
> I also went back and walked through the build logs of previous versions - while GCC 9
> was still current, there had been no problems, but this was also with boost 1.67.
> 8.8.9 failed for different reasons, and for 8.8.10 I had already reported the issue
> but haven't seen a response since.
> How to proceed?
> - S
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> The archives can be found at:
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736