Bump CMake to 4.2.3 and boost to 1.90

[davidrohr]

No description provided.

[ktf]

@davidrohr actually it seems to fail also on linux. I suspect this is the old issue which we patched on our side. Do you see it when running locally?

[davidrohr]

@davidrohr actually it seems to fail also on linux. I suspect this is the old issue which we patched on our side. Do you see it when running locally?

@ktf : You refer to

In file included from /Volumes/build/alice-ci-workdir/alidist-o2/sw/osx_arm64/boost/v1.90.0-local3/include/boost/histogram/indexed.hpp:16:
/Volumes/build/alice-ci-workdir/alidist-o2/sw/osx_arm64/boost/v1.90.0-local3/include/boost/histogram/detail/operators.hpp:48:14: error: use of overloaded operator '>' is ambiguous (with operand types 'const boost::histogram::indexed_range<boost::histogram::histogram<std::vector<boost::histogram::axis::variant<boost::histogram::axis::regular<float, boost::use_default, boost::use_default, boost::histogram::axis::option::bitset<0>>, boost::histogram::axis::integer<int, boost::use_default, boost::histogram::axis::option::bitset<0>>>>>>::accessor' and 'const boost::histogram::unlimited_storage<>::reference')
   48 |     return b > a;
      |            ~ ^ ~
/Volumes/build/alice-ci-workdir/alidist-o2/sw/osx_arm64/boost/v1.90.0-local3/include/boost/histogram/indexed.hpp:191:20: note: in instantiation of function template specialization 'boost::histogram::detail::operator<<boost::histogram::unlimited_storage<>::reference>' requested here

No, I do not see it on Linux locally on my laptop, and also the Linux CI here seems ok. They are randomly failing when rerunning, but all the Linux CIs have already been green in this PR.

[ktf]

@davidrohr , no I meant the one about boost::interprocess:

[17996:B]: [03:54:34][STATE] Exiting FairMQ state machine
[17996:B]: [03:54:34][FATAL] error while setting up workflow in o2-framework-crashing-workflow: Could not initialize shared memory transport: Failed to create/open shared memory segment 'fmq_2251b784_m_0': boost::interprocess_exception::library_error
[17996:B]: terminate called after throwing an instance of 'o2::framework::RuntimeErrorRef'

I suspect this is the container enforces limits correctly issue we patched around in the previous version of boost.

[davidrohr]

I suspect this is the container enforces limits correctly issue we patched around in the previous version of boost.

Ah, that could be. But then it happens randomly, since this has been green before. Only the MacOS CI was red few days ago.
I will check what that patch did exactly and if we can still apply it.

[ehellbar]

@davidrohr the issue on the EPN was indeed related to the shm manager. Using the same O2PDPSuite for the shm-manager locally or for the service on staging, everything works fine.

[ktf]

@nzardosh just confirmed for jet everything seems fine as well. Once the current issues with jenkins are fixed, I would go ahead and merge this.

[pzhristov]

@alisw/dataflow-experts Do you have any news?

[davidrohr]

@ktf : validation by FLPs are done: https://its.cern.ch/jira/browse/OCONF-907
I think we can merge it. Do you want to synchronize with the new boost, or we just go ahead with this?

[ktf]

Let's merge this and then we think about it.

[vkucera]

The symlink lib -> lib64 is not relocated which is currently breaking the AliPhysics CI builds:

lib -> /sw/INSTALLROOT/6f8bcece55616f5b23671770a825fc8e1249b05f/slc7_x86-64/treelite/df6a892b7faf532aea13bacc0f30b8a4743f82cf-local1/lib64

[vkucera]

Suggested change

	[[ -d $INSTALLROOT/lib64 ]] && [[ ! -d $INSTALLROOT/lib ]] && ln -sf ${INSTALLROOT}/lib64 $INSTALLROOT/lib
	[[ -d $INSTALLROOT/lib64 ]] && [[ ! -d $INSTALLROOT/lib ]] && ln -sf lib64 $INSTALLROOT/lib

I guess a relative link should fix it.

[ktf]

There is actually a way to tell CMake to use lib rather than lib64. I would use that. @singiamtel can you have a look?

[davidrohr]

I only vaguely remember, but I think I tried the CMake libdir setting, and it failed for some reason, that is why I put the symlink. We can of course try to fix it the "correct" way, but if that causes issues, I would just create a relative symlink.

[vkucera]

Let's see if #6213 fixes it.