Created attachment 231887 [details] full build log % cat /var/db/ports/editors_libreoffice/options | grep -v '^#' _OPTIONS_READ=libreoffice-7.2.5.2 _FILE_COMPLETE_OPTIONS_LIST=COINMP CUPS DOCS GNOME GTK3 GTK4 JAVA KF5 LTO MARIADB MMEDIA PGSQL QT5 SDK TEST WEBDAV OPTIONS_FILE_UNSET+=COINMP OPTIONS_FILE_UNSET+=CUPS OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_UNSET+=GNOME OPTIONS_FILE_SET+=GTK3 OPTIONS_FILE_UNSET+=GTK4 OPTIONS_FILE_UNSET+=JAVA OPTIONS_FILE_UNSET+=KF5 OPTIONS_FILE_UNSET+=LTO OPTIONS_FILE_UNSET+=MARIADB OPTIONS_FILE_UNSET+=MMEDIA OPTIONS_FILE_UNSET+=PGSQL OPTIONS_FILE_SET+=QT5 OPTIONS_FILE_UNSET+=SDK OPTIONS_FILE_UNSET+=TEST OPTIONS_FILE_UNSET+=WEBDAV % cd /usr/ports/editors/libreoffice % make [snip] [build CXX] workdir/UnpackedTarball/pdfium/core/fpdfapi/parser/cpdf_object_strea m.cpp S=/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3 && I=$S/instdir && W=$ S/workdir && mkdir -p $W/GenCxxObject/UnpackedTarball/pdfium/core/fpdfapi/page/ $W/Dep/GenCxxObject/UnpackedTarball/pdfium/core/fpdfapi/page/ && cd /usr/ports/ editors/libreoffice/work/libreoffice-7.3.0.3 && CCACHE_CPP2=1 c++ -DBOOST_ER ROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DFREEBSD -DND EBUG -DOSL_DEBUG_LEVEL=0 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT -isystem /usr/local/include -DFPDF_IMPLEMENTATION -DUSE_SYSTEM_LCMS2 -DUSE_SYSTEM_LIBJPE G -DUSE_SYSTEM_ZLIB -DUSE_SYSTEM_ICUUC -DMEMORY_TOOL_REPLACES_ALLOCATOR -DUNICOD E -DWIN32_LEAN_AND_MEAN -DCOMPONENT_BUILD -DUSE_SYSTEM_LIBOPENJPEG2 -DSYSTEM_Z LIB -DZLIB_CONST -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H='<freetype-custom-co nfig/ftmodule.h>' -DFT_CONFIG_OPTIONS_H='<freetype-custom-config/ftoption.h>' -fvisibility=hidden -Wall -Wno-missing-braces -Wnon-virtual-dtor -Wendif-labe ls -Wextra -Wundef -Wunreachable-code -Wshadow -Wunused-macros -Wembedded-direct ive -finput-charset=UTF-8 -fmessage-length=0 -fno-common -pipe -fstack-protector -strong -Wdeprecated-copy-dtor -Wimplicit-fallthrough -Wunused-exception-param eter -Wrange-loop-analysis -fvisibility-inlines-hidden -fPIC -Woverloaded-virtua l -Wno-unused-parameter -Wno-unused-local-typedefs -std=c++17 -O2 -pipe -fstac k-protector-strong -DLDAP_DEPRECATED -isystem /usr/local/include -fno-strict-ali asing -isystem /usr/local/include -DEXCEPTIONS_ON -fexceptions -w -DLIBO_INT ERNAL_ONLY -c $W/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_dib.cpp -o $W/Ge nCxxObject/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_dib.o -I$W/UnpackedTar ball/pdfium/third_party/freetype/include/ -I$W/UnpackedTarball/pdfium/third_part y/freetype/src/include/ -I$W/UnpackedTarball/pdfium -I$W/UnpackedTarball/pdfium/ third_party -I$W/UnpackedTarball/pdfium/third_party/agg23 -isystem /usr/local/i nclude/openjpeg-2.4 -I$S/include -I$S/config_host -isystem /usr/loc al/include -Wno-long-long In file included from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/wo rkdir/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_dib.cpp:31: /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/UnpackedTarball/ pdfium/core/fxcodec/jpx/cjpx_decoder.h:63:14: error: unknown type name 'opj_code c_t'; did you mean 'opj_poc_t'? UnownedPtr<opj_codec_t> m_Codec; ^~~~~~~~~~~ opj_poc_t /usr/local/include/openjpeg.h:225:3: note: 'opj_poc_t' declared here } opj_poc_t; ^ In file included from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/wo rkdir/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_dib.cpp:31: /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/UnpackedTarball/ pdfium/core/fxcodec/jpx/cjpx_decoder.h:65:14: error: use of undeclared identifie r 'opj_stream_t' UnownedPtr<opj_stream_t> m_Stream; ^ test -f /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/Unpacked Tarball/pdfium/core/fpdfapi/parser/cpdf_object_stream.cpp || (echo "Missing gene rated source file /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdi r/UnpackedTarball/pdfium/core/fpdfapi/parser/cpdf_object_stream.cpp" && false) [snip] [build CXX] workdir/UnpackedTarball/pdfium/core/fpdfapi/edit/cpdf_stringarchives tream.cpp S=/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3 && I=$S/instdir && W=$ S/workdir && mkdir -p $W/GenCxxObject/UnpackedTarball/pdfium/core/fpdfapi/parse r/ $W/Dep/GenCxxObject/UnpackedTarball/pdfium/core/fpdfapi/parser/ && cd /usr/po rts/editors/libreoffice/work/libreoffice-7.3.0.3 && CCACHE_CPP2=1 c++ -D BOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DFREE BSD -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT -isystem /usr/local/include -DFPDF_IMPLEMENTATION -DUSE_SYSTEM_LCMS2 -DUSE_SYSTE M_LIBJPEG -DUSE_SYSTEM_ZLIB -DUSE_SYSTEM_ICUUC -DMEMORY_TOOL_REPLACES_ALLOCATOR -DUNICODE -DWIN32_LEAN_AND_MEAN -DCOMPONENT_BUILD -DUSE_SYSTEM_LIBOPENJPEG2 -D SYSTEM_ZLIB -DZLIB_CONST -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H='<freetype-c ustom-config/ftmodule.h>' -DFT_CONFIG_OPTIONS_H='<freetype-custom-config/ftoptio n.h>' -fvisibility=hidden -Wall -Wno-missing-braces -Wnon-virtual-dtor -Wen dif-labels -Wextra -Wundef -Wunreachable-code -Wshadow -Wunused-macros -Wembedde d-directive -finput-charset=UTF-8 -fmessage-length=0 -fno-common -pipe -fstack-p rotector-strong -Wdeprecated-copy-dtor -Wimplicit-fallthrough -Wunused-excepti on-parameter -Wrange-loop-analysis -fvisibility-inlines-hidden -fPIC -Woverloade d-virtual -Wno-unused-parameter -Wno-unused-local-typedefs -std=c++17 -O2 -pip e -fstack-protector-strong -DLDAP_DEPRECATED -isystem /usr/local/include -fno-st rict-aliasing -isystem /usr/local/include -DEXCEPTIONS_ON -fexceptions -w -D LIBO_INTERNAL_ONLY -c $W/UnpackedTarball/pdfium/core/fpdfapi/parser/cpdf_cross_ ref_table.cpp -o $W/GenCxxObject/UnpackedTarball/pdfium/core/fpdfapi/parser/cpdf _cross_ref_table.o -I$W/UnpackedTarball/pdfium/third_party/freetype/include/ -I $W/UnpackedTarball/pdfium/third_party/freetype/src/include/ -I$W/UnpackedTarball /pdfium -I$W/UnpackedTarball/pdfium/third_party -I$W/UnpackedTarball/pdfium/thir d_party/agg23 -isystem /usr/local/include/openjpeg-2.4 -I$S/include -I$S/con fig_host -isystem /usr/local/include -Wno-long-long /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/UnpackedTarball/ pdfium/core/fpdfapi/page/cpdf_dib.cpp:124:34: error: use of undeclared identifie r 'OPJ_CLRSPC_SRGB'; did you mean 'CLRSPC_SRGB'? jpx_info.colorspace == OPJ_CLRSPC_SRGB) { ^~~~~~~~~~~~~~~ CLRSPC_SRGB /usr/local/include/openjpeg.h:133:2: note: 'CLRSPC_SRGB' declared here CLRSPC_SRGB = 1, /**< sRGB */ ^ 3 errors generated. [snip] gmake[2]: *** [Makefile:288: build] Error 2 gmake[2]: Leaving directory '/usr/ports/editors/libreoffice/work/libreoffice-7.3 .0.3' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/editors/libreoffice *** Error code 1 Stop. make: stopped in /usr/ports/editors/libreoffice
+1. Already responded at dev-commits-ports-main ML [1] but no reaction (except excessive patch) yet. Defaut option except LTO is ON. # This file is auto-generated by 'make config'. # Options for libreoffice-7.3.0.3 _OPTIONS_READ=libreoffice-7.3.0.3 _FILE_COMPLETE_OPTIONS_LIST=COINMP CUPS DOCS GNOME GTK3 JAVA KF5 LTO MARIADB MMEDIA PGSQL QT5 SDK TEST WEBDAV OPTIONS_FILE_UNSET+=COINMP OPTIONS_FILE_SET+=CUPS OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_UNSET+=GNOME OPTIONS_FILE_UNSET+=GTK3 OPTIONS_FILE_SET+=JAVA OPTIONS_FILE_UNSET+=KF5 OPTIONS_FILE_SET+=LTO OPTIONS_FILE_UNSET+=MARIADB OPTIONS_FILE_SET+=MMEDIA OPTIONS_FILE_UNSET+=PGSQL OPTIONS_FILE_SET+=QT5 OPTIONS_FILE_UNSET+=SDK OPTIONS_FILE_UNSET+=TEST OPTIONS_FILE_UNSET+=WEBDAV [1] https://lists.freebsd.org/archives/dev-commits-ports-main/2022-February/014463.html
Do you have openjpeg15 installed? If so, please remove it for now as libreoffice needs openjpeg (2.x).
(In reply to Li-Wen Hsu from comment #2) It is. Thanks for the info. It was pulled in as indirect dependency of deoygen, which itself is an dependency of something. Now try rebuilding libreoffice with openjpeg15 (forcibly) deleted. Is there any way to fix this? graphics/openjpeg and graphics/openjpeg15 don't conflict each other. So there should be at least one (hopefully standardized) way to pick right one only.
I have linking failure with openjpeg 2.4 (see attachement)
Created attachment 231895 [details] Linking failure in pdfium
openjpeg15 is an explicit dependency for tex-web2c, which is required by texlive. Since openjpeg15 and openjpeg 2.4 packages are supposed to be able to coexist and openjpeg15 is required by other packages, libreoffice should be able to build in the presence of openjpeg15 and select openjpeg 2.4 correctly.
(In reply to russo from comment #6) No. Abandoned conflicting openjpeg15 must be fixed instead.
(In reply to Dima Panov from comment #7) If that is the case, then all the ports that actually require openjpeg15 should be fixed. I've already opened a bug report (262021) for the one conflict that is biting me, tex-web2c --- which as far as I can tell has a Makefile that explicitly *requires* openjpeg15 be installed, but doesn't actually link to it for any reason.
(In reply to jakub_lach from comment #5) Unfortunately, same error here. MAKE_JOBS_UNSAFE=yes. Without "MAKE_JOBS_UNSAFE=yes", "[LNK] Executable/canvasdemo" line was "[CXX] chart2/source/controller/accessibility/AccessibleChartShape.cxx", but with "MAKE_JOBS_UNSAFE=yes" should be accurate. Confirmed graphics/openjpeg15 is deinstalled like below. % pkg version -o -v | fgrep openjpeg graphics/openjpeg = up-to-date with index What can I try next?
(In reply to jakub_lach from comment #5) This is a different problem, I had the same. But a build without option LTO was successful, as a workaround.
(In reply to Li-Wen Hsu from comment #2) how bout the port links with the correct library and uses the correct header, there should be no conflicts at all. If it conflicts its because the header is being pulled from /usr/local/include/ instead of /usr/local/include/openjpeg-2.4/ where the file actually exists, this isn't a users problem, and no I will not delete a required port because this port doesn't pull headers from the correct location on a freebsd system. I'll just see if I can go back to openoffice instead. I don't have the verbose errors but I must be having the same issue as its pdfium that is failing to compile. $} pkg info -l openjpeg openjpeg-2.4.0: /usr/local/bin/opj_compress /usr/local/bin/opj_decompress /usr/local/bin/opj_dump /usr/local/include/openjpeg-2.4/openjpeg.h /usr/local/include/openjpeg-2.4/opj_config.h /usr/local/include/openjpeg-2.4/opj_stdint.h /usr/local/lib/libopenjp2.a /usr/local/lib/libopenjp2.so /usr/local/lib/libopenjp2.so.2.4.0 /usr/local/lib/libopenjp2.so.7 /usr/local/lib/openjpeg-2.4/OpenJPEGConfig.cmake /usr/local/lib/openjpeg-2.4/OpenJPEGTargets-release.cmake /usr/local/lib/openjpeg-2.4/OpenJPEGTargets.cmake /usr/local/libdata/pkgconfig/libopenjp2.pc /usr/local/share/licenses/openjpeg-2.4.0/BSD2CLAUSE /usr/local/share/licenses/openjpeg-2.4.0/LICENSE /usr/local/share/licenses/openjpeg-2.4.0/catalog.mk $} pkg info -l openjpeg15 openjpeg15-1.5.2_1: /usr/local/bin/image_to_j2k /usr/local/bin/j2k_dump /usr/local/bin/j2k_to_image /usr/local/include/openjpeg.h /usr/local/lib/libopenjpeg.so /usr/local/lib/libopenjpeg.so.1.5.2 /usr/local/lib/libopenjpeg.so.2 /usr/local/libdata/pkgconfig/libopenjpeg.pc /usr/local/libdata/pkgconfig/libopenjpeg1.pc /usr/local/man/man1/image_to_j2k.1.gz /usr/local/man/man1/j2k_dump.1.gz /usr/local/man/man1/j2k_to_image.1.gz /usr/local/man/man3/libopenjpeg.3.gz /usr/local/share/doc/openjpeg/CHANGES /usr/local/share/doc/openjpeg/LICENSE /usr/local/share/licenses/openjpeg15-1.5.2_1/BSD2CLAUSE /usr/local/share/licenses/openjpeg15-1.5.2_1/LICENSE /usr/local/share/licenses/openjpeg15-1.5.2_1/catalog.mk /usr/local/share/openjpeg/OpenJPEGConfig.cmake /usr/local/share/openjpeg/OpenJPEGTargets-release.cmake /usr/local/share/openjpeg/OpenJPEGTargets.cmake
(In reply to Dima Panov from comment #7) no, pull your header from the correct location on the file system
(In reply to alt2600 from comment #12) My apologies, after digging into the config.log to look this over assuming the wrong paths, I see you point. And now we are all held hostage due to a 2 year old report posted bug on openjpeg15
(In reply to alt2600 from comment #13) Folks, be patient, I working on fixing openjpeg15 and consumers. Pointyhat to sunpoet@ for POLA violation -- he keep patches which forces port install includes to root includes folder instead of original subdir as authors designed it.
(In reply to Florian Walpen from comment #10) Thanks! It helped for git src stable/13 e1465e2e1e06. But segfaulted around [MOD] postprocess on git src main abf5bff71d38. As the segfaulted build was not "MAKE_JOBS_UNSAFE=yes", so where it segfaulted is not at all accurate. Now rebuilding with "MAKE_JOBS_UNSAFE=yes". Would taka a fair amount of time to finish (fail or not).
openjpeg15 port is fixed now in main
(In reply to Tomoaki AOKI from comment #15) I have finished the build with LTO disabled now.
(In reply to Dima Panov from comment #16) Thanks! I'll give it a try on src main, which I need rebuilding anyway.
With the openjpeg15 fix pulled, I'm back up and running. Thanks for pulling all the pieces together.
(In reply to jakub_lach from comment #17) Yes, it's OK for me, too, on stable/13. But main still failed with "MAKE_JOBS_UNSAFE=yes" build. Same options applied and graphics/openjpeg15 deleted. As changes in UMA, elf tools is done on main after my current state, I'll try after updating base to latest state. Error log and backtrace (from gengal.bin.core) is like below. ===== Error Log ===== [LNK] Executable/gengal.bin S=/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3 && I=$S/instdir && W=$S/workdir && c++ -Wl,-z,origin '-Wl,-rpath,$ORIGIN' -Wl,-rpath-link,$I/program -fstack-protector-strong -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -Wl,--hash-style=gnu -Wl,-Bsymbolic-functions -L$W/LinkTarget/StaticLibrary -L$I/sdk/lib -L$I/program -L$I/program -fstack-protector-strong -L/usr/local/lib -L/usr/local/lib $W/CxxObject/svx/source/gengal/gengal.o -Wl,--start-group $W/LinkTarget/StaticLibrary/libglxtest.a $W/LinkTarget/StaticLibrary/libvclmain.a -pthread -L/usr/local/lib -lorcus-0.17 -lorcus-parser-0.17 -lX11 -Wl,--end-group -Wl,--no-as-needed -lbasegfxlo -luno_sal -ltllo -lsfxlo -lsvllo -lsvtlo -lcomphelper -luno_cppu -luno_cppuhelpergcc3 -lutllo -lsvxcorelo -lvcllo -o $I/program/gengal.bin TEMPFILE=/usr/ports/editors/libreoffice/work/gbuild.XXXXXX.c0VocQXBqZ && mv ${TEMPFILE} /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/LinkTarget/Executable/gengal.bin.objectlist touch /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/Executable/gengal.run mkdir -p /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/Gallery/ mkdir -p /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/Gallery/backgrounds/ mkdir -p /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/Package/prepared/Gallery/Files/ && touch /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/Package/prepared/Gallery/Files/backgrounds [GAL] backgrounds S=/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3 && I=$S/instdir && W=$S/workdir && rm -f $W/Gallery/backgrounds/* && RESPONSEFILE=/usr/ports/editors/libreoffice/work/gbuild.XXXXXX.sBaBWtQojY && ( LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program" $I/program/gengal.bin --build-tree --destdir file://$S/extras/source/gallery --name "backgrounds" --path $W/Gallery/backgrounds --filenames file://$RESPONSEFILE -env:UserInstallation=file://$W/Gallery/backgrounds/user ) && rm $RESPONSEFILE && touch $W/Gallery/backgrounds.done Work on gallery 'file:///usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/Gallery/backgrounds' Existing themes: 0 Segmentation fault (core dumped) gmake[3]: *** [/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/solenv/gbuild/Gallery.mk:57: /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/Gallery/backgrounds.done] Error 139 rm /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/dict_word_hu.txt /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/edit_word_hu.txt /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/count_word.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/edit_word_he.txt /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/sent.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/edit_word.txt /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/dict_word_prepostdash.txt /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/count_word.txt /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/dict_word.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/line.txt /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/edit_word.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/dict_word_he.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/edit_word_he.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/dict_word_nodash.txt /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/line.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/dict_word.txt /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/dict_word_nodash.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/dict_word_hu.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/edit_word_hu.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/dict_word_prepostdash.brk /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/sent.txt /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/workdir/CustomTarget/i18npool/breakiterator/dict_word_he.txt gmake[3]: Leaving directory '/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3' gmake[2]: *** [Makefile:288: build] Error 2 gmake[2]: Leaving directory '/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3' *** Error code 1 Stop. make[1]: stopped in /usr/ports/editors/libreoffice *** Error code 1 Stop. make: stopped in /usr/ports/editors/libreoffice ** Command failed (exit code 1): env LOCALIZED_LANG=ja CPUTYPE=haswell MAKE_JOBS_NUMBER_LIMIT=12 make DISABLE_VULNERABILITIES=yes MAKE_JOBS_UNSAFE=yes UPGRADE_TOOL=pkg_replace UPGRADE_PORT=libreoffice-7.2.5.2 UPGRADE_PORT_VER=7.2.5.2 ** Fix the problem and try again. ===== Looking for core ===== % bfs /usr/ports/editors/libreoffice/work/ -name "*.core" -type f /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/gengal.bin.core ===== Backtrace ===== Reading symbols from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/gengal.bin... (No debugging symbols found in /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/gengal.bin) [New LWP 101298] warning: Could not load shared library symbols for [vdso]. Do you need "set solib-search-path" or "set sysroot"? Core was generated by `/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/gengal.b'. Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 0x000000087718531a in gcc3::deleteException(void*) () from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libgcc3_uno.so warning: File "/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libbasegfxlo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libbasegfxlo.so-gdb.py line to your configuration file "/root/.config/gdb/gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/root/.config/gdb/gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: File "/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libuno_sal.so.3-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: File "/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libtllo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: File "/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libsvllo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: File "/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libuno_cppu.so.3-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: File "/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libutllo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: File "/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libvcllo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". (gdb) bt #0 0x000000087718531a in gcc3::deleteException(void*) () from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libgcc3_uno.so #1 0x000000082c90c02a in __cxa_free_exception () from /lib/libcxxrt.so.1 #2 0x000000082bee9205 in FileExists(INetURLObject const&) () from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libsvxcorelo.so #3 0x000000082bef81a4 in GalleryBinaryStorageLocations::ImplGetURLIgnoreCase(INetURLObject const&) () from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libsvxcorelo.so #4 0x000000082bef7557 in GalleryBinaryEngineEntry::CreateUniqueURL(INetURLObject const&, INetURLObject&) () from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libsvxcorelo.so #5 0x000000082bee4aec in GalleryThemeEntry::GalleryThemeEntry(bool, INetURLObject const&, rtl::OUString const&, bool, bool, unsigned int, bool) () from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libsvxcorelo.so #6 0x000000082bee71ba in Gallery::CreateTheme(rtl::OUString const&) () from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libsvxcorelo.so #7 0x0000000000207086 in (anonymous namespace)::GalApp::Main() () #8 0x000000082fbb0fae in ImplSVMain() () from /usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libvcllo.so #9 0x000000000020a52f in main () (gdb) q
(In reply to Tomoaki AOKI from comment #20) Updated src main to git bd6e8729d6f6, try rebuilding and segfaulted the same way. Recalling ntp segfault issue on ASLR (previous implementation, though), setting sysctl kern.elf64.aslr.enable to 0 (default 1, enabled on main, 0 on stable/13) without luck.
(In reply to Tomoaki AOKI from comment #21) Forcibly updating all ports containing libraries that actually linked against editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/gengal.bin (checked by ldd), segfaults as the same way. Renaming preserved libraries having the name libuno*.so.* under /usr/local/lib/compat/pkg/, where portupgrade preserves old libraries, not to be accidentally picked, segfaults the same way. For both of which, sysctl kern.elf64.aslr.enable was back to default on main (1), as chaging it to 0 didn't affected on previous try. For the record: rebuilt ports below. devel/liborcus devel/icu textproc/libxml2 ftp/curl security/nss devel/nspr graphics/libepoxy graphics/graphite2 print/harfbuzz print/harfbuzz-icu graphics/lcms2 graphics/jpeg-turbo graphics/png graphics/cairo x11-fonts/fontconfig print/freetype2 x11/libXext devel/liblangtag www/libnghttp2 devel/glib20 net/avahi-app security/gnutls x11/pixman graphics/libglvnd textproc/expat2 devel/pcre devel/gettext-runtime converters/libiconv devel/dbus security/p11-kit dns/libidn2 devel/libunistring security/libtasn1 security/nettle math/gmp devel/libffi devel/boost-libs x11/libxcb x11/libXau x11/libXdmcp x11/libX11
*** Bug 262065 has been marked as a duplicate of this bug. ***
(In reply to Tomoaki AOKI from comment #22) No more idea. Giving up for now. And building this kind of heavy things within weekday on main is difficult... As basically my main (current) environment is a subset of stable/13 with installed-ports aspect (because it's test environment), risks of broken buuild should be much larger on stable/13, but stable/13 is OK. So the problem would be anything in difference of toolchain or libraries within main and stable/13.
I have got on 13 stable: [LNK] Executable/fftester /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_stream_create' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_setup_decoder' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_image_data_alloc' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_end_decompress' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_destroy_codec' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_read_header' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_image_destroy' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_stream_destroy' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_get_decoded_tile' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_stream_set_skip_function' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_stream_set_read_function' S=/tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3 && I=$S/instdir && W=$S/workdir && /usr/local/bin/readelf -d $I/program/libdesktopbe1lo.so | grep SONAME > $W/LinkTarget/Library/libdesktopbe1lo.so.exports.tmp; /usr/local/bin/nm --plugin LLVMgold.so --dynamic --extern-only --defined-only --format=posix $I/program/libdesktopbe1lo.so | cut -d' ' -f1-2 >> $W/LinkTarget/Library/libdesktopbe1lo.so.exports.tmp && if cmp -s $W/LinkTarget/Library/libdesktopbe1lo.so.exports.tmp $W/LinkTarget/Library/libdesktopbe1lo.so.exports; then rm $W/LinkTarget/Library/libdesktopbe1lo.so.exports.tmp; else mv $W/LinkTarget/Library/libdesktopbe1lo.so.exports.tmp $W/LinkTarget/Library/libdesktopbe1lo.so.exports && touch -r $I/program/libdesktopbe1lo.so $W/LinkTarget/Library/libdesktopbe1lo.so.exports; fi /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_set_error_handler' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_set_warning_handler' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_stream_set_user_data' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_image_data_free' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_stream_set_user_data_length' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_decode' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_set_info_handler' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_set_default_decoder_parameters' S=/tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3 && I=$S/instdir && W=$S/workdir && /usr/local/bin/readelf -d $I/program/libspllo.so | grep SONAME > $W/LinkTarget/Library/libspllo.so.exports.tmp; /usr/local/bin/nm --plugin LLVMgold.so --dynamic --extern-only --defined-only --format=posix $I/program/libspllo.so | cut -d' ' -f1-2 >> $W/LinkTarget/Library/libspllo.so.exports.tmp && if cmp -s $W/LinkTarget/Library/libspllo.so.exports.tmp $W/LinkTarget/Library/libspllo.so.exports; then rm $W/LinkTarget/Library/libspllo.so.exports.tmp; else mv $W/LinkTarget/Library/libspllo.so.exports.tmp $W/LinkTarget/Library/libspllo.so.exports && touch -r $I/program/libspllo.so $W/LinkTarget/Library/libspllo.so.exports; fi /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_create_decompress' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_stream_set_seek_function' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_set_decode_area' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_stream_create' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_setup_decoder' /usr/local/bin/ld.bfd: /tmp/ports/usr/ports/editors/libreoffice/work/libreoffice-7.3.0.3/instdir/program/libpdfiumlo.so: undefined reference to `opj_image_data_alloc' clang++: error: linker command failed with exit code 1 (use -v to see invocation)
Without LTO build ok.
I managed to get a ktrace of the gengal.bin run - attaching compressed text copy as gengal.bin-ktrace.xz
Created attachment 232152 [details] failing gengal.bin ktrace text
As Jonathan Chen reported on freebsd-ports ML [1], build fails not only on main but also on stable/13 with same failure mode. I could confirm on stable/13, amd64 git a0c3799828e5. At least, as I reported at Comment 15, built fine on e1465e2e1e06 with LTO option disabled. This should mean any commit MFC'ed within f6c74bacf5e7 and a0c3799828e5 breaks build. This can be narrowed down if Jonathan reports what was his src revision. [1] https://lists.freebsd.org/archives/freebsd-ports/2022-February/001518.html
*** Bug 262285 has been marked as a duplicate of this bug. ***
(In reply to Tomoaki AOKI from comment #29) ,6:48am> uname -a FreeBSD jade.inside.chen.org.nz 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n249727-0add00229d5: Thu Feb 24 09:59:44 NZDT 2022 root@jade.inside.chen.org.nz:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
(In reply to Jonathan Chen from comment #31) Thanks! This helped to narrow down. Finally, it turned out that commit b2127b6f1ae2 on stable/13 [1] broke build. It's commit c00d34566536 on main [2]. Manually reverting [1] on stable/13 allowed finishing build. Not yet tested on main. It would be better adapting editors/libreoffice (gengal.bin part) to the above-mentioned commits, but I have no idea how to do so. [1] https://lists.freebsd.org/archives/dev-commits-src-branches/2022-February/003036.html [2] https://lists.freebsd.org/archives/dev-commits-src-main/2022-February/003807.html
I was redirected here when trying to report my editors/libreoffice build fail on 13.0-RELEASE-p7 amd64. Was building from 'latest' ports tree, because libreoffice pkg from that repo crashes with signal 11. So does 'quarterly'. I"ve been following this for the last few days. Does this all mean that it is the base OS that causes the build fail and not the port itself? But mine is not STABLE, it's a RELEASE-p7. And /usr/include/unwind.h mentioned in the linkes from comment 32 above is not present on my system... Anyway, what do I do?...
(In reply to bergerkos from comment #33) > Anyway, what do I do?... LibreOffice is quite a complex software and many factors can affect the build process. It also takes time to verify and debug. We are working on it, but cannot have a very clear ETA at the moment. Before the issue has been sorted out, I recommend using libreoffice package from official pkg.freebsd.org, where 7.3.0 is available now.
Ok thank you very much.
Well here's my original problem, why I even started the build in the first place... Official pkg repo offers only libreoffice-7.3.0.3, which, unfortunately, fails to run! Trying to report that as a bug also redirected me here...
Correction: it doesn't redirect me here but has been reported as a separate bug successfully. Sorry
Last resort, tried to build version 7.2.5.2 from the corresponding git tree version. It builds all right, but fails to run as well... so it must indeed by the OS.
(In reply to Tomoaki AOKI from comment #32) Tried building on src main at git 66b86c8a7604 (a bit old though, but known to me as problematic) with commit c00d34566536 manually reverted successfully. Installed and starts fine. unwind.h seems to be included on {WRKSRC}/bridges/source/cpp_uno/gcc3_[linux_intel|linux_arm|ios|linux_x86-64|linux_aarch64]/share.hxx unconditionally (a), so differences on before problematic commit : /usr/include/c++/v1/unwind.h after and including problematic commit : /usr/include/unwind.h would be causing this build issue. Basically, editors/libreoffice should be fixed to adapt with both. (Conditional extra-patch checking the existence of /usr/include/unwind.h?) (a) Checked by `grep -r -n unwind.h /usr/ports/editors/libreoffice/work/ | fgrep #include` after `make extract`, then look into files listed.
(In reply to Tomoaki AOKI from comment #39) Based on your finding here I think a simple patch adding some #ifdef based on __FreeBSD_version [1] could be enough. [1] https://docs.freebsd.org/en/books/porters-handbook/versions/
(In reply to Guido Falsi from comment #40) Unfortunately, no commit messages on bumps mention about the commits I've mentioned. This would make future developers confuse because of unsane traceability. Moreover, if further MFC to stable/12 is planned, depending on __FreeBSD_version (OSVERSION on ports) should force another update. As editors/libreoffice is a giant, requiring several hours to build, this would be a pain.
dim@ kindly did a detailed analysis on dev-commits-src-branches ML [1]. (Original post [by me] is not delivered, though, I've CC'ed dim@ and jhb@.) Which way should we go on? Fix editors/libreoffice, or request base to implement compat hacks? [1] https://lists.freebsd.org/archives/dev-commits-src-branches/2022-March/003378.html
(In reply to Tomoaki AOKI from comment #41) > Unfortunately, no commit messages on bumps mention about the commits I've mentioned. > This would make future developers confuse because of unsane traceability. In the ports tree we are often grabbing __FreeBSD_version values near the affected commits, because often one exactly at the affected commit is often missing. Also quite often the commit actually bumping __FreeBSD_version happens a few commits after the fact, so even when there is an actual specific bump it is not exactly matching the event in the history. So this objection is moot in practice, just grab the nearest bump, that is good enough, especially since we are talking about head and stable, people will anyway upgrade past the event at some point. Chances of people falling in one of the commits in between is really low. > Moreover, if further MFC to stable/12 is planned, depending on __FreeBSD_version (OSVERSION on ports) should force another update. > As editors/libreoffice is a giant, requiring several hours to build, this would be a pain. This depends on the nature of the fix. As far as I can understand this is a build fix, while already built binaries keep working (except ones built using hacks to try to work around the issue, but that's user action that they will need to fix themselves), so we simply need to change the conditional, no PORTREVISION bump is required for build fixes. If I'm wrong and this is a runtime also issue and thus need to force package being rebuilt you get a point here, but a minor one. If the package is broken there is no alternative than rebuilding it to fix it.
(In reply to Florian Walpen from comment #10) FWIW, LTO build on 13-STABLE still fails after recent update on libpdfium.
(In reply to jakub_lach from comment #44) Though with PDFIUM disabled and LTO enabled it segfaults on gengal.bin so it should work once gengal thing is ironed out.
Created attachment 232274 [details] Fix build with PDFIUM and LTO enabled. This supposedly fixes the build failure with PDFIUM and LTO enabled: When libvcllo.so is linked together with libpdfiumlo.so, it also needs libopenjp2.so from graphics/openjpeg, since pdfium depends on that. Building with LTO exposes this as an error, complaining about undefined references to openjpeg library functions. This patch adds the missing linker flag "-lopenjp2". Tested on 13.0-RELEASE-p7, successfully opened some documents. What puzzles me is that the LTO package seems to use more disk space than the one without LTO. But I don't have time to investigate now.
Introducing further investigation on dev-commits-src-branches ML by dim@. [1] https://lists.freebsd.org/archives/dev-commits-src-branches/2022-March/003422.html [2] https://lists.freebsd.org/archives/dev-commits-src-branches/2022-March/003423.html
(In reply to Florian Walpen from comment #46) Oh, thanks for the investigaton! I'll push patch asap
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=c8b6581835f18a1dae05a4dd9a8b5829fe99b5d7 commit c8b6581835f18a1dae05a4dd9a8b5829fe99b5d7 Author: Dima Panov <fluffy@FreeBSD.org> AuthorDate: 2022-03-06 16:37:48 +0000 Commit: Dima Panov <fluffy@FreeBSD.org> CommitDate: 2022-03-06 16:37:48 +0000 editors/libreoffice: force PDFium to link with OpenJPEG (+) When libvcllo.so is linked together with libpdfiumlo.so, it also needs libopenjp2.so from graphics/openjpeg, since pdfium depends on that. Building with LTO exposes this as an error, complaining about undefined references to openjpeg library functions. While here, add py310 to allowed versions to the build PR: 262008 Submitted by: Florian Walpen <dev@submerge.ch> Sponsored by: Netzkommune GmbH editors/libreoffice/Makefile | 4 ++-- editors/libreoffice/files/patch-RepositoryExternal.mk (new) | 10 ++++++++++ 2 files changed, 12 insertions(+), 2 deletions(-)
Created attachment 232330 [details] editors/libreoffice: work around changed alignment of __cxa_exception Here is patch that should make libreoffice work with both the old and the new alignment of __cxa_exception (and _Unwind_Exception): editors/libreoffice: work around changed alignment of __cxa_exception LibreOffice has special detection for the change in alignment and size of struct cxa_exception, when using libc++abi. However, this updated alignment also applies to libunwind and upstream libcxxrt, and will soon apply to our libcxxrt too. Enable the special detection unconditionally for x86_64 and aarch64, so libreoffice packages built on 13.0-R (with the old alignment) will seamlessly work on 13.1-R (which will have the new alignment).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f88f34d1b4a00d94c00aae1b3097c9c637e36397 commit f88f34d1b4a00d94c00aae1b3097c9c637e36397 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2022-03-09 07:28:27 +0000 Commit: Dima Panov <fluffy@FreeBSD.org> CommitDate: 2022-03-09 07:28:27 +0000 editors/libreoffice: work around changed alignment of __cxa_exception LibreOffice has special detection for the change in alignment and size of struct cxa_exception, when using libc++abi. However, this updated alignment also applies to libunwind and upstream libcxxrt, and will soon apply to our libcxxrt too. Enable the special detection unconditionally for x86_64 and aarch64, so libreoffice packages built on 13.0-R (with the old alignment) will seamlessly work on 13.1-R (which will have the new alignment). PR: 262008 editors/libreoffice/Makefile | 2 +- ...bridges_source_cpp__uno_gcc3__linux__aarch64_abi.cxx (new) | 11 +++++++++++ ...idges_source_cpp__uno_gcc3__linux__x86-64_except.cxx (new) | 11 +++++++++++ 3 files changed, 23 insertions(+), 1 deletion(-)
(In reply to Dimitry Andric from comment #50) Thank you for patch. I can build on 14-current successfully.
@dim Shouldn't the same change be done to bridges/source/cpp_uno/gcc3_linux_powerpc/except.cxx and bridges/source/cpp_uno/gcc3_linux_powerpc64/except.cxx?
(In reply to Dimitry Andric from comment #50) Thanks! Confirmed builds/installs/starts fine, with and without Phabricator D34488 patch on stable/13, amd64. (With D34488 patch alone, gengal.bin segfaulted. The committed patch here was mandatory.)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=72df847a94bccee245a3316e4f848482b9ac2ac2 commit 72df847a94bccee245a3316e4f848482b9ac2ac2 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2022-03-08 21:53:16 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2022-03-09 17:25:18 +0000 Remove compat hacks from libcxxrt's _Unwind_Exception This reverts 9097e3cbcac4, which was in itself a revert of upstream libcxxrt commits 88bdf6b290da ("Specify double-word alignment for ARM unwind") and b96169641f79 ("Updated Itanium unwind"), and a reapplication of our commit 3c4fd2463bb2 ("libcxxrt: add padding in __cxa_allocate_* to fix alignment"). The editors/libreoffice port will be patched to be able to cope with the standards-compliant alignment of _Unwind_Exception and consequently, that of __cxa_exception. The layouts and sizes of these structures should then be completely the same for libcxxrt, libunwind and libc++abi. PR: 262008 Reviewed by: emaste, jhb, theraven MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D34488 contrib/libcxxrt/exception.cc | 30 ++++++------------------------ contrib/libcxxrt/unwind-arm.h | 2 +- contrib/libcxxrt/unwind-itanium.h | 9 ++++++--- 3 files changed, 13 insertions(+), 28 deletions(-)
(In reply to commit-hook from comment #51) Btw can we please MFH this, so it gets into the quarterly for the upcoming 13.1-RELEASE? That is very important. :)
(In reply to Piotr Kubaj from comment #53) Upstream doesn't have the libc++abi workaround parts for powerpc and powerpc64, so maybe it was never necessary there? Or maybe nobody ever ran into the issue on these architectures. The question is whether the addition of __attribute__((aligned)) to struct _Unwind_Exception makes any difference in the size of __cxa_exception on the platform. On x86_64, the maximum alignment is 16 bytes, so the addition of the attribute makes the total struct grow from 120 to 128 bytes. Depending on how powerpc and powerpc64 struct layouts end up, adding the attribute may or may not make a difference. If it does, then we should probably add a similar piece of workaround code as was done for x86_64.
(In reply to Dimitry Andric from comment #56) 2022Q1 still have 7.2.5 version. is it affected too? If so, I'll apply patch to quarterly asap
(In reply to Dima Panov from comment #58) I've just looked at the 7.2.5 source, and the bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx and bridges/source/cpp_uno/gcc3_linux_aarch64/abi.cxx source files both have the same libc++abi workaround code. So I think the patches should apply as-is, please let me know if they don't work, then I'll adjust them!
(In reply to commit-hook from comment #49) Just built on 13.1-PRERELEASE #0 stable/13-949837074: Fri Mar 4 14:44:22 CET 2022 with LTO and PDFIUM enabled. Thanks!
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=93779214f1c64c0713f7c900021e35d4e4e49697 commit 93779214f1c64c0713f7c900021e35d4e4e49697 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2022-03-08 21:53:16 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2022-03-12 18:20:55 +0000 Remove compat hacks from libcxxrt's _Unwind_Exception This reverts 9097e3cbcac4, which was in itself a revert of upstream libcxxrt commits 88bdf6b290da ("Specify double-word alignment for ARM unwind") and b96169641f79 ("Updated Itanium unwind"), and a reapplication of our commit 3c4fd2463bb2 ("libcxxrt: add padding in __cxa_allocate_* to fix alignment"). The editors/libreoffice port will be patched to be able to cope with the standards-compliant alignment of _Unwind_Exception and consequently, that of __cxa_exception. The layouts and sizes of these structures should then be completely the same for libcxxrt, libunwind and libc++abi. PR: 262008 Reviewed by: emaste, jhb, theraven MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D34488 (cherry picked from commit 72df847a94bccee245a3316e4f848482b9ac2ac2) contrib/libcxxrt/exception.cc | 30 ++++++------------------------ contrib/libcxxrt/unwind-arm.h | 2 +- contrib/libcxxrt/unwind-itanium.h | 9 ++++++--- 3 files changed, 13 insertions(+), 28 deletions(-)
A commit in branch releng/13.1 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ea9fa27b9470c15b4c6c8425839da90b3fda7c28 commit ea9fa27b9470c15b4c6c8425839da90b3fda7c28 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2022-03-08 21:53:16 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2022-03-17 15:13:06 +0000 Remove compat hacks from libcxxrt's _Unwind_Exception This reverts 9097e3cbcac4, which was in itself a revert of upstream libcxxrt commits 88bdf6b290da ("Specify double-word alignment for ARM unwind") and b96169641f79 ("Updated Itanium unwind"), and a reapplication of our commit 3c4fd2463bb2 ("libcxxrt: add padding in __cxa_allocate_* to fix alignment"). The editors/libreoffice port will be patched to be able to cope with the standards-compliant alignment of _Unwind_Exception and consequently, that of __cxa_exception. The layouts and sizes of these structures should then be completely the same for libcxxrt, libunwind and libc++abi. PR: 262008 Reviewed by: emaste, jhb, theraven Approved by: re (gjb) MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D34488 (cherry picked from commit 72df847a94bccee245a3316e4f848482b9ac2ac2) (cherry picked from commit 93779214f1c64c0713f7c900021e35d4e4e49697) contrib/libcxxrt/exception.cc | 30 ++++++------------------------ contrib/libcxxrt/unwind-arm.h | 2 +- contrib/libcxxrt/unwind-itanium.h | 9 ++++++--- 3 files changed, 13 insertions(+), 28 deletions(-)
@dim That libcxxrt change broke libreoffice on powerpc*.
Created attachment 233272 [details] editors/libreoffice: apply __cxa_exception workaround for powerpc* (In reply to Piotr Kubaj from comment #63) Can you please test the attached patch on both powerpc and powerpc64? I have added the workaround code blindly, because I have no way to test it.
(In reply to Dimitry Andric from comment #64) That patch applies fine to the ports tree, but when running make patch, it fails to pass. The reason is probably that it doesn't take into account other patches in ports. Those files (except.cxx) are already conditionally patched on powerpc* in files/powerpc64/patch-bridges-source-cpp_uno-gcc3_linux_powerpc-except.cxx and files/powerpc64/patch-bridges-source-cpp_uno-gcc3_linux_powerpc64-except.cxx.
I can confirm that libreoffice now builds fine on powerpc64le on 13.1-RC4.