Created attachment 260713 [details] script from attempt to build on 14.2-RELEASE-p; ports revision main:51e8c57fa ERROR: error 65280 occurred while making /usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/l10ntools/source/help (see attached build log)
It looks like it is finding the boost port under /usr/local and using that instead of the local copy of an older version. New versions of boost are not compatible with gnu89.
I locally have gcc13-13.3.0 and boost-libs-1.87.0_1 installed; should I install some other version of them, or just delete them?
(In reply to George Mitchell from comment #2) We no longer have a port for a sufficiently old version of boost, so the aoo port supplies an old copy. Try deleting your local boost package. I don't think gcc will matter. You may find issues with other locally installed packages, though.
(In reply to George Mitchell from comment #2) I'm seeing a vcl module build failure in poudriere on 14.2, but not -CURRENT. My -CURRENT build uses a bunch of non-default options, by my 14.2 build is pretty vanilla. Even stranger, I haven't been seeing any pkg-fallout errors.
For some reason, the copy of libgtk-x11-2.0.so.0 is built for 14.2 with poudriere is missing many symbols, like gtk_drawing_area_new.
Indeed, deleting my installed boost-libs fixes the problem. There must be a way for a port to say "Please don't use the installed version of X," but I don't know what it is . . . I haven't run into the libgtk problem.
The only thing the port can do it to put the include path in a safe order. Unfortunately, the path manipulation inside AOO is pretty hairy. gcc is required in this case for fortran. I've also run into a similar build problem on stable/14. In this case the x11-toolkits/gtk20 build failed. This problem appears to be intermittent.
Ugh. This is ugly, but could the Makefile detect the presence of boost-libs and complain that it must be temporarily deinstalled to compile this port and then reinstalled?
Make isn't that smart, and the conflicting header could be anything with the same name as an internal header. OpenOffice uses two different build systems. I fixed a similar problem in the new system a while back, and modules are gradually being converted over to the new system. This failure is happening in a module that still uses the old system. I dug into it and figured out how to fix the old build system as well.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=73598629cba46ce945c4682380751ae67ac54198 commit 73598629cba46ce945c4682380751ae67ac54198 Author: Don Lewis <truckman@FreeBSD.org> AuthorDate: 2025-06-01 18:32:57 +0000 Commit: Don Lewis <truckman@FreeBSD.org> CommitDate: 2025-06-01 18:45:26 +0000 editors/openoffice-*: Re-order include path Re-order the compiler include path to avoid inadverantly picking up unwanted system include files. This is just a build fix and does not change successfully built packages, so no PORTREVISION bump. PR: 287074 Reported by: George Mitchell .../patch-canvas_source_cairo_makefile.mk (new) | 11 ++++++ ...ctivity_source_drivers_evoab2_makefile.mk (new) | 11 ++++++ ...nnectivity_source_drivers_kab_makefile.mk (new) | 11 ++++++ ...orms_source_xforms_submission_makefile.mk (new) | 12 ++++++ ...-forms_source_xforms_xpathlib_makefile.mk (new) | 12 ++++++ ...atch-fpicker_source_unx_gnome_makefile.mk (new) | 11 ++++++ ...patch-fpicker_source_unx_kde4_makefile.mk (new) | 11 ++++++ .../files/patch-jvmfwk_source_makefile.mk (new) | 12 ++++++ .../patch-l10ntools_source_help_makefile.mk (new) | 11 ++++++ .../files/patch-oox_source_core_makefile.mk (new) | 11 ++++++ .../patch-pyuno_source_loader_makefile.mk (new) | 11 ++++++ .../patch-pyuno_source_module_makefile.mk (new) | 11 ++++++ .../patch-sccomp_source_solver_makefile.mk (new) | 12 ++++++ ...-shell_source_backends_kde4be_makefile.mk (new) | 11 ++++++ ...h-shell_source_backends_kdebe_makefile.mk (new) | 11 ++++++ .../files/patch-solenv_inc_target.mk (new) | 14 +++++++ .../patch-ucb_source_ucp_webdav_makefile.mk (new) | 46 ++++++++++++++++++++++ ...lhelp_source_cxxhelp_provider_makefile.mk (new) | 19 +++++++++ ...tch-xmlsecurity_source_xmlsec_makefile.mk (new) | 12 ++++++ ...xmlsecurity_source_xmlsec_nss_makefile.mk (new) | 12 ++++++ ...ctivity_source_drivers_evoab2_makefile.mk (new) | 11 ++++++ ...orms_source_xforms_submission_makefile.mk (new) | 12 ++++++ ...-forms_source_xforms_xpathlib_makefile.mk (new) | 12 ++++++ .../patch-l10ntools_source_help_makefile.mk (new) | 11 ++++++ .../patch-pyuno_source_loader_makefile.mk (new) | 11 ++++++ .../patch-pyuno_source_module_makefile.mk (new) | 11 ++++++ ...-shell_source_backends_kde4be_makefile.mk (new) | 11 ++++++ ...h-shell_source_backends_kdebe_makefile.mk (new) | 11 ++++++ .../files/patch-solenv_inc_target.mk (new) | 14 +++++++ ...tch-xmlsecurity_source_xmlsec_makefile.mk (new) | 12 ++++++ ...xmlsecurity_source_xmlsec_nss_makefile.mk (new) | 12 ++++++ 31 files changed, 400 insertions(+)
Thank you!
I have a build in progress of openoffice-devel including this latest commit, but it doesn't look like it will finish tonight. Still, it's way past the point of the crash I was having, so I'm confident that your fix solves the problem. I should note for the record that I also have the May 28 patch (https://bugs.freebsd.org/bugzilla/attachment.cgi?id=260841) from bug #279705 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279705) updating textproc/libxml2 locally applied for this build. (And I have my conflicting version of boost-libs still installed.) I hope to report success tomorrow morning.