On 17/07/14 09:20, Mattias Ellert wrote: > > 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.
If that's unsupported, then different libgsoap should probably conflict against each other. > 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. Maybe at this point it would, but I would have expected the libraries in libcgsi-gsoap1 to link against libgsoap.so, and then end users or applications could set LD_PRELOAD or LD_LIBRARY_PATH to load a different implementation of libgsoap.so. But that would only work if all the different implementations had the same SONAME (but not necessarily the same file name). > 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. I disagree. But next time open a transition bug and let us know what binnmus need to be scheduled and in what order, so that we don't have to guess things and end in situations like this. > 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.) Yes, I opened a bug about that before this transition started. Feel free to NMU that :-) Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
