Menu
▾
▴
xmlroff-list
|
From: Dave M. <da...@da...> - 2003-07-22 18:31:28
|
I'm attempting to built xmlroff from CVS, but am having problems. I checked out the source, and ran "./autogen.sh", followed by "./configure --help" then "./configure" to check things were sane. Upon typing "make" it builds until the final stages, where I get the following error: Making all in . make[2]: Entering directory `/home/david/coding/sourceforge-anonymous-xmlroff/xmlroff' /bin/sh ./libtool --mode=link gcc -g -O2 -I/usr/local/include/pangopdf/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libgnomeprint-2.2 -I/usr/include/libart-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/local/include -I/usr/include/libgnomeprint-2.2 -I/usr/include/libart-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -Wall -o libfo-0.2.la -rpath /usr/local/lib -version-info :: fo-object.lo fo-node.lo fo-context.lo fo-context-util.lo expression-parser.lo result-to-fo.lo area-to-pdf.lo area/libfo-area.la expr/libfo-expr.la fo/libfo-fo.la datatype/libfo-datatype.la property/libfo-property.la libfo/libfo-libfo.la libtool: link: CURRENT `' is not a nonnegative integer libtool: link: `::' is not valid version information It looks to me like the macro in configure.in to setup the version info hasn't worked properly; it's come out as "::" rather than "0:2:3" (or whatever) Have anyone got any suggestions? Have I forgotten something obvious? Should I have set something when I configured the code? BTW This is on a Red Hat 9 machine. -- David Malcolm www.conglomerate.org |
|
From: Tony G. <Ton...@Su...> - 2003-07-24 07:51:07
|
Dave Malcolm wrote at 22 Jul 2003 19:31:36 +0000: > I'm attempting to built xmlroff from CVS, but am having problems. ... > It looks to me like the macro in configure.in to setup the version info > hasn't worked properly; it's come out as "::" rather than "0:2:3" (or > whatever) > > Have anyone got any suggestions? Have I forgotten something obvious? > Should I have set something when I configured the code? It was my problem, not your problem. I checked in a modified configure.in and Makefile.am on 22nd July after I found that I had the problem after breaking things on 21st July. Please do an update and see if you still have the problem. Also, please provide an opinion on the usability of separating out (and not installing) fo-doc-commands.h. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Dave M. <da...@da...> - 2003-07-25 11:08:35
|
On Thu, 2003-07-24 at 07:53, Tony Graham wrote: > Dave Malcolm wrote at 22 Jul 2003 19:31:36 +0000: > > I'm attempting to built xmlroff from CVS, but am having problems. > ... > > It looks to me like the macro in configure.in to setup the version info > > hasn't worked properly; it's come out as "::" rather than "0:2:3" (or > > whatever) > > > > Have anyone got any suggestions? Have I forgotten something obvious? > > Should I have set something when I configured the code? > > It was my problem, not your problem. > > I checked in a modified configure.in and Makefile.am on 22nd July > after I found that I had the problem after breaking things on 21st > July. > > Please do an update and see if you still have the problem. OK - it fixed that problem. Thanks! I'm now attempting to link Conglomerate against libfo, and am running into random crashes. I'm using a vanilla Red Hat 9 machine. I've built PangoPDF and xmlroff, installing them to /usr/local, with PKG_CONFIG_PATH set to /usr/local/lib/pkgconfig. When I build and run my app (linking against libfo), the Gtk libraries seem to dynamically link against the local PangoPDF version of the Pango symbols, rather than the /usr/lib build of the "real" Pango, and crashes occur (probably there are a few things out of sync here and there). Is this the anticipated behaviour i.e. do I need to rebuild my entire Gtk/Gnome build environment on top of PangoPDF (please no!) or can anyone suggest a simple solution? Is there something simple I've missed? > > Also, please provide an opinion on the usability of separating out > (and not installing) fo-doc-commands.h. I'm thinking of doing some hacking on the gnome print backend (to implement passing a GnomePrintJob and forcing the code to stick to the paper size in that, as discussed in a previous email); I can't really comment until I've got everything building and running within my app. -- David Malcolm www.conglomerate.org |
|
From: Tony G. <Ton...@Su...> - 2003-07-25 15:54:10
|
Dave Malcolm wrote at 25 Jul 2003 12:10:17 +0000: > On Thu, 2003-07-24 at 07:53, Tony Graham wrote: ... > > Please do an update and see if you still have the problem. > > OK - it fixed that problem. Thanks! Great. ... > When I build and run my app (linking against libfo), the Gtk libraries > seem to dynamically link against the local PangoPDF version of the Pango > symbols, rather than the /usr/lib build of the "real" Pango, and crashes > occur (probably there are a few things out of sync here and there). > > Is this the anticipated behaviour i.e. do I need to rebuild my entire > Gtk/Gnome build environment on top of PangoPDF (please no!) or can > anyone suggest a simple solution? Is there something simple I've > missed? No, nothing simple that you've missed. You are now into uncharted territory. Do you get any useful messages when your app crashes? What is the ldd output? Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Dave M. <da...@da...> - 2003-07-26 16:17:55
|
On Fri, 2003-07-25 at 15:56, Tony Graham wrote:
[snip]
> You are now into uncharted territory. Do you get any useful messages
> when your app crashes? What is the ldd output?
To try to isolate the problem, I grabbed gnome-hello from GNOME CVS,
built it normally (it worked), and then hacked the configure script to
link against libfo thus:
Index: configure.ac
===================================================================
RCS file: /cvs/gnome/gnome-hello/configure.ac,v
retrieving revision 1.8
diff -u -r1.8 configure.ac
--- configure.ac 16 Jul 2003 05:42:52 -0000 1.8
+++ configure.ac 26 Jul 2003 15:59:00 -0000
@@ -20,7 +20,7 @@
LIBGNOMEUI_REQUIRED=1.96.0
SCROLLKEEPER_REQUIRED=0.1.4
-PKG_CHECK_MODULES(GNOME_HELLO, libgnome-2.0 >= $LIBGNOME_REQUIRED
libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED)
+PKG_CHECK_MODULES(GNOME_HELLO, libgnome-2.0 >= $LIBGNOME_REQUIRED
libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED libfo-0.2 >= 0.2.4)
AC_SUBST(GNOME_HELLO_CFLAGS)
AC_SUBST(GNOME_HELLO_LIBS)
I then did re-ran autogen.sh, did a make clean, then a make.
The gnome-hello program now crashes on startup, in a similar way to my
Conglomerate tests; here's a fragment of the backtrace:
(gdb) run
Starting program:
/home/david/coding/gnome-anonymous-cvs/gnome-hello/src/gnome-hello
[New Thread 1094308544 (LWP 25565)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1094308544 (LWP 25565)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x40e0392e in pango_layout_run_get_extents (run=0x80b9b10,
shape_setp=0x0, run_ink=0xbfffb3c0, run_logical=0x80b9cbc) at
pango-layout.c:3751
#2 0x40e037c9 in pango_layout_line_get_extents_real (line=0x80bc0c0,
ink_rect=0x0, logical_rect=0xbfffb3c0) at pango-layout.c:3689
#3 0x40e03947 in pango_layout_line_get_extents (line=0x80b9b10,
ink_rect=0x0, logical_rect=0xbfffb3c0) at pango-layout.c:3774
#4 0x40e00fc9 in get_line_extents_layout_coords (layout=0x80b9960,
line=0x80bc0c0, layout_width=-1, y_offset=0, baseline=0xbfffb44c,
line_ink_layout=0x0,
line_logical_layout=0xbfffb450) at pango-layout.c:1867
#5 0x40e010cd in pango_layout_get_extents_internal (layout=0x80b9960,
ink_rect=0x0, logical_rect=0xbfffb4f0, line_extents=0x0) at
pango-layout.c:1935
#6 0x40e01312 in pango_layout_get_extents (layout=0x80b9b10,
ink_rect=0x0, logical_rect=0xbfffb4f0) at pango-layout.c:2031
#7 0x4025793d in gtk_label_get () from /usr/lib/libgtk-x11-2.0.so.0
#8 0x401d7533 in gtk_accel_label_get_accel_width () from
/usr/lib/libgtk-x11-2.0.so.0
Here's the result of running ldd on the executable:
[david@shirehorse1 src]$ ldd gnome-hello
libgnomeui-2.so.0 => /usr/lib/libgnomeui-2.so.0 (0x40028000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x400b3000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x400bc000)
libbonoboui-2.so.0 => /usr/lib/libbonoboui-2.so.0 (0x400d4000)
libgnomecanvas-2.so.0 => /usr/lib/libgnomecanvas-2.so.0
(0x40136000)
libgnome-2.so.0 => /usr/lib/libgnome-2.so.0 (0x40163000)
libpangoft2-1.0.so.0 =>
/usr/local/lib/pangopdf/libpangoft2-1.0.so.0 (0x40177000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x40196000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x403ea000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x40459000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0
(0x40472000)
libpangoxft-1.0.so.0 =>
/usr/local/lib/pangopdf/libpangoxft-1.0.so.0 (0x40485000)
libpangox-1.0.so.0 => /usr/local/lib/pangopdf/libpangox-1.0.so.0
(0x404a3000)
libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0x404af000)
libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x40506000)
libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0x4053d000)
libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4
(0x40576000)
libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x40589000)
liblinc.so.1 => /usr/lib/liblinc.so.1 (0x405cb000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x405d3000)
libfo-0.2.so.0 => /usr/local/lib/libfo-0.2.so.0 (0x405d8000)
libpdf.so.1 => /usr/local/lib/libpdf.so.1 (0x40867000)
libpangopdflib-1.0.so.0 =>
/usr/local/lib/pangopdf/libpangopdflib-1.0.so.0 (0x408f5000)
libpangogp-1.0.so.0 =>
/usr/local/lib/pangopdf/libpangogp-1.0.so.0 (0x4091f000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40941000)
libgnomeprint-2-2.so.0 => /usr/lib/libgnomeprint-2-2.so.0
(0x40966000)
libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0x40da8000)
libxslt.so.1 => /usr/lib/libxslt.so.1 (0x40dbf000)
libpango-1.0.so.0 => /usr/local/lib/pangopdf/libpango-1.0.so.0
(0x40dec000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x40e1d000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x40e52000)
libdl.so.2 => /lib/libdl.so.2 (0x40e56000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40e5a000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x40ec5000)
libz.so.1 => /usr/lib/libz.so.1 (0x40fb0000)
libm.so.6 => /lib/tls/libm.so.6 (0x40fbe000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40fe0000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
libpopt.so.0 => /usr/lib/libpopt.so.0 (0x40fee000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40ff7000)
libesd.so.0 => /usr/lib/libesd.so.0 (0x41015000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x4101d000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x41042000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x41094000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x41098000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x410a0000)
libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x410ae000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x410c0000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x410c8000)
libORBitCosNaming-2.so.0 => /usr/lib/libORBitCosNaming-2.so.0
(0x411a8000)
libssl.so.4 => /lib/libssl.so.4 (0x411ad000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x411e2000)
librt.so.1 => /lib/tls/librt.so.1 (0x412d3000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x412e5000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libresolv.so.2 => /lib/libresolv.so.2 (0x41306000)
libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2
(0x41318000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x4132b000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3
(0x41389000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3
(0x4139a000)
The problems appears to be this line:
libpango-1.0.so.0 => /usr/local/lib/pangopdf/libpango-1.0.so.0
(0x40dec000)
i.e. that clients of libpango (such as GTK) are being dynamically linked
to PangoPDF, rather than the "real" Pango, and die horribly (due to ABI
inconsistencies, I think)
I'm not an expert at managing dynamic libraries on Unix and similar
systems (I come from a Win32 and games console background); I believe
that PangoPDF needs to have some kind of renaming: probably of the
generated so file, and possibility of the symbols inside it (some kind
of automated shell script?)
Hope the above makes sense! Is there a simple fix I've missed? Is it
possible to statically link PangoPDF inside xmlroff without exporting
its symbols to fix the problem? (I don't know enough about "so" files to
implement this myself).
--
David Malcolm
www.conglomerate.org
|
|
From: Tony G. <Ton...@Su...> - 2003-07-29 10:29:30
|
Dave Malcolm wrote at 26 Jul 2003 17:19:37 +0000: > Hope the above makes sense! Is there a simple fix I've missed? Is it > possible to statically link PangoPDF inside xmlroff without exporting > its symbols to fix the problem? (I don't know enough about "so" files to > implement this myself). I was about to suggest statically linking PangoPDF to libfo. Add '--enable-static --disable-shared' to the PangoPDF 'configure' command line. You may also need to add '--with-included-modules=basic-gp'. You may also need to add '--enable-static --disable-shared' to the xmlroff 'configure' command line, but I suggest trying it without first. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Dave M. <da...@da...> - 2003-07-29 13:53:54
|
On Tue, 2003-07-29 at 10:31, Tony Graham wrote: > Dave Malcolm wrote at 26 Jul 2003 17:19:37 +0000: > > Hope the above makes sense! Is there a simple fix I've missed? Is it > > possible to statically link PangoPDF inside xmlroff without exporting > > its symbols to fix the problem? (I don't know enough about "so" files to > > implement this myself). > > I was about to suggest statically linking PangoPDF to libfo. > > Add '--enable-static --disable-shared' to the PangoPDF 'configure' > command line. You may also need to add > '--with-included-modules=basic-gp'. OK - I just tried that. My "patched to link with libfo" version of gnome-hello still dies deep inside GTK+, in the same way as before. I ran ldd on the executable and grepped for pango, and couldn't see any direct pangopdf references. However, running nm of the libfo library shows up lots of undefined "pango" symbols, so somehow I suppose the libfo linkage is pulling in a load of pango symbols from pangopdf which clash with the pango symbols from the "real" pango. > > You may also need to add '--enable-static --disable-shared' to the > xmlroff 'configure' command line, but I suggest trying it without > first. OK - am now doing a full rebuild of xmlroff with those options (having cleaned out my /usr/local/lib). I'll post the results... Dave Malcolm |
|
From: Dave M. <da...@da...> - 2003-07-29 16:37:58
|
On Tue, 2003-07-29 at 14:55, Dave Malcolm wrote: > > > > > You may also need to add '--enable-static --disable-shared' to the > > xmlroff 'configure' command line, but I suggest trying it without > > first. > > OK - am now doing a full rebuild of xmlroff with those options (having > cleaned out my /usr/local/lib). I'll post the results... > Doh! That failed as well... Doing an "nm" on the installed libfo-0.2.a shows a load of undefined pango symbols. Doing an "nm" on the gnome-hello executable reveals that the pangopdf symbols have been built into it (they are present in the "text" and "data" sections, rather than being "unknown"), so it appears that when GTK+ is loaded it finds the Pango symbols inside the main executable, rather than in the correct shared library - and then blows up. I'm now reading through the libtool and binutils info/man pages... Any ideas? I'm beginning to think that the symbols inside pangopdf need a systematic rename - which would be a pain. Has anyone else attempted to link libfo with gnome-hello? Dave Malcolm |
|
From: Tony G. <Ton...@Su...> - 2003-07-29 16:44:57
|
Dave Malcolm wrote at 29 Jul 2003 17:39:48 +0000: > Has anyone else attempted to link libfo with gnome-hello? I won't be able to get to it before Friday. I'll try gnome-hello then. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X