On Thu, Aug 06, 2020 at 05:04:20PM +0200, Florian Weimer wrote: > * Daniel P. Berrangé: > > > This is in relation to this bug > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1862745 > > > > The last but one build of libgphoto have auto-provides for the ELF > > libraries: > > > > libgphoto2 = 2.5.24-2.fc33 > > libgphoto2(x86-64) = 2.5.24-2.fc33 > > libgphoto2.so.6()(64bit) > > libgphoto2_port.so.12()(64bit) > > libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit) > > libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit) > > > > any new build both in the mass rebuild and any scratch builds I try > > looses some of these auto deps leaving just > > > > libgphoto2 = 2.5.24-3.fc33 > > libgphoto2(x86-64) = 2.5.24-3.fc33 > > libgphoto2.so.6()(64bit) > > libgphoto2_port.so.12()(64bit) > > > > > > Was there any change people are aware of that would explain this and > > suggest what we need todo to get these deps back in libghoto ? > > I think this isn't the real issue. As far as I can tell, all the symbol > versioning information is gone. The RPM dependencies are correct, but > the ABI is not. 8-p Doh, yes, it didn't even occur to me to check the actual symbol versioning in the library :-( > configure.ac has this: > > AC_MSG_CHECKING([for asm .symver support]) > AC_COMPILE_IFELSE([dnl > AC_LANG_PROGRAM([[]],[[ > int f1() { } > int f2() { } > asm(".symver f1, f@VER1"); > asm(".symver f2, f@@VER2"); > int main(int argc, char **argv) { } > ]])dnl > ],[ > AC_DEFINE([HAVE_ASM_SYMVERS],1,[Define if there is asm .symver support.]) > VERSIONMAPLDFLAGS="-Wl,--version-script=\$(srcdir)/libgphoto2.ver" > AC_MSG_RESULT(yes) > ],[ > VERSIONMAPLDFLAGS="" > AC_MSG_RESULT(no) > ]) > AC_SUBST(VERSIONMAPLDFLAGS) > > And build.log shows: > > checking for asm .symver support... no > > The HAVE_ASM_SYMVERS macro is apparently unused, but setting > VERSIONMAPLDFLAGS looks *very* relevant. > > The cause seems to be this: > > /tmp/ccAbnnro.s: Assembler messages: > /tmp/ccAbnnro.s: Error: invalid attempt to declare external version name > as default in symbol `f@@VER2' > > It's LTO-related in the sense that f1 & f2 get different symbols with > LTO. This fixes the test: > > int __attribute__ ((externally_visible)) f1() { } > int __attribute__ ((externally_visible)) f2() { } > asm(".symver f1, f@VER1"); > asm(".symver f2, f@@VER2"); > int main(int argc, char **argv) { } This didn't work, because the problem was slightly more subtle... This AC_LANG_PROGRAM call puts the code snippet inside a main() { ...} so what configure was actually attempting to compile is: int main () { int f1() { } int f2() { } asm(".symver f1, f@VER1"); asm(".symver f2, f@@VER2"); int main(int argc, char **argv) { } ; return 0; } clearly this code is nonsense, but by luck it still worked until newer GCC came along. The code has to be passed as the first arg of AC_LANG_PROGRAM, not the second arg, so that its outside the main() {...} Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
