gnutls.pc: unnecessary pathname in Libs.private

changed the description

Are you sure, it's not a custom installed libunistring ?

Here (Debian, custom installed libunistring and libidn2) it looks like

Libs.private:       -lgmp /usr/local/lib/libunistring.so -Wl,-rpath -Wl,/usr/local/lib -lidn2

After uninstalling both libs from /usr/local and a ldconfig and ./configure run in gnutls/, the line looks like

Libs.private:       -lgmp -lunistring -lidn2

Which looks correct.

I can verify that this happens in fedora. I see that the detection of libunistring is done by AC_LIB_HAVE_LINKFLAGS. It may be something in fedora that makes it decide to link directly with the .so.

Try it with how libidn2 detects it:

if test "$ac_cv_libunistring" = "yes";then
  AC_SEARCH_LIBS(u8_normalize, unistring, [], [ac_cv_libunistring=no])
fi
AM_CONDITIONAL(HAVE_LIBUNISTRING, test "$ac_cv_libunistring" = "yes")

That needs a unistring_EARLY after gl_EARLY

Just tested on our fedora29 docker image (fresh local build) and I can't reproduce:

# cat lib/gnutls.pc
# Process this file with autoconf to produce a pkg-config metadata file.

# Copyright (C) 2004-2012 Free Software Foundation, Inc.

# Copying and distribution of this file, with or without modification,
# are permitted in any medium without royalty provided the copyright
# notice and this notice are preserved.  This file is offered as-is,
# without any warranty.

# Author: Simon Josefsson

prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: GnuTLS
Description: Transport Security Layer implementation for the GNU system
URL: http://www.gnutls.org/
Version: 3.6.5
Libs: -L${libdir} -lgnutls
Libs.private:      -ltspi -lgmp -lunistring -lidn2
Requires.private: nettle, hogweed, libtasn1, p11-kit-1
Cflags: -I${includedir}

So looks like Fedora meanwhile fixed it.

Also not reproducible with out Fedora28 docker image (gnutls.pc looks the same as above).

I just checked on Fedora 29 too, latest "gnutls-devel" package, and see in /usr/lib64/pkgconfig/gnutls.pc:

Libs.private: -ltspi -lgmp /usr/lib64/libunistring.so -lidn2

So I don't know you guys see something different. Very strange...

OK, then it's a packaging issue at Fedora and it must be fixed there.

What I did is building the latest GnuTLS from git (on Fedora28 / Fedora29) to see if there is a fundamental issue with either GnuTLS's build system or with the development packages provided by Fedora. It isn't.

@nmav Did you open an issue at Fedora ? We could then close this one here.

Tim Rühsen @rockdaboot commented 38 minutes ago

OK, then it's a packaging issue at Fedora and it must be fixed there.

It is not Fedora specific, it also shows up on Debian.

It is not Fedora specific, it also shows up on Debian.

I work on Debian unstable and can't reproduce, but can see that you are right.

Anyways, building GnuTLS (from git) on Debian unstable and make install results in

$ cat /usr/local/lib/pkgconfig/gnutls.pc
...
Libs.private:      -ltspi -lgmp -lunistring -lidn2
...

Isn't that what Debian package building basically does (make install + then collect the data) ?

Tim Rühsen @rockdaboot commented 29 minutes ago

Isn't that what Debian package building basically does (make install + then collect the data) ?

Yes. The significant difference to your build is that Debian is using multiarch, i.e. we set --libdir. e.g. on amd64 the following command sequence will reproduce the issue:

mkdir b4deb ; cd b4deb ; ../configure --without-tpm --disable-guile --disable-rpath --enable-libdane --prefix=/usr --libdir=\${prefix}/lib/x86_64-linux-gnu && make -j5

mentioned in merge request !877 (merged)

Thanks @ametzler ! That makes it reproducible.

I changed the libunistring detection in !877 (merged) to fix it. Please review / test.

closed via merge request !877 (merged)

mentioned in commit 4fea0218

gnutls.pc: unnecessary pathname in Libs.private

Designs

Child items ...

Activity