After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 345729 - ORBit-2.0.pc's Libs shouldn't include -lm
ORBit-2.0.pc's Libs shouldn't include -lm
Status: RESOLVED FIXED
Product: ORBit2
Classification: Deprecated
Component: general
2.14.x
Other Linux
: Normal minor
: ---
Assigned To: ORBit maintainers
ORBit maintainers
Depends on:
Blocks: 396255
 
 
Reported: 2006-06-23 09:43 UTC by Sebastian Rittau
Modified: 2007-01-13 22:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Rittau 2006-06-23 09:43:21 UTC
This bug was originally filed as Debian bug #374018 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374018) by Samuel Thibault:

------------------------------------------------------------------

Package: liborbit2-dev
Version: 1:2.14.0-1.1
Severity: minor


Hi,

There are spurious dependencies in ORBit-2.0.pc:

Libs: -L${libdir} -lORBit-2 -lm

-lm is _not_ needed in Libs (since the -lORBit-2 interface
doesn't depend on -lm interface) and just brings a unneeded
dependencies. It should rather be put in Libs.private:

Libs: -L${libdir} -lORBit-2
Libs.private: -lm

(so that static compiling still works).

Samuel

------------------------------------------------------------------

The patch is rather trivial:

--- ORBit-2.0.pc.in.old 2006-06-23 11:42:25.908664500 +0200
+++ ORBit-2.0.pc.in     2006-06-23 11:42:56.146554250 +0200
@@ -9,5 +9,6 @@
 Description: High-performance CORBA Object Request Broker.
 Version: @ORBIT_VERSION@
 Requires: glib-2.0 gmodule-no-export-2.0 gthread-2.0
-Libs: -L${libdir} @MINGW_LDFLAGS@ -lORBit-2 @LIBM@
+Libs: -L${libdir} -lORBit-2
+Libs.private: @MINGW_LDFLAGS@ @LIBM@
 Cflags: -I${includedir}/orbit-2.0 -DORBIT2=1
Comment 1 Daniel Macks 2006-06-23 18:32:13 UTC
The *.private fields are only available in newer versions of pkg-config. Might want to raise xPKG_CONFIG_MIN_VERSION in configure.in?

On second thought, not technically needed, but there really isn't *any* way to signal to users of orbit that the .pc is only fully compatible with at least a certain version of pkg-config. D'oh:(

Actually, looking at that region of configure.in, it might be cleaner to just use PKG_PROG_PKG_CONFIG instead of implementing it locally with AC_PATH_PROG and a manual --atleast-pkgconfig-version.
Comment 2 Kjartan Maraas 2006-11-22 20:35:07 UTC
Fixed.