Quoting the "Actual error log":

QUOTE
/usr/local/bin/clang++90
END QUOTE

Twice. I expect that earlier material in the
build log is likely relevant to why it it is
using clang 9.0 instead of something more modern
like 13 or 14.

The logic I see in the editors/libreoffice/Makefile
looks like:

.if ${PORT_OPTIONS:MLTO} && ${CHOSEN_COMPILER_TYPE} == clang
CPP=    ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT}
CC=     ${LOCALBASE}/bin/clang${LLVM_DEFAULT}
CXX=    ${LOCALBASE}/bin/clang++${LLVM_DEFAULT}
BUILD_DEPENDS+= ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT}
LLD_UNSAFE=     yes
.endif

That should mean that LLVM_DEFAULT ended up as "90",
not "13" or "14".

What has presented does not appear to be enough to
trace back to why "90" was in use.

(In reply to Mark Millard from comment #1)

Strange.
editors/libreoffice built just fine at port main git b305ea3361859bddd115ea9748fb89fbc85f20a8.

This was upgrade to 7.3.3 and next and most recent commit was just a bump for graphics/poppler update.

And unfortunately, build error on my previous post was copy/pasted from terminal emulator screen and no build log kept.

I'll try again without /etc/make.conf kludge when I can take enough time.
(editors/libreoffice is large enough to consume a plenty of time on build.)

(In reply to Tomoaki AOKI from comment #2)

The FreeBSD build servers are not having problems building.
For example,

http://beefy18.nyi.freebsd.org/build.html?mastername=main-amd64-default&build=pa3e075eb6037_s5af718a592

(that is still ongoing) shows editors/libreoffice in the
built list. Some details are below (from its build log).

The log show that it is using the system-clang compiler
and system-lld linker (so from llvm14), even though
devel/llvm13 is installed for the build.

=>> Building editors/libreoffice
build started at Sat May 21 04:48:00 UTC 2022
port directory: /usr/ports/editors/libreoffice
package name: libreoffice-7.3.3.2_1
building for: FreeBSD main-amd64-default-job-02 14.0-CURRENT FreeBSD 14.0-CURRENT 1400059 amd64
maintained by: office@FreeBSD.org
Makefile ident: 
Poudriere version: 3.2.8-21-g883afb07
Host OSVERSION: 1400050
Jail OSVERSION: 1400059
Job Id: 02
. . .
---Begin OPTIONS List---
===> The following configuration options are available for libreoffice-7.3.3.2_1:
     COINMP=off: Enable CoinMP (deprecated) math solver
     CUPS=on: CUPS printing system support
     DOCS=on: Build and/or install documentation
     GNOME=off: GNOME desktop environment support
     GTK3=off: GTK+ 3 GUI toolkit support
     GTK4=off: GTK+ 4 GUI toolkit support (broken)
     JAVA=on: Add Java support (XML filters, macros, DB connections)
     KF5=off: KF5/Qt5 GUI toolkit support (implies QT5)
     LTO=off: Use Link-Time Optimization
     MARIADB=off: Build with MariaDB/MySQL-SDBC driver
     MMEDIA=on: Enable multimedia backend for Impress
     PDFIUM=on: Enable PDFium secure engine
     PGSQL=off: Build with PostgreSQL-SDBC driver
     QT5=on: Qt5 GUI toolkit support (default visual style)
     SDK=off: Build with SDK
     TEST=off: Run all regression tests
     WEBDAV=off: Enable WebDAV protocol
===> Use 'make config' to modify these settings
---End OPTIONS List---
. . .
[main-amd64-default-job-02] |   `-- Installing llvm13-13.0.1_2...
[main-amd64-default-job-02] |   | `-- Installing lua53-5.3.6...
[main-amd64-default-job-02] |   | `-- Extracting lua53-5.3.6: .......... done
[main-amd64-default-job-02] |   `-- Extracting llvm13-13.0.1_2: .......... done
. . .
checking for cc... /usr/bin/cc
. . .
checking whether the compiler is actually Clang... yes
checking whether Clang is new enough... yes (14.0.3)
. . .
checking for linker that is used... LLD 14.0.3 (FreeBSD llvmorg-14.0.3-0-g1f9140064dfb-1400004) (compatible with GNU linkers)
. . .
=======================<phase: package        >============================
===>  Building package for libreoffice-7.3.3.2_1
===========================================================================
=>> Cleaning up wrkdir
===>  Cleaning for libreoffice-7.3.3.2_1
build of editors/libreoffice | libreoffice-7.3.3.2_1 ended at Sat May 21 09:12:11 UTC 2022
build time: 04:24:11

Created attachment 234109 [details]
Reproduced full build log

Full build log with .txz archived. Same error mode is reproduced.
Forcibly rebuilt with commented out workaround on /etc/make.conf.

Build options are as below.

OPTIONS_FILE_UNSET+=COINMP
OPTIONS_FILE_SET+=CUPS
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_UNSET+=GNOME
OPTIONS_FILE_UNSET+=GTK3
OPTIONS_FILE_UNSET+=GTK4
OPTIONS_FILE_SET+=JAVA
OPTIONS_FILE_UNSET+=KF5
OPTIONS_FILE_SET+=LTO
OPTIONS_FILE_UNSET+=MARIADB
OPTIONS_FILE_SET+=MMEDIA
OPTIONS_FILE_SET+=PDFIUM
OPTIONS_FILE_UNSET+=PGSQL
OPTIONS_FILE_SET+=QT5
OPTIONS_FILE_UNSET+=SDK
OPTIONS_FILE_UNSET+=TEST
OPTIONS_FILE_UNSET+=WEBDAV

(In reply to Mark Millard from comment #3)

Can OPTIONS_FILE_SET+=LTO affects this behaviour?
Or devel/llvm90 are always used if installed and "DEFAULT_VERSIONS+= llvm=13" is not set?

 *devel/llvm90 is installed as an dependency of devel/rust-bindgen.
  devel/llvm13 is installed as an dependency of graphics/mesa-dri.

IIUC, Poudriere (I myself don't use it) builds inside jail that is no ports is installed and build dependencies every time (or install them via pkg every time).
If it's correct, no devel/llvm* ports are used even if any of them are installed on base environment, thus does not affect.

For record: I usually update/install ports with ports-mgmt/portupgrade-devel.
If bitten by any error that is a result of known portupgrade problem, switch to ports-mgmt/pkg_replace.

(In reply to Tomoaki AOKI from comment #5)

The FreeBSD build servers work by using poudriere bulk . So
what I reported in Comment #3 indicates that, for how they
work, devel/llvm13 is installed during the specific build
of editors/libreoffice . (I build ports via poudriere-devel
myself.) It is possible that some other port, that is needed
to build editors/libreoffice , in turn has as a runtime
dependency devel/llvm13 . (So the install is indirect rather
than direct.)

The:

OPTIONS_FILE_SET+=LTO

uses ( quoting what I reported in Comment #1 ):

.if ${PORT_OPTIONS:MLTO} && ${CHOSEN_COMPILER_TYPE} == clang
CPP=    ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT}
CC=     ${LOCALBASE}/bin/clang${LLVM_DEFAULT}
CXX=    ${LOCALBASE}/bin/clang++${LLVM_DEFAULT}
BUILD_DEPENDS+= ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT}
LLD_UNSAFE=     yes
.endif

In turn the modern Mk/bsd.default-versions.mk has:

LLVM_DEFAULT?=         90

which is where the "90" is from in your build unless
you are (possibly indirectly) assigning LLVM_DEFAULT
yourself, such a via your:

DEFAULT_VERSIONS+=      llvm=13

use.

Looks like the subject line's reference to "llvm/clang14"
is just incorrect at this point: that vintage has not been
tried yet by you from what I can see. (Without LTO the
system's llvm14 toolchain would be used, but you are
trying LTO.)

So far as I can tell, what is in your original description
is all expected behavior for your context and the real
complaint is that the port does not force an appropriate
llvm vintage when LTO is specified, leaving you to manually
manage that aspect, without giving  you notice of such a
status.

(In reply to Mark Millard from comment #6)

OK. Agreed why devel/llvm90 was used.

Let's explain why I wrote the subject as such.

First of all, I've never changed the options throuout the revs specified below.

On upgrading editors/libreoffice

 from:
   git ca1c4839224a639c0ddd602a21b942efa4ca0952
     editors/libreoffice: fix i386/powerpc libcxxrt ABI change detection

 to:
   git b305ea3361859bddd115ea9748fb89fbc85f20a8
     editors/libreoffice: update to 7.3.3 release (+)

 base clang: before llvm/clang14 import

built fine. I already had devel/llvm90 as an dependency of other port.


On upgrading editors/libreoffice
 from:
   git b305ea3361859bddd115ea9748fb89fbc85f20a8
     editors/libreoffice: update to 7.3.3 release (+)

 to:
   git f22f615ec337d1c92d021ad4ecd1d2e83cfc4af5
     graphics/poppler: bump portrevision of consumers

   base clang: at llvm 14
     base git 14c99b43ef69beafa01a1574641c4cf19ecf2b9d, just after
     llvm14 import (3a9a9c0ca44ec535dcf73fe8462bee458e54814b)

which was just a PORTREVISION bump, I've bitten by the problem.
This time, setting "DEFAULT_VERSIONS+= llvm=13" for editors/libreoffice
allowed me to build.


So I thought base llvm/clang14 somehow affecting.
This still confuses me.

(In reply to Tomoaki AOKI from comment #7)

Your use of:

OPTIONS_FILE_SET+=LTO

causes:

.if ${PORT_OPTIONS:MLTO} && ${CHOSEN_COMPILER_TYPE} == clang
CPP=    ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT}
CC=     ${LOCALBASE}/bin/clang${LLVM_DEFAULT}
CXX=    ${LOCALBASE}/bin/clang++${LLVM_DEFAULT}
BUILD_DEPENDS+= ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT}
LLD_UNSAFE=     yes
.endif

to be used. But if you do not use LTO that code is not
used and the system toolchain is used.

Going back to the use of LTO case to provide more
description of it . . .

LTO use in turn causes use of ${LLVM_DEFAULT} in the
places shown above. It no longer uses the system toolchain
but instead uses devel/llvm${LLVM_DEFAULT} .

If you leave LLVM_DEFAULT at its default you get devel/llvm90
as the toolchain. If you assign a different default, you get
what you assign, such as when you assigned 13 and got
devel/llvm13 .

If you want devel/llvm14 to be used, one way is to use:

if ${.CURDIR:M/usr/ports/editors/libreoffice}
DEFAULT_VERSIONS+=      llvm=14
.endif

in your /etc/make.conf file. If you do this, it seems
unlikely that you would get the same failure that you get
with devel/llvm90 in use. If it is really different, that
would make the subject line for this bugzilla report
incorrect/misleading.

(In reply to Mark Millard from comment #8)

Finished the build I've started before sleep was successful with
 *Workaround in /etc/make.conf is commented out.
 *LTO=off
on main.

Didn't uploaded the log, though, but base clang14 seems to be used.

Still confusing why my previous update of editors/libreoffice at git b305ea3361859bddd115ea9748fb89fbc85f20a8 was successful with same configuration I've bitten this time thogh, I've edited the subject.

At least, LTO option should imply dependency to proper devel/llvm*.
13 would be a good candidate, but not sure 10 through 12 are OK, too or not.

Comment 10 Dimitry Andric 2022-05-22 22:07:41 UTC

(In reply to Mark Millard from comment #8)
Yes, indeed the question is why it's choosing clang 9.0 by default. Maybe this is because of your other make.conf settings?

(In reply to Dimitry Andric from comment #10)

Tomoaki AOKI is the one building with LTO enabled
and hitting the odd way editors/libreoffice is
set up for handling such. My normal activities do
not include building editors/libreoffice.

editors/libreoffice is set up to not use devel/llvm*
at all when LTO is off and to use
devel/llvm${LLVM_DEFAULT} when LTO is turned on.
That is the way its Makefile ends up working.

As far as I can tell, if one forced LTO to be off
but also forced LLVM_DEFAULT=90 , the compile error
reported would still happen: devel/llvm90 is
apparently too old to be used.

But if one forces LTO to be on but does not also force
a specific devel/llvm* to be used, one ends up with
devel/llvm90 and ends up with the compile errors
reported.

So, as editors/libreoffice is set up, to use LTO
one must also control which devel/llvm* is used
to form a coherent combination.

There may be a better way for editors/libreoffice
to be set up --but I've not been working on proposing
changes, just documenting the current status and why
the reported things happened and why they were not
llvm 14 tied.

(In reply to Tomoaki AOKI from comment #9)

QUOTE
At least, LTO option should imply dependency to proper devel/llvm*.
13 would be a good candidate, but not sure 10 through 12 are OK, too or not.
END QUOTE

I do consider what editors/libreoffice does odd but
I'm not trying to propose changes. I leave that to
fluffy@FreeBSD.org (the maintainer) to potentially
decide what changes would be appropriate (if any).
Hopefully, some of the notes in the comments for this
bugzilla submittal would be useful to for making
such judgments.

As for "previous update of editors/libreoffice": I have no
way to analyze or confirm vs. deny many details for that
prior overall context and so basically have to ignore it.
I'm sticking to evidence I can investigate independently
and am otherwise silent.

(In reply to Dimitry Andric from comment #10)

Mk/bsd.default-versions.mk has

.  if ${ARCH} == powerpc
LLVM_DEFAULT?=          10
.  else
LLVM_DEFAULT?=          90
.  endif

lines in it, so unless otherwise specified, 90 is preferred except powerpc.
Maybe editors/libreoffice should specify known-to-be-safe one in its Makefile
if LTO=on.

Looking into dependents on FreshPorts, 10 and 11 have few dependencies, while 12 and 13 has more dependents, including mesa related ones (except mesa-dri) for 12 and chromium, firefox, mesa-dri,... for 13.
So I think 10 and 11 would not be a proper option, even if they are fine for lireoffice.

As other giants (www/chromium, www/firefox, ...) use 13, and I've already confirmed 13 is OK, I'd like to suggest 13 as default for editors/libreoffice, too.

(In reply to Tomoaki AOKI from comment #13)

The note's wording presumes that LTO has been enabled.
Otherwise no devel/llvm* is used at all that way
editors/libreoffice is currently set up. The only thing
that creates a use of a devel/llvm* is the code that I
keep quoting from editors/libreoffice/Makefile :

QUOTE
.if ${PORT_OPTIONS:MLTO} && ${CHOSEN_COMPILER_TYPE} == clang
CPP=    ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT}
CC=     ${LOCALBASE}/bin/clang${LLVM_DEFAULT}
CXX=    ${LOCALBASE}/bin/clang++${LLVM_DEFAULT}
BUILD_DEPENDS+= ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT}
LLD_UNSAFE=     yes
.endif
END QUOTE

That code is only for LTO enabled --with a clang
compiler type also identified. Otherwise, no
port-based toolchain is caused to be used.

Confirmed with 7.3.3.2_3, it uses llvm90 and fails in the same way (LTO=on).

(In reply to jakub_lach from comment #15)

With llvm14 from ports it fails too - 

In file included from /usr/obj/usr/ports/editors/libreoffice/work/libreoffice-7.3.3.2/workdir/UnpackedTarball/skia/src/opts/SkOpts_sse42.cpp:11:                                                                                        
/usr/obj/usr/ports/editors/libreoffice/work/libreoffice-7.3.3.2/workdir/UnpackedTarball/skia/src/o                                    pts/SkChecksum_opts.h:25:16: error: always_inline function '_mm_crc32_u64' requires target feature                                     'crc32', but would be inlined into function 'crc32c_8' that is compiled without support for 'crc3                                                           2'                                                                                                          
        return _mm_crc32_u64(seed, v);                                                                                                                                   
               ^                                                                                                                      
/usr/obj/usr/ports/editors/libreoffice/work/libreoffice-7.3.3.2/workdir/UnpackedTarball/skia/src/o                                   pts/SkChecksum_opts.h:22:66: error: always_inline function '_mm_crc32_u32' requires target feature                                    'crc32', but would be inlined into function 'crc32c_4' that is compiled without support for 'crc3                                                                                2'                                                                                                          
    static uint32_t crc32c_4(uint32_t seed, uint32_t v) { return _mm_crc32_u32(seed, v); }                                                        
                                                                 ^
/usr/obj/usr/ports/editors/libreoffice/work/libreoffice-7.3.3.2/workdir/UnpackedTarball/skia/src/opts/SkChecksum_opts.h:21:66: error: always_inline function '_mm_crc32_u8' requires target feature 'crc32', but would be inlined into function 'crc32c_1' that is compiled without support for 'crc32'
    static uint32_t crc32c_1(uint32_t seed, uint8_t  v) { return _mm_crc32_u8(seed, v); }
                                                                 ^
3 errors generated.
gmake[3]: *** [/usr/obj/usr/ports/editors/libreoffice/work/libreoffice-7.3.3.2/solenv/gbuild/LinkTarget.mk:400: /usr/obj/usr/ports/editors/libreoffice/work/libreoffice-7.3.3.2/workdir/GenCxxObject/UnpackedTarball/skia/src/opts/SkOpts_sse42.o] Error 1
gmake[3]: *** Waiting for unfinished jobs....


FWI - Penryn (here) does not have sse42

(In reply to jakub_lach from comment #16)

FWIW, 

.if ${.CURDIR:M/usr/ports/editors/libreoffice}
DEFAULT_VERSIONS+=llvm=13
.endif

compiles (LTO=on)

(In reply to jakub_lach from comment #17)

FWIW, after update to libreoffice-7.4.0.3 compilation with LTO=on failed during linking. 

Since the, after removing -

if ${.CURDIR:M/usr/ports/editors/libreoffice}
DEFAULT_VERSIONS+=      llvm=13
.endif

I've updated to libreoffice-7.4.0.3 successfully.