Summary: | app-pda/libplist-2.2.0-r2 - ../src/.libs/libplist-2.0.so: error: undefined reference to 'fmin' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Fabio Coatti <fabio.coatti> |
Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jer |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
config.log |
Description
Fabio Coatti
2020-08-12 10:47:51 UTC
Created attachment 654308 [details]
build.log
checking if fmin is a builtin function... yes Why does it say that? Could you please attach the config.log, too? (In reply to Fabio Coatti from comment #0) > LDFLAGS="-Wl,--as-needed -O2 -pipe" does not equal > LDFLAGS="-Wl,-O1 -Wl,--as-needed -march=native -O3 -fgraphite-identity > -floop-nest-optimize -ftree-loop-distribution -flto=4 -fuse-linker-plugin > -pipe -fpie -fpic -fstack-protector-strong -fstack-clash-protection > -Wl,--as-needed -Wl,--hash-style=gnu" but assuming you *also* tested with the former and saw the same failure, rendering my observation entirely beside the purpose of this bug report, I must say that those are the weirdest LDFLAGS I have ever seen. (In reply to Jeroen Roovers from comment #3) > (In reply to Fabio Coatti from comment #0) > > LDFLAGS="-Wl,--as-needed -O2 -pipe" > > does not equal > > > LDFLAGS="-Wl,-O1 -Wl,--as-needed -march=native -O3 -fgraphite-identity > > -floop-nest-optimize -ftree-loop-distribution -flto=4 -fuse-linker-plugin > > -pipe -fpie -fpic -fstack-protector-strong -fstack-clash-protection > > -Wl,--as-needed -Wl,--hash-style=gnu" > > but assuming you *also* tested with the former and saw the same failure, > rendering my observation entirely beside the purpose of this bug report, I > must say that those are the weirdest LDFLAGS I have ever seen. Yep, I concur, I indeed like to play around with compilation flags.However, As you may see from the build log, in this case the compilation was done with rather common CFLAGS/LDFLAGS. It could be that this behavior is somehow triggered by other packages CFLAGS, but I fail to see how. Anyway. While looking around I found this bug report, not sure if it can be related: https://github.com/libimobiledevice/libplist/issues/157 (In reply to Fabio Coatti from comment #4) > https://github.com/libimobiledevice/libplist/issues/157 Nobody attached their config.log there either: (In reply to Jeroen Roovers from comment #2) > checking if fmin is a builtin function... yes > > Why does it say that? Could you please attach the config.log, too? The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=04014b1e2768aa4d0747c44b7a0c0b473f5a4e04 commit 04014b1e2768aa4d0747c44b7a0c0b473f5a4e04 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-08-13 07:58:56 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-08-13 08:06:58 +0000 app-pda/libplist: Simplify configure test for fmin https://github.com/libimobiledevice/libplist/pull/168 Package-Manager: Portage-3.0.2, Repoman-2.3.23 Bug: https://bugs.gentoo.org/736866 Signed-off-by: Jeroen Roovers <jer@gentoo.org> app-pda/libplist/files/libplist-2.2.0-fmin.patch | 34 ++++++++++++++++++++++ .../files/libplist-2.2.0-pkgconfig-lib.patch | 5 ++-- app-pda/libplist/libplist-2.2.0-r2.ebuild | 5 +++- 3 files changed, 40 insertions(+), 4 deletions(-) Created attachment 654420 [details]
config.log
And here is the config.log. Sorry for the delay :)
(In reply to Fabio Coatti from comment #7) > Created attachment 654420 [details] > config.log configure:12869: checking if fmin is a builtin function configure:12892: x86_64-pc-linux-gnu-gcc -o conftest -O0 -Wl,--as-needed -O2 -pipe conftest.c -lpthread >&5 configure:12892: $? = 0 configure:12900: result: yes For some reason I cannot fathom that "works" here but fails later on. I assume that upstream is using an incorrect combination of autoconf caching and AC_TRY_LINK (as well as LDFLAGS injection) here and have proposed a high level simplification upstream. Can you try again with the latest changes announced in comment #6, please? (In reply to Jeroen Roovers from comment #8) > > For some reason I cannot fathom that "works" here but fails later on. I > assume that upstream is using an incorrect combination of autoconf caching > and AC_TRY_LINK (as well as LDFLAGS injection) here and have proposed a high > level simplification upstream. > > Can you try again with the latest changes announced in comment #6, please? With those changes I can confirm that the compilation is successful, both with normal CFLAGS and "weird" ones, including LTO. If you need some info (dunno, for reference) from config.log just let me know. Anyway, many thanks for the real quick fix! |