Re: Lost ELF library auto-provides since mass rebuild
* Daniel P. Berrangé:
> 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.
I think it's actually a binutils change. Older binutils was happy to
apply .symver to undefined symbols, effectively ignoring the directive
(because there is nothing to attach it to). That changed in binutils
2.35, which started to diagnose the problem with an error.
> The code has to be passed as the first arg of AC_LANG_PROGRAM, not the
> second arg, so that its outside the main() {...}
Glad it's been fixed.
Thanks,
Florian
___
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
Re: Lost ELF library auto-provides since mass rebuild
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
Re: Lost ELF library auto-provides since mass rebuild
On Thu, 2020-08-06 at 17:04 +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
>
> 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) { }
>
> Not sure this was missed by Jeff's config.log differ. Maybe its
> binutils version was too old?
This package needs to opt-out of LTO.
libgphoto2 passed its control and LTO builds as well as the config.h check. So
I'm not sure what went wrong here.
jeff
___
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
Re: Lost ELF library auto-provides since mass rebuild
* 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
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) { }
Not sure this was missed by Jeff's config.log differ. Maybe its
binutils version was too old?
Thanks,
Florian
___
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
Lost ELF library auto-provides since mass rebuild
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 ? 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
