ons 2014-07-16 klockan 22:41 +0200 skrev Emilio Pozuelo Monfort:
> Source: gfal2
> Version: 2.3.0-4
> Severity: serious
> 
> Doing rebuilds for the libgsoap5 transition, your package failed to build
> everywhere except on amd64, i386 and hurd-i386. That seems to be because
> in those builds, the version of libcgsi-gsoap1 was 1.3.6-1 (i.e. before the
> binNMU for libgsoap5) while on the builds that failed libcgsi-gsoap1 was at
> 1.3.6-1+b1. The error was:
> 
> /usr/bin/c++   -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
> -Werror=format-security -D_FORTIFY_SOURCE=2    -Wl,-z,relro 
> CMakeFiles/unit_test_srm_plugin.dir/tests_srm.cpp.o  -o unit_test_srm_plugin  
> -L/«PKGBUILDDIR»/obj-arm-linux-gnueabihf/src  
> -L/«PKGBUILDDIR»/obj-arm-linux-gnueabihf/plugins -rdynamic 
> ../../../../src/libgfal2.so.2.3.0 -lgfal_srm_ifce -lgfal_transfer 
> -lgfal_plugin_srm -lm ../../../../src/libgfal2.so.2.3.0 
> ../../../gtest/libgtest.a ../../../gtest/libgtest_main.a -luuid -lstdc++ 
> -lglib-2.0 -lgthread-2.0 -lglib-2.0 -lgthread-2.0 -ldl 
> ../../../gtest/libgtest.a -lpthread 
> -Wl,-rpath,/«PKGBUILDDIR»/obj-arm-linux-gnueabihf/src:/«PKGBUILDDIR»/obj-arm-linux-gnueabihf/plugins
>  
> //usr/lib/libcgsi_plugin.so.1: undefined reference to 
> `soap_init_LIBRARY_VERSION_REQUIRED_20817'
> collect2: error: ld returned 1 exit status
> make[4]: *** [test/unit/common/srm/unit_test_srm_plugin] Error 1
> 
> I'm filing this against gfal2, although it bothers me that the libraries
> shipped by libcgsi-gsoap1 have undefined references. But that's been
> happening for a long time, so filing here. Please reassign if necessary.
> 
> Emilio

The failure is not caused by that the binnmu for cgsi-gsoap had
happened, but because the binnmu for srm-ifce had not happened. Now that
the binnmus for srm-ifce has completed the builds of gfal2 shouldn't
have any problems. If you try to build against a cgsi-gsoap that has
been rebuilt and an srm-ifce that has not you are using an incompatible
set of dependencies and your build is expected to fail. That it fails
instead of creating a broken binary is a good thing.

That the libraries in libcgsi-gsoap1 have undefined references is by
construction, they are deliberately left unresolved in order to make it
possible for different users of the library to choose different
implementations of these functions. Explicitly linking these libraries
to one implementation will introduce breakage.

The binnmu of lcgdm is similar. Only amd64 was tried so far and failed
because it was using a cgsi-gsoap that had not been recompiled (and
therefore expects gsoap4) together with the new gsoap5. After the
cgsi-gsoap has been rebuilt the lcgdm rebuild will work just fine.

I think you have unreasonable expectations if you expect interdependent
packages to be able to binnmu in random order.

This is not a permanent FTBFS. It is a transient state that exist during
the transition when some packages have been rebuilt and some not.

(The virtuabox package needs fixing for unrelated reasons, it bails out
if the gcc version detected in greater than 4.8.)

        Mattias

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to