Summary: | most static lib's emerged with lto cannot be linked against: "undefined reference to ..." | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Klaus Kusche <klaus.kusche> |
Component: | Current packages | Assignee: | Richard Freeman <rich0> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | paolo.pedroni |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 618550 |
Description
Klaus Kusche
2016-08-17 19:08:02 UTC
please attach full build.log (In reply to Alex Xu (Hello71) from comment #1) > please attach full build.log I can't, at least not easily. My build logs are on a RAM disk, and gone since yesterday night. To reproduce the error in the dar build, I would need some way to undo the effect of "ar s" on the six libraries I fixed yesterday (my libraries are fixed now, so dar currently builds fine). Is there an easy way to do so? Besides, I don't think that this is a problem of the dar build, that's why I didn't enter the dar component in the description of this bug: I extracted the link command from the log, tried it on the command line, reduced it to the absolute minimum needed to link dar_static, and it also failed in the same way, although the command was absolutely correct and reasonable (the same one would use for linking "by hand"). The fact that "ar s" on the libraries fixed the problem indicates that the libs were broken, but these lib's are not generated by the dar build, but by sys-apps/attr, app-arch/bzip2, dev-libs/lzo, sys-libs/zlib, sys-libs/libcap and app-arch/xz-utils. These seem to cause the problem (or there is something wrong with building static-libs in general on my system). The static libs on my system seem to already have an index, so I would guess that something strange happened on your system. Please always attach a full build log when reporting a build failure. (In reply to Mike Gilbert from comment #3) > The static libs on my system seem to already have an index, so I would guess > that something strange happened on your system. I re-emerged the libs. They actually all have an archive index, but it is broken and results in an un-linkable lib, because it only contains lto info and not the linkable symbols. Example libattr.a: nm -s after emerging: Archive index: __gnu_lto_v1 in libattr.o __gnu_lto_slim in libattr.o __gnu_lto_v1 in attr_copy_fd.o __gnu_lto_slim in attr_copy_fd.o __gnu_lto_v1 in attr_copy_file.o __gnu_lto_slim in attr_copy_file.o __gnu_lto_v1 in attr_copy_check.o __gnu_lto_slim in attr_copy_check.o __gnu_lto_v1 in attr_copy_action.o __gnu_lto_slim in attr_copy_action.o __gnu_lto_v1 in syscalls.o __gnu_lto_slim in syscalls.o ==> emerging dar fails nm -s after ar s: Archive index: attr_get in libattr.o attr_getf in libattr.o attr_set in libattr.o attr_setf in libattr.o attr_remove in libattr.o attr_removef in libattr.o attr_list in libattr.o attr_listf in libattr.o attr_multi in libattr.o attr_multif in libattr.o attr_copy_fd in attr_copy_fd.o attr_copy_file in attr_copy_file.o attr_copy_check_permissions in attr_copy_check.o attr_copy_action in attr_copy_action.o setxattr in syscalls.o lsetxattr in syscalls.o fsetxattr in syscalls.o getxattr in syscalls.o lgetxattr in syscalls.o fgetxattr in syscalls.o listxattr in syscalls.o llistxattr in syscalls.o flistxattr in syscalls.o removexattr in syscalls.o lremovexattr in syscalls.o fremovexattr in syscalls.o ==> emerging dar works Exactly the same for almost all other static lib's I checked (not only the six packages mentioned in this bug report, but also e.g. libjemalloc, libtasn1, the multimedia codec libs, ...), only glibc and boost seem to produce correct .a libs. So building the static libs with lto is the culprit. Emerging the libs without lto results in correct archive indices, and dar emerges fine afterwards. However, building the libs without lto would mean that lto is lost also for all dynamically linked executables using these libs, so that's an ugly workaround. Please re-assign to gcc, binutils, libtool or whatever. This problem has nothing to do with dar, but only with the creation of static libs, for almost any ebuild. I tried to emerge some other packages which are expected to produce statically linked executables (e.g. libarchive after applying the fixes described in bug 591096), and I also tried to link some of my own programs statically, and all failed in the same way when linking: Most of the lib*.a libraries produced by emerging a package with USE=static-libs and with lto cannot be linked against because the linker is unable to find the symbols provided by the lib. The problem occurs with .a libs from more than a dozen ebuilds, and for any link target executable. Applying "ar s" to all the .a libs or re-emerging all the .a lib without lto fixes the problem: After that, the static executables link without problems. However, just dropping lto from many of the important lib's in the system just to get working static libs is not an option (because it also affects the performance of all dynamically linked libs and programs). Have you tried adding -ffat-lto-objects to the CFLAGS of the problematic package? This might solve your problem. *** This bug has been marked as a duplicate of bug 603594 *** |