boost-1.86.0 - broken patch is causing segfault

[Bruce Dubbs]

New minor version.

[Douglas R. Reno]

The release notes are quite extensive. They can be found at ​https://www.boost.org/users/history/version_1_86_0.html

There were no new libraries added by this version. The only removals were from some experimental features in the MySQL module.

[Douglas R. Reno]

The build fails of NumPy 2.0.0 or later is installed:

libs/python/src/numpy/dtype.cpp: In member function ‘int boost::python::numpy::dtype::get_itemsize() const’: libs/python/src/numpy/dtype.cpp:101:83: error: ‘PyArray_Descr’ {aka ‘struct _PyArray_Descr’} has no member named ‘elsize’

101 | int dtype::get_itemsize() const { return reinterpret_cast<PyArray_Descr*>(ptr())->elsize;}

| ^~

"g++" -fvisibility-inlines-hidden -fPIC -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_NUMPY_SOURCE -DNDEBUG -I"." -I"/usr/include/python3.12" -I"/usr/lib/python3.12/site-packages/numpy/_core/include" -c -o "bin.v2/libs/python/build/gcc-14/release/x86_64/python-3.12/threading-multi/visibility-hidden/numpy/dtype.o" "libs/python/src/numpy/dtype.cpp"

...failed gcc.compile.c++ bin.v2/libs/python/build/gcc-14/release/x86_64/python-3.12/threading-multi/visibility-hidden/numpy/dtype.o...

This looks to be fixed by two commits upstream - ​https://github.com/boostorg/python/commit/0474de0f6cc9c6e7230aeb7164af2f7e4ccf74bf and ​https://github.com/boostorg/python/commit/99a5352b5cf790c559a7b976c1ba99520431d9d1

[martyj19]

I have attached a patch to solve a build failure for libreoffice in the embedded libcmis that is caused by a function prototype change.

[thomas]

for my local i686 system, i had to add

sed -e "s/defined(__MINGW32__)/& || defined(__i386__)/" \
    -i ./libs/stacktrace/src/exception_headers.h

which i applied unconditionally (as x86_64 is handled there anyhow). Leaving that sed out, it FTBFS on i686 with

libs/stacktrace/build/../src/from_exception.cpp:170:2: Fehler: #error On this platform memory
leaks are possible if capturing stacktrace from exceptions is enabled and exceptions are thrown
concurrently and libc++ runtime is used. Define
`BOOST_STACKTRACE_LIBCXX_RUNTIME_MAY_CAUSE_MEMORY_LEAK` to suppress this error if the library
would not be used with libc++ runtime (for example, it would be only used with GCC runtime).
Otherwise, disable the boost_stacktrace_from_exception library build (for example by `./b2
boost.stacktrace.from_exception=off` option).

After digging a bit around in the internet, i came across the above solution (starting at ​https://github.com/boostorg/stacktrace/issues/163 and following the link to the source). Seems to work pretty fine.

[Douglas R. Reno]

This is the update that keeps on giving. :)

I'll get that patch for Libreoffice in as well as the sed in with this update as well.

[martyj19]

Patch to libreoffice to solve a build failure with boost 1.86.0

[Douglas R. Reno]

Fixed at 61678cd2ad2593744ce790746e1d415620fca5c1

[martyj19]

The book has picked up a faulty version of the libreoffice patch. I discovered that it was missing an "&" and reuploaded it. The version in the book would cause a segfault if it were executed.

[Xi Ruoyao]

In the future if a similar issue happens again please upload a new attachment (named libreoffice-24.2.5.2-boost_1.86.0_build_failure-2.patch) to avoid confusion.

[Xi Ruoyao]

And generally people should be more careful when casting a pointer (this is the third time a broken pointer casting is proposed for BLFS in this development cycle).

[martyj19]

Replying to Xi Ruoyao:

And generally people should be more careful when casting a pointer (this is the third time a broken pointer casting is proposed for BLFS in this development cycle).

It isn't helpful that creating patches to external tarballs is as difficult as it is and the mistake was introduced during that process. In this case the corrected file was uploaded within a few minutes and I assumed that Douglas hadn't yet grabbed the file. I take your point that it could have been more obvious that it was updated, which I wasn't sure was necessary when I did it.

You are correct that people should be as careful as they possibly can be. Sometimes even with the best of intentions people make mistakes that creep into a release. See for example "LoongArch DT_RELR fixes." I spent many years on a project where making a mistake was extremely expensive and I am as sensitive to this as anyone.

[Douglas R. Reno]

I'll get to this first thing this morning. Thank you for the heads up, Marty!

[Douglas R. Reno]

Fixed at 8bb252db612b0dc296f7c085fc43e74f1153998a