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 71812 - LIBGNOME_LIBS needs INTLLIBS
LIBGNOME_LIBS needs INTLLIBS
Status: RESOLVED OBSOLETE
Product: gnome-libs
Classification: Deprecated
Component: general
1.4.x
Other IRIX
: Normal normal
: ---
Assigned To: gnome-libs Maintainers
gnome-libs Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-02-18 02:14 UTC by Greg Hudson
Modified: 2003-02-09 03:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to include INTLLIBS in LIBGNOME_LIBS (713 bytes, patch)
2002-02-18 02:16 UTC, Greg Hudson
none Details | Review

Description Greg Hudson 2002-02-18 02:14:06 UTC
gnomelib_init() uses bindtextdomain(), so libgnome relies on -lintl on
platforms (like IRIX) which need that.  As things stand, LIBGNOME_LIBS (-->
the output of gnome-config --libs gnome) doesn't contain -lintl on those
platforms, leading to problems like:

whirlpool% cat > test.c
int main() { gnomelib_init("test", "1.0"); }
whirlpool% cc test.c `gnome-config --libs gnome`
whirlpool% ./a.out
3050899:./a.out: rld: Fatal Error: attempted access to unresolvable symbol
in /usr/athena/lib/libgnome.so.33: bindtextdomain

I will attach a fix.
Comment 1 Greg Hudson 2002-02-18 02:16:03 UTC
Created attachment 6758 [details] [review]
Patch to include INTLLIBS in LIBGNOME_LIBS
Comment 2 Kjartan Maraas 2002-03-19 00:51:05 UTC
I'll try to get this into the next release.
Comment 3 Kjartan Maraas 2002-09-14 14:28:51 UTC
Jacob, could you look at this one too, please?
Comment 4 jacob berkman 2002-09-17 21:28:51 UTC
i'm pretty sure this is the wrong fix.

the right thing is to change libgnome_la_LIBS to include INTL_LIBS
Comment 5 Greg Hudson 2002-09-18 15:31:28 UTC
Uh, why is it the wrong fix?  LIBGNOME_LIBS contains all the other
dependencies of libgnome; why not this one?

(Adding INTL_LIBS to libgnome_la_LIBS may also be appropriate, but it
won't work for the case of a non-libtoolized application and static
linking.)
Comment 6 jacob berkman 2002-09-18 15:36:37 UTC
if apps are making libintl calls, they should add -lintl to their link
lines.

i can't remember the static linking semantics here though.
Comment 7 Greg Hudson 2002-09-18 15:47:15 UTC
That argument applies equally well (which is to say, not at all) to
everything else in LIBGNOME_LIBS.  "If apps are making esd calls, they
should use -lesd."  The point is, the apps aren't making esd calls or
libintl calls; libgnome is, and whole reason for LIBGNOME_LIBS is to
act as a backstop for library dependencies.  If you think that
backstop shouldn't exist, then LIBGNOME_LIBS and everything like it
should be blown away, but that would be a very radical change to the
build system model.

(To refresh your memory on static linking semantics: there are no
library dependencies for static linking, unless the application is
using libtool to do its linking.)
Comment 8 Luis Villa 2003-02-09 03:32:13 UTC
Because of the release of GNOME2.0 and 2.2, and the apparent lack of interest in
a further release of GNOME 1.4, many GNOME1.4 bugs are being closed. If you feel
your bug was incorrectly labeled as a GNOME1.4 bug, or also applied to GNOME2,
please reopen it and reassign it to another component more relevant to GNOME2.
Thanks, and hope you enjoy GNOME2.