Duplicate Dependency Error Reported in Build Image

[sk...@chromium.org]

tl;dr; We've somehow compiled against the same library twice.  No, it's not slotted.

We're trying to update gnutls and we've run into a problem during build_image.  We get a failure in test_elf_deps which seems to be checking binaries to see if the libraries they are compiled against are consistent.  Somehow, when we compile net-print/cups-filters it reports that it depends on two different versions of gnutls.  However, it does not depend on gnutls directly.  cups-filters depends on gnults through openldap and cups (but openldap isn't reported in the graph).  It might be notable that net-print cups is a dependency of the SDK but I am unsure if that's relevant.  Please help.

/mnt/host/source/src/scripts/build_library/test_image_content.sh: line 41: echo: write error: Broken pipe ERROR : test_elf_deps: Failed dependency check ERROR : Package: net-print/cups-filters-1.17.8-r1 ERROR : /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libcupsfilters.so.1.0.0 (interpreter => None) ERROR : libcupsimage.so.2 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libcupsimage.so.2 ERROR : libcups.so.2 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libcups.so.2 ERROR : libgnutls.so.30 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libgnutls.so.30 ERROR : libunistring.so.2 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libunistring.so.2 ERROR : libtasn1.so.6 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libtasn1.so.6 ERROR : libnettle.so.6 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libnettle.so.6 ERROR : libhogweed.so.4 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libhogweed.so.4 ERROR : libgmp.so.10 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libgmp.so.10 ERROR : libidn2.so.0 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libidn2.so.0 ERROR : libavahi-common.so.3 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libavahi-common.so.3 ERROR : libavahi-client.so.3 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libavahi-client.so.3 ERROR : libdbus-1.so.3 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/usr/lib64/libdbus-1.so.3 ERROR : libgnutls.so.26 => None ERROR : libpthread.so.0 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/lib64/libpthread.so.0 ERROR : ld-linux-x86-64.so.2 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/lib64/ld-linux-x86-64.so.2 ERROR : libcrypt.so.1 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/lib64/libcrypt.so.1 ERROR : libz.so.1 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/lib64/libz.so.1 ERROR : libm.so.6 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/lib64/libm.so.6 ERROR : libdl.so.2 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/lib64/libdl.so.2 ERROR : libc.so.6 => /mnt/host/source/src/build/images/wolf/R66-10453.0.0-rc2/rootfs/lib64/libc.so.6

[Brian Norris]

I thought I already commented on the CL already?

I guessed that even though cups-filters does not *list* a dependency on gnutls, it does in fact have a dependency. That's a problem.

The problem would manifest if you upgrade gnutls, which causes libcups to get rebuilt but not libcupsfilter. Thus you have an existing prebuilt libcupsfilter that linked to old gnutls (which no longer exists, and is rightly flagged by the ELF tester) as well as the new libcups (which links to the new gnutls).

I think if you fix cups-filters to express its SSL dependencies, this problem should go away.

Disclaimer: this is a semi-educated guess.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Brian Norris]

My comments were here:

https://chromium-review.googlesource.com/c/chromiumos/overlays/portage-stable/+/938640

I think that's what you're asking about.

[Sean Kau]

Thing is, I looked through what cups-filter is linking and I I can't find -lgnutls anywhere. I'm not sure how lddtree works so I don't know if the listed libraries are always direct dependencies.

[Brian Norris]

It's definitely in there. On an existing build (without that CL):

# readelf -a /build/scarlet/usr/lib/libcupsfilters.so | grep tls
 0x00000001 (NEEDED)                     Shared library: [libgnutls.so.26]

[Brian Norris]

And here's why:

$ /build/$BOARD/usr/bin/cups-config --libs
-lcups -lgnutls -lz -lpthread -lm -lcrypt -lz

That's one of the ways cups-filters determines its linker flags.

I wonder if any of those are actually necessary, except for the '-lcups' part... because AFAICT from the source, cups-filters does NOT actually make any openssl/gnutls calls directly from its source. Its only dependency is via libcups.

[Sean Kau]

It has to be for cups-browsed.  I should see if I can separate the targets.

[Mike Frysinger]

`cups-config --libs` most likely should only list -lcups since we're building it as a shared lib

-mike

[Brian Norris]

Are you sure? My build doesn't have cups-browsed linking against gnutls directly.

And anyway, if that was a dependency...that'd be up to the cups-filters ebuild and Makefiles to express its dependencies and linker flags. That doesn't change what `cups-config` should be listing.

[Brian Norris]

Yeah, that's what I was thinking too.

cups-config is kinda weird actually; it has a --static flag, except that `cups-config --static --libs` could give you different output than `cups-config --libs --static`. (And anyway, --static doesn't really do anything for us currently, since as you say, we're building shared.)

[Sean Kau]

I see where cups-config is invoked now, it's being invoked during the configure stage to generate the library flags.  We'll look into whether cups-filters even needs cups-config as I suspect this is an artifact of it being split out from CUPS some years ago.

We'll add gnutls as a direct dependency now (to get Portage to do the right thing) and come back to clean it up.

[Brian Norris]

Calling cups-config is correct, because that's how you discover the correct flag(s) to use to link to libcups (which cups-filters uses). You could probably code this in other ways, but in general, you often call 'pkg-config' or whatever equivalent '<custom-package>-config' is provided by a package if you want to link to its libraries.

The problem is that cups-config is currently listing way too many libraries for you.

Hacking the gnutls dependency in cups-filters should work for now. But we should patch CUPS so it stops over-reporting in cups-config.