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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
