GNOME Bugzilla – Bug 322885
pango build fails when make is working in examples/
Last modified: 2006-01-16 09:42:21 UTC
Please describe the problem: I had many problems when trying to share my computer with files from my distribution and building things separately in /usr/local/ Steps to reproduce: 1. while libglib2.0 lives in /usr cd into current pango/examples and run make 2. make is unable to complete the examples there I have shown here that I ran make clean first and then i pasted the spew that shows the problem. Actual results: carol@treva:/build/gnome/pango/examples$ make clean test -z "pango.modules" || rm -f pango.modules rm -rf .libs _libs rm -f pangoft2topgm pangoft2topgm rm -f pango-xftview pango-xftview rm -f pango-cairoview pango-cairoview rm -f cairosimple cairosimple rm -f *.o core *.core rm -f *.lo carol@treva:/build/gnome/pango/examples$ make <--snipped--> /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o pangoft2topgm pangoft2top gm.o renderdemo.o argcontext.o ../pango/libpango-1.0.la ../pango/libpangoft2-1.0 .la -lfontconfig -lfreetype -lz gcc -g -O2 -Wall -o .libs/pangoft2topgm pangoft2topgm.o renderdemo.o argcontext.o ../pango/.libs/libpango-1.0.so ../pango/.libs/libpangoft2-1.0.so -lfontconfig /usr/lib/libfreetype.so -lz ../pango/.libs/libpango-1.0.so: undefined reference to `g_intern_static_string' collect2: ld returned 1 exit status make[2]: *** [pangoft2topgm] Error 1 Expected results: I would expect make to only look in /usr/local Does this happen every time? everytime, for months and months now Other information:
Created attachment 55451 [details] [review] include GLIB_LIBS in LDADDs This should fix it. I guess libtool doesn't figure out the library dependencies on its own.
2005-11-30 Behdad Esfahbod <behdad@gnome.org> * examples/Makefile.am: Add GLIB_LIBS to examples explicitly. (#322885, Manish Singh)
Created attachment 55457 [details] [review] more LDADD fixes I reopened the bug report since the same fix needed to be applied to a few more Makefile.am. tests/ pango/ and tools/
I thought that I had reopened this bug when I attached the patch, obviously I was wrong about that. I have reopened the bug report as I meant to do.
I believe this is due to a Debian-specific change in their libtool: They set link_all_deplibs=no. This reduces the library dependencies, which is good for building a distribution. However, it also requires the user to explicitly specify all libraries from which symbols are used in the library/program that is created. To verify that my suspicion is correct, you could edit the libtool file and change all lines link_all_deplibs=no to link_all_deplibs=yes (these lines are once at the very top of libtool, and a few times at the very end, one for each language). Then, redo all linking (without the patches applied). This should succeed now. We are still discussing how a good solution of this issue may be found, sorry for the inconvenience. But in one way or other, a solution _may_ require that package authors specify the libraries from which symbols are explicitly used, so they can be directly linked against. I say 'may' since there is no final solution yet. Cheers, Ralf
Ah, then please make sure libtool --config generates correct output for deplibs_check_method. Pango uses that to decide what to put in its pkg-config files.
Erm, I don't quite understand your comment, Behedad. Who is it addressed to? If me: what output do you expect? Pointing me to the pango source would probably be helpful (I know very little about pango sources or gnome, I work a bit on libtool).
Argh, excuse me for misspelling your name. :(
Ralf, Yes, my comment was addressed to you. I think bug 318750 is also cause by the same kind of libtool tweaking done in debian. Would be good if you check out that bug and see if it's all working. As for the Pango source, check out the pango/configure.in, search for deplibs. I just want to make sure that with the custom libtool configuration that you do in debian, those lines still generate sane configuration for pango. Maybe you can extend the configure.in checks to fix this bug too?
Behdad, A couple of comments: I don't know for certain why you act upon different deplibs_check_method. You may want to act on link_all_deplibs instead, but again, I don't think this is a good interface. Please note that I am not a Debian developer. I work on upstream GNU libtool and am trying to sort out the differences between that and Debian, in the long run. Especially, at the moment I can't test your hypotheses, sorry. I will write to the Debian libtool maintainer about this, though. Cheers, Ralf
Hi, I'm the Debian maintainer of the libtool package. I believe this is caused by the Debian patch to libtool to reduce the dependencies. There still need to be some problems fixed with it. When I'm trying this, I'm seeing something simular to: http://bugzilla.gnome.org/show_bug.cgi?id=318750 The difference is that I get a warning from the linker that it can't find libpangoft2-1.0.so.0: /usr/bin/ld: warning: libpangoft2-1.0.so.0, needed by ../pango/.libs/libpangocairo-1.0.so, not found (try using -rpath or -rpath-link) ../pango/.libs/libpangocairo-1.0.so: undefined reference to pango_fc_font_map_cache_clear' I also get the same error as in the above mentioned bug (so without the warning, just the error about undefined reference) when I have an older pango installed (2.8.2, in /usr/lib) and then try to build the new version (1.10.1). At that point it's picking up the wrong libpangoft2-1.0.so.0, it's using the one from /usr/lib instead of the one from the source dir. I assume something simular is going on here with installed versions of glib-2.0 in the default search path (/usr/lib, /usr/local/lib) and somewhere in the source tree. Or maybe there is a version in both /usr/lib and /usr/local/lib? For more infomration about this see: http://bugs.debian.org/322885 Kurt
I have a feeling that this is debian's libtool fault, not Pango's. Closing...