Hello all,

I come to you because I'm puzzled with a bug I have in one of my package, and I'm seeking for help. Please CC me when answering as I'm not on this list.

The package is ns3, a scientific simulator of computer networks. This package is
huge, I seem to be the only active maintainer, but upstream is very collaborative.

Upstream just moved from a build system called waf to cmake, which is an nice move. They introduced a small python script saving the waf interface to their users that don't like changes, and unfortunately the raw cmake interface is not usable yet (cmake checks on files created by the script), so I cannot use the plain classical cmake build in debian/rules. I did my best to mimick the behavior of `dh --buildsystem=cmake` but I have a strange failure on non-amd64 platforms:
https://buildd.debian.org/status/package.php?p=ns3

The build, tests and install targets go well, until dh_shlibdeps. At that step, I get a huge bunch of errors like the following:
```
dh_shlibdeps -a
dpkg-shlibdeps -Tdebian/libns3.36.substvars debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wimax.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wifi.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wave.so.36.1 debian/libns3.36/usr/
lib/x86_64-linux-gnu/libns3-visualizer.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-virtual-net-device.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-uan.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-traffic-control.so.36.
1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-topology-read.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-tap-bridge.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-stats.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-
spectrum.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-sixlowpan.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-propagation.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-point-to-point.so.36.1 debian/libns3.36/usr/lib/x86_
64-linux-gnu/libns3-point-to-point-layout.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-olsr.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-nix-vector-routing.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-network.so.36.1
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-netanim.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-mobility.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-mesh.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-lte.so.36.1
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-lr-wpan.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet-apps.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-
flow-monitor.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-fd-net-device.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-energy.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-dsr.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-
gnu/libns3-dsdv.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-csma.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-csma-layout.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-core.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-
gnu/libns3-config-store.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-buildings.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-bridge.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-applications.so.36.1 debian/libns3.36/usr/
lib/x86_64-linux-gnu/libns3-aodv.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-antenna.so.36.1
dpkg-shlibdeps: error: cannot find library libns3-bridge.so.36.1 needed by debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 (ELF format: 'elf64-littleaarch64' abi: '020100b700000000'; RPATH: '')
dpkg-shlibdeps: error: cannot find library libns3-traffic-control.so.36.1 needed by debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 (ELF format: 'elf64-littleaarch64' abi: '020100b700000000'; RPATH: '')
```
This specific one is for arm64, but I get exactly the same problem for all platforms but amd64. https://buildd.debian.org/status/fetch.php?pkg=ns3&arch=arm64&ver=3.36.1%2Bdfsg-2&stamp=1656893780&raw=0

All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the package. They are added to the debian/libns3.36/DEBIAN/shlibs a few lines above in the build log, and dh_strip found them further above in the log. What really puzzles me is that the package builds fine on amd64 and i386.

The package is uptodate on salsa, in case someone wants to test something directly on the package. Fear not to do so, this package only takes one hour to build on my machine :)

If you wonder, the cmake macro to define and build a library is in 
ns-3.36.1/build-support/custom-modules/ns3-module-macros.cmake
I already had to patch it to support Debian: https://salsa.debian.org/debian/ns3/-/blob/master/debian/patches/library-soversion.diff
This patch is ugly for now, but I'm already discussing with upstream so that they integrate the spirit of this patch to their code. They are receptive.


So this is it. I'm stranded here, so any kind of help, pointer, advice or patch is more than welcome, please.


Thanks in advance,
Mt

PS: don't forget to CC me, please.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEET76cTupS7xPVQWYSmL2XJE9zvqcFAmLClvIACgkQmL2XJE9z vqftyg/9HyTmiOjP+tC6NCFy9Tm/lBfHDro2aRARKOOqKOVZ8Wq1FFyf6gE1piDr loT9TiYHvys7zlLUOU1Kp9oQMIe8RiHiYugb2b1Rfcuz566D2WRibRytS/+DlLTN kX4ipSx4rYo7AOQZQtfxC0WGdVv+2e+4wlDjzAzB/doI5ZMT/bnqBX5ZWI+ERl9V pmS0VK1LKKMLzn/zwPesdY02S9qClExHaDMbCEk4GQgJY0fKF6Qhcc7ZkcdyQMsf il4BikPUMbAlS76wJh/wIMenMPweCJ4Nkks2itHSvMX+2j12Lfk6K2nz2KoQ3Smj 7Hj3Ky1YhCA0NNr4dCY88/111JQabuiHnJW0pIzC+XumBpEG1hgFp5StwYucxOIN D6+aQLlnTU3I0BlQ2Kk4HDf0NLgMk3nG/sxr6JSOMmZWqeLTJnubLZO+wDiQYeZn DZiyb+TSnuElTnsPcFuZhgKTwiTSSSRpjfHqbt0rfr3B5gewYML1aPLCLAmA6ySI UZbgJsjCFgCzSFwhzvBngLY7cFLMIVpp4TE5SNQeMLaR/QRIVOURDXEQexcHBhzB 29lIR3pA2wjcZXHQzOPK2cyhBCSAnZGq1joDeiGVhTpYqYlhGb+IpFZhWFlmDLE9 AEoATMfF6Ogt1qwO0f6m6AkTrr67L/fAKbbbuFfCk3LPxQdoTR0=
=Mvtw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

Martin Quinson, le lun. 04 juil. 2022 09:29:54 +0200, a ecrit:

dpkg-shlibdeps -Tdebian/libns3.36.substvars debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wimax.so.36.1

x86_64-linux-gnu is only valid for amd64.

In

./debian/rules: -DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_INSTALL_PREFIX=/usr

you want to use $(DEB_HOST_MULTIARCH) instead of hardcoding x86_64-linux-gnu

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 04 Jul 2022 at 09:29:54 +0200, Martin Quinson wrote:

All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the package. They are added to the debian/libns3.36/DEBIAN/shlibs

Independent of the dh_shlibdeps failure that was already diagnosed, if
these libraries are public (i.e. other packages in Debian are allowed to
link against them) and the SONAMEs of the libraries are of the form libns3-*.so.36.1, then the binary package that contains them should
probably be called something like libns3-36.1, rather than libns3.36.

(Either that, or they should be split up into one binary package per
library, named like libns3-bridge36.1 and so on, by mechanically
transforming their SONAMEs according to the convention documented
in Policy - but I can understand why you would prefer not to do that when
there are a large number of libraries with matching versioning.)

Otherwise, when the SONAMEs jump from libns3-*.so.36.1 to libns3-*.so.36.2
in a future version, any dependent packages that require libns3-*.so.36.1
would be broken by upgrading libns3.36 to a version that no longer contains libns3-*.so.36.1.

If you wonder, the cmake macro to define and build a library is in 
ns-3.36.1/build-support/custom-modules/ns3-module-macros.cmake
I already had to patch it to support Debian: https://salsa.debian.org/debian/ns3/-/blob/master/debian/patches/library-soversion.diff
This patch is ugly for now, but I'm already discussing with upstream so that they integrate the spirit of this patch to their code. They are receptive.

If you're giving advice to upstream, it's important to be aware of
whether the libraries are private (only to be used by other binary
packages within the same source package, like samba-libs or
libsystemd-shared) or public (with a -dev package that can validly be
used by other source packages, like libsmbclient or libsystemd0 or any
typical shared library like GTK or Qt). The correct advice to give to an upstream for private shared libraries is not the same as the correct
advice for public shared libraries.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)