when build lxc w/ clang, the build failed with: ERROR: LLVM's thinLTO only works with gnu gold, lld, lld-link, and ld64, not ld.bfd This is probably a meson issue, but I'm not sure. see https://github.com/mesonbuild/meson/issues/10798 Build temporary fixed by following patch, change LTO mode to default. diff --git a/meson.build b/meson.build index 5d1bb36..351f832 100644 --- a/meson.build +++ b/meson.build @@ -8,7 +8,7 @@ project( license: 'LGPLv2+', default_options: [ 'b_lto=true', - 'b_lto_mode=thin', + 'b_lto_mode=default', 'b_colorout=always', 'b_asneeded=true', 'b_pie=true', Reproducible: Always
Please attach full build.log and paste emerge --info. Afterwards, please re-open.
Created attachment 805411 [details] emerge --info
Created attachment 805414 [details] build.log
Created attachment 805417 [details] meson-log.txt
Created attachment 805420 [details, diff] patch to change lto mode
please see attachments for the required info, thanks.
I don't understand. It doesn't looke like you have lto enabled... do you? I see your emerge --info lists clang as CC so indeed why are you using bfd with clang? Anyway I don't seem to have problems, # cat /var/db/pkg/app-containers/lxc-5.0.1/CC clang # cat /var/db/pkg/app-containers/lxc-5.0.1/CFLAGS -march=native -O3 -pipe -flto=thin
Are you saying that with clang, it tries to automatically use LTO even when you haven't set it yourself?
I can't see lto being enabled anywhere, but I wonder how to print whatever the project forces on. I wonder if this is a meson or lxc bug. On a GCC system: # CC="clang" CXX="clang++" emerge -1 lxc --usepkg=n --buildpkg=n results in ERROR: LLVM's thinLTO only works with gnu gold, lld, lld-link, and ld64, not ld.bfd but my meson.log or build.log doesn't show lto being enabled.
May need environment file from OP too...
So does look like lxc upstream enables lto via meson options: default_options: [ 'b_lto=true', 'b_lto_mode=thin', but it's meson that gets the thin wrong, I think.
lxc's meson.build file sets the default (unless you pass your own -Db_lto=false in MYMESONARGS) value of lto to: - on - specifically thin Meson isn't getting anything "wrong" here, you (that is, the lxc project, not the gentoo bug reporter) explicitly requested something that Meson believes it cannot fulfill, so it raises an error. Ignoring the mode=thin is IMO not an option -- if you ask for it, Meson shouldn't successfully ignore it. In mesonbuild/compilers/mixins/clang.py : ``` if mode == 'thin': # Thin LTO requires the use of gold, lld, ld64, or lld-link if not isinstance(self.linker, (AppleDynamicLinker, ClangClDynamicLinker, LLVMDynamicLinker, GnuGoldDynamicLinker)): raise mesonlib.MesonException(f"LLVM's thinLTO only works with gnu gold, lld, lld-link, and ld64, not {self.linker.id}") args.append(f'-flto={mode}') ``` If, as the linked Meson ticket asks about, that is no longer true (you can patch out the middle 3 lines and locally test), then Meson could be changed to enable the clang+bfd combination. But that would require testing and confirmation, and seems unlikely.
yes, I 've said that this might be the problem of meson. The issue (https://github.com/mesonbuild/meson/issues/10798) was submited by me too. But I'm not familar w/ the internals of thinLTO, I did a simple test w/ cland and ldd.bfd, it seems work, but I just can't conclude that the assertion of meson is wrong. (In reply to Eli Schwartz from comment #12) > lxc's meson.build file sets the default (unless you pass your own > -Db_lto=false in MYMESONARGS) value of lto to: > > - on > - specifically thin > > Meson isn't getting anything "wrong" here, you (that is, the lxc project, > not the gentoo bug reporter) explicitly requested something that Meson > believes it cannot fulfill, so it raises an error. > > Ignoring the mode=thin is IMO not an option -- if you ask for it, Meson > shouldn't successfully ignore it. > > In mesonbuild/compilers/mixins/clang.py : > > ``` > if mode == 'thin': > # Thin LTO requires the use of gold, lld, ld64, or lld-link > if not isinstance(self.linker, (AppleDynamicLinker, > ClangClDynamicLinker, LLVMDynamicLinker, GnuGoldDynamicLinker)): > raise mesonlib.MesonException(f"LLVM's thinLTO only works > with gnu gold, lld, lld-link, and ld64, not {self.linker.id}") > args.append(f'-flto={mode}') > ``` > > If, as the linked Meson ticket asks about, that is no longer true (you can > patch out the middle 3 lines and locally test), then Meson could be changed > to enable the clang+bfd combination. But that would require testing and > confirmation, and seems unlikely.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c67d9ff4be934959df1ae631fcb9c5c50c7a1faf commit c67d9ff4be934959df1ae631fcb9c5c50c7a1faf Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-09-18 07:18:28 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-09-18 07:18:28 +0000 app-containers/lxc: add "lto" use flag - upstream enables lto unconditionally which causes all kinds of issues for us with different linkers available. Closes: https://bugs.gentoo.org/870178 Signed-off-by: Joonas Niilola <juippis@gentoo.org> app-containers/lxc/lxc-5.0.1-r1.ebuild | 166 +++++++++++++++++++++++++++++++++ app-containers/lxc/metadata.xml | 1 + 2 files changed, 167 insertions(+)
This should be handled by our ebuild now, but Liu, if you use system-wide clang you should also use lld. The simples way is to emerge sys-devel/clang with +default-lld USE flag configuration.
