Bug#907358: ncbi-vdb: fix broken library on i386

2018-09-04 Thread Andreas Tille
On Tue, Aug 28, 2018 at 09:38:50PM +0200, Andreas Tille wrote:
> 
> So I did but was running into new problems which are caused by the hand
> craftet build system (yes, I tried to convince upstream to use some of
> the usual candidates but failed :-((( ).  I was able to add some missing
> libs in pbuilder chroot but whatever trick I try[1] the build system
> always constructs a different command line than I tested inside the
> pbuilder chroot.
> 
> Do you have any idea to stop this insane messing up with library options?

I fixed another library linking issue and stumbled about the next even
more complex one.  I gave up for the moment and deactivated the patch.
May be upstream becomes sane about their build system at some point in
time.

Thanks for your help in any case

  Andreas.

-- 
http://fam-tille.de



Bug#907266: Bug#907358: ncbi-vdb: fix broken library on i386

2018-08-28 Thread Steve Langasek
On Tue, Aug 28, 2018 at 09:38:50PM +0200, Andreas Tille wrote:
> > Also, this broken library package would have been detectable at build time
> > if you were building with -Wl,-z,defs in LDFLAGS, as that would have
> > prevented ever generating a shared library with missing symbols.  That's a
> > good idea to do anyway, but in particular it would mean that if you didn't
> > want to support i386 anymore, you could just add this to build flags and not
> > have to worry about changing the architecture list explicitly.

> So I did but was running into new problems which are caused by the hand
> craftet build system (yes, I tried to convince upstream to use some of
> the usual candidates but failed :-((( ).  I was able to add some missing
> libs in pbuilder chroot but whatever trick I try[1] the build system
> always constructs a different command line than I tested inside the
> pbuilder chroot.

> Do you have any idea to stop this insane messing up with library options?

> [1] 
> https://salsa.debian.org/med-team/ncbi-vdb/blob/master/debian/patches/fix_linking.patch

Failure I see in a local build is:

Try to add extra libs to LDFLAGS ... unfortunately this fails as well
CMD=gcc -shared -o 
/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib/libkdf5.so.2.9.2 
-Wl,-soname,libkdf5.so.2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now 
-Wl,-z,defs -Wl,--as-needed -g-ghdf5dir.pic.o hdf5file.pic.o 
hdf5arrayfile.pic.o 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/ilib -lhdf5_serial 
-lz -lmbedx509 -lmbedtls -lmbedcrypto -Wl,-Bstatic -Wl,-whole-archive -lklib 
-lkfs -Wl,-no-whole-archive -Wl,-Bdynamic -lbz2 -ldl -lpthread -lm -lkproc 
-lkfs -lkdb -lkns -lkfg
gcc -shared -o 
/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib/libkdf5.so.2.9.2 
-Wl,-soname,libkdf5.so.2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now 
-Wl,-z,defs -Wl,--as-needed -g-ghdf5dir.pic.o hdf5file.pic.o 
hdf5arrayfile.pic.o 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/ilib -lhdf5_serial 
-lz -lmbedx509 -lmbedtls -lmbedcrypto -Wl,-Bstatic -Wl,-whole-archive -lklib 
-lkfs -Wl,-no-whole-archive -Wl,-Bdynamic -lbz2 -ldl -lpthread -lm
/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/ilib/libklib.a(hashfile.pic.o):
 In function `map_calloc':
/tmp/ncbi-vdb/libs/klib/hashfile.c:288: undefined reference to `KLockAcquire'
/tmp/ncbi-vdb/libs/klib/hashfile.c:321: undefined reference to `KLockUnlock'
/tmp/ncbi-vdb/libs/klib/hashfile.c:328: undefined reference to `KLockUnlock'
[...]

When using -Wl,--as-needed, each object needs to be listed on the
commandline /after/ those objects that use it.

A correct commandline would be:

gcc -shared -o 
/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib/libkdf5.so.2.9.2 
-Wl,-soname,libkdf5.so.2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now 
-Wl,-z,defs -Wl,--as-needed -g-ghdf5dir.pic.o hdf5file.pic.o 
hdf5arrayfile.pic.o 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/lib 
-L/tmp/ncbi-vdb/debian/tmp/usr/ncbi-vdb/linux/gcc/x86_64/dbg/ilib -lhdf5_serial 
-lz -Wl,-Bstatic -Wl,-whole-archive -lklib -lkfs -Wl,-no-whole-archive 
-Wl,-Bdynamic -lbz2 -ldl -lpthread -lm -lkfs -lkq -lkproc -lkdb -lkns -lkfg 
-lksproc -lmbedx509 -lmbedtls -lmbedcrypto -lz

So this seems to be sufficient:

CMD="$CMD -lkfs -lkq -lkproc -lkdb -lkns -lkfg -lksproc -lmbedx509 
-lmbedtls -lmbedcrypto -lz"

Though there is another similar error when trying to link libdiagnose.so
later.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature


Bug#907266: Bug#907358: ncbi-vdb: fix broken library on i386

2018-08-28 Thread Andreas Tille
Control: tags -1 help

Hi Steve,

On Sun, Aug 26, 2018 at 03:04:40PM -0700, Steve Langasek wrote:
> Package: ncbi-vdb
> Version: 2.9.1-1+dfsg-1
> Severity: grave
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu cosmic ubuntu-patch
> 
> Dear Andreas,
> 
> The libncbi-vdb2 library is broken on i386, because while it has managed to
> build, it has unresolvable references:
> ...
> It would also be perfectly reasonable to drop i386 as a supported
> architecture for ncbi-vdb if you prefer; but I suggest you then make sure to
> actually do this, rather than shipping a broken library package on i386.

Thanks to your patch I decided to leave i386 for the moment but its
definitely a candidate for removal.

> Also, this broken library package would have been detectable at build time
> if you were building with -Wl,-z,defs in LDFLAGS, as that would have
> prevented ever generating a shared library with missing symbols.  That's a
> good idea to do anyway, but in particular it would mean that if you didn't
> want to support i386 anymore, you could just add this to build flags and not
> have to worry about changing the architecture list explicitly.

So I did but was running into new problems which are caused by the hand
craftet build system (yes, I tried to convince upstream to use some of
the usual candidates but failed :-((( ).  I was able to add some missing
libs in pbuilder chroot but whatever trick I try[1] the build system
always constructs a different command line than I tested inside the
pbuilder chroot.

Do you have any idea to stop this insane messing up with library options?


[1] 
https://salsa.debian.org/med-team/ncbi-vdb/blob/master/debian/patches/fix_linking.patch

-- 
http://fam-tille.de



Bug#907358: ncbi-vdb: fix broken library on i386

2018-08-28 Thread Adrian Bunk
On Sun, Aug 26, 2018 at 03:04:40PM -0700, Steve Langasek wrote:
>...
> It would also be perfectly reasonable to drop i386 as a supported
> architecture for ncbi-vdb if you prefer; but I suggest you then make sure to
> actually do this, rather than shipping a broken library package on i386.
>...

Additionally, there is a baseline violation on i386:
https://sources.debian.org/src/ncbi-vdb/2.9.1-1+dfsg-1/debian/patches/add_-msse2.patch/

The userbase of this package on i386 is likely zero, so setting 
  Architecture: amd64
would IMHO be the best way forward.

> Cheers,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



Bug#907358: ncbi-vdb: fix broken library on i386

2018-08-26 Thread Steve Langasek
Package: ncbi-vdb
Version: 2.9.1-1+dfsg-1
Severity: grave
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Andreas,

The libncbi-vdb2 library is broken on i386, because while it has managed to
build, it has unresolvable references:

$ ldd -d -r /usr/lib/i386-linux-gnu/libncbi-vdb.so.2
linux-gate.so.1 (0xf7f0d000)
libmbedx509.so.0 => /usr/lib/i386-linux-gnu/libmbedx509.so.0 
(0xf7a33000)
libmbedtls.so.10 => /usr/lib/i386-linux-gnu/libmbedtls.so.10 
(0xf7a03000)
libmbedcrypto.so.1 => /usr/lib/i386-linux-gnu/libmbedcrypto.so.1 
(0xf7999000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf797a000)
libbz2.so.1.0 => /lib/i386-linux-gnu/libbz2.so.1.0 (0xf7968000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7963000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7944000)
libxml2.so.2 => /usr/lib/i386-linux-gnu/libxml2.so.2 (0xf7757000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7655000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7479000)
/lib/ld-linux.so.2 (0xf7f0f000)
libicuuc.so.60 => /usr/lib/i386-linux-gnu/libicuuc.so.60 (0xf72b8000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xf728c000)
libicudata.so.60 => /usr/lib/i386-linux-gnu/libicudata.so.60 
(0xf58e2000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf575b000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf573d000)
undefined symbol: uint64_msbit  (/usr/lib/i386-linux-gnu/libncbi-vdb.so.2)
$

This is because there is no implementation of uint64_msbit for the gcc/i386
target.

However, there doesn't appear to be anything about the gcc/x86_64
implementation which is 64-bit-specific, so attached is a patch that fixes
this bug by simply copying the x86_64 implementation to the i386 file.

This problem was discovered because it caused a build failure for sra-sdk on
i386 in Ubuntu when trying to link against the library at build time.  The
same build failure appears to exist in Debian.

It would also be perfectly reasonable to drop i386 as a supported
architecture for ncbi-vdb if you prefer; but I suggest you then make sure to
actually do this, rather than shipping a broken library package on i386.

Also, this broken library package would have been detectable at build time
if you were building with -Wl,-z,defs in LDFLAGS, as that would have
prevented ever generating a shared library with missing symbols.  That's a
good idea to do anyway, but in particular it would mean that if you didn't
want to support i386 anymore, you could just add this to build flags and not
have to worry about changing the architecture list explicitly.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ncbi-vdb-2.9.1-1+dfsg/debian/patches/i386-uint64_msbit.patch 
ncbi-vdb-2.9.1-1+dfsg/debian/patches/i386-uint64_msbit.patch
--- ncbi-vdb-2.9.1-1+dfsg/debian/patches/i386-uint64_msbit.patch
1969-12-31 16:00:00.0 -0800
+++ ncbi-vdb-2.9.1-1+dfsg/debian/patches/i386-uint64_msbit.patch
2018-08-26 14:57:18.0 -0700
@@ -0,0 +1,25 @@
+Description: add missing implementation of uint64_msbit for i386
+ Without this definition, we get a "successful" library build with undefined
+ symbols on i386.  We can use the same implementation of this function as on
+ x86_64.
+Author: Steve Langasek 
+Last-Modified: 2018-08-26
+
+Index: ncbi-vdb-2.9.1-1+dfsg/interfaces/cc/gcc/i386/arch-impl.h
+===
+--- ncbi-vdb-2.9.1-1+dfsg.orig/interfaces/cc/gcc/i386/arch-impl.h
 ncbi-vdb-2.9.1-1+dfsg/interfaces/cc/gcc/i386/arch-impl.h
+@@ -127,6 +127,13 @@ int32_t uint32_msbit ( uint32_t self )
+ return rtn;
+ }
+ 
++static __inline__
++int32_t uint64_msbit ( uint64_t self )
++{
++if (self==0) return -1;
++return 63 - __builtin_clzll ( self );
++}
++
+ typedef struct int128_t int128_t;
+ struct int128_t
+ {
diff -Nru ncbi-vdb-2.9.1-1+dfsg/debian/patches/series 
ncbi-vdb-2.9.1-1+dfsg/debian/patches/series
--- ncbi-vdb-2.9.1-1+dfsg/debian/patches/series 2018-06-27 20:41:16.0 
-0700
+++ ncbi-vdb-2.9.1-1+dfsg/debian/patches/series 2018-08-26 14:58:11.0 
-0700
@@ -9,3 +9,4 @@
 add_-msse2.patch
 use_debian_packaged_libmbedx.patch
 mbedtls_ssl_init.patch
+i386-uint64_msbit.patch