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 ?


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 :|

[Florian Weimer]

* 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

[Jeff Law]

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

[Daniel P. Berrangé]

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 :|

[Florian Weimer]

* 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