On Fri, 2003-03-14 at 18:54, Rick Jones wrote: > Hi - > > I find myself wanting to use gtk+ for a project and so I've been working > through installing all the dependencies. > > I've already run into and worked around (thanks to the archive) the > problems with atk/pango and docs not building (make failure on > all-local)
If I remember correctly, this problem is most easily solved by using GNU make. The GTK+ build instructions say: The GTK+ makefiles will mostly work with different versions of make, however, there tends to be a few incompatibilities, so the GTK+ team recommends installing GNU make if you don't already have it on your system and using it. (It may be called gmake rather than make.) > , and now I'm compiling gtk itself. > > I'm using the HP ANSI C compiler: > > $ what `which cc` > /usr/bin/cc: > LINT B.11.11.06 CXREF B.11.11.06 > HP92453-01 B.11.11.06 HP C Compiler > $ Sep 8 2000 23:13:51 $ > > The configure gets through OK (I had to manually move some .h files for > png/tiff into /usr/local/include) and the compile chugs along until: See what: http://developer.gnome.org/doc/API/2.2/gtk/gtk-building.html Says about setting CPPFLAGS and LDFLAGS. > cc -g -o .libs/gdk-pixbuf-csource gdk-pixbuf-csource.o -L/usr/local/lib > -L/opt/ > libpng/lib ./.libs/libgdk_pixbuf-2.0.sl /usr/local/lib/libintl.sl -lc > -Wl,+b -Wl > ,/home/raj/gtk+-2.2.1/gdk-pixbuf/.libs:/usr/local/lib^M > /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file > (gdk-pixbuf-csource.o > ) was detected. The linked output may not run on a PA 1.x system.^M > /usr/ccs/bin/ld: Unsatisfied symbols:^M > g_log_set_always_fatal (code)^M > g_fprintf (code)^M > g_error_free (code)^M > g_free (code)^M > g_object_unref (code)^M > g_type_init (code)^M > g_strdup (code)^M > *** Error exit code 1^M > > should I have seen a glib in that cc line there somewhere? I have glib > installed on the system (libs in /usr/local/lib) and it seems that those > missing symbols are from glib. Did I fubar something in the configure > perhaps Looks like a libtool bug. Libtool is supposed to (if necessary) put the required dependency libraries on the link line:. gdk-pixbuf/Makefile should have variables set similar to: gdk_pixbuf_csource_LDADD = $(LDADDS) LDADDS = libgdk_pixbuf-$(GTK_API_VERSION).la libgdk_pixbuf_2_0_la_LIBADD = pixops/libpixops.la $(builtin_objs) $(gdk_pixbuf_win32res_lo) $(GDK_PIXBUF_DEP_LIBS) GDK_PIXBUF_DEP_LIBS = -Wl,--export-dynamic -lgmodule-2.0 -ldl -lgobject-2.0 -lglib-2.0 -lm If GDK_DEP_LIBS includes -lglib-2.0 yet you get the above link line for gdk-pixbuf-csource, that's a libtool bug. > What follows are the nits I've found thusfar. The seem pretty minor. This really isn't the right forum for this type of report ... you'd be much better off filing a bug in bugzilla. See the GTK+ README. That being said, as long as warnings: - Don't indicate real bugs in GTK+ - Aren't encountered with the compilers that GTK+ contributors use. Fixing them probably won't be a very high priority for us. Regards, Owen > from line 567: > > GType > gdk_pixbuf_non_anim_get_type (void) > { > static GType object_type = 0; > > but above it it is forward decl'd as: > > static GType gdk_pixbuf_non_anim_get_type (void) G_GNUC_CONST; > > and the other is the same: > > > static GType gdk_pixbuf_non_anim_iter_get_type (void) G_GNUC_CONST; > ... > > GType > gdk_pixbuf_non_anim_iter_get_type (void) These would be good to have in bugzilla. > cc: "gdk-pixdata.c", line 200: warning 604: Pointers are not > assignment-compatible.^M > cc: "gdk-pixdata.c", line 200: warning 563: Argument #2 is not the > correct type. > > > which seems to be this code: > > stream = get_uint32 (stream, &pixdata->magic); > stream = get_uint32 (stream, &pixdata->length); > if (pixdata->magic != GDK_PIXBUF_MAGIC_NUMBER || pixdata->length < > GDK_PIXDATA > > get_uint32 wants guint* as parm 2: > static inline const guint8 * > get_uint32 (const guint8 *stream, guint *result) > { > > and pixdata->length is gint: This one also probably should be fixed. (unsigned char * vs. char * warnings almost never indicate real bugs, but it's nice to get int out parameters like this right.) > And the code appears to be: > > void > MODULE_ENTRY (png, fill_info) (GdkPixbufFormat *info) > { > static GdkPixbufModulePattern signature[] = { > 905 { "\x89PNG\r\n\x1a\x0a", NULL, 100 }, > { NULL, NULL, 0 } > }; > > and the GdkPixbufModulePattern > > typedef struct _GdkPixbufModulePattern GdkPixbufModulePattern; > struct _GdkPixbufModulePattern { > unsigned char *prefix; > unsigned char *mask; > int relevance; > }; > > I'm not quite sure what the compiler is complaining about there but > would _guess_ that it is the constant string being assigned to the > unsigned char *prefix? Perhaps the compiler is being overly paranoid > about pointers to literals, which will be in the TEXT area? I think rather it's simply that the char literal is 'char' rather than 'unsigned char'. > \-I/opt/libpng/include -g -c io-jpeg.c +Z -DPIC -o io-jpeg.lo^M > cpp: "/usr/local/include/jconfig.h", line 12: warning 2001: Redefinition > of macro HAVE_STDLIB_H.^M > cpp: "/usr/include/sys/param.h", line 379: warning 2001: Redefinition of > macro MIN.^M > cpp: "/usr/include/sys/param.h", line 380: warning 2001: Redefinition of > macro MAX.^M > cpp: "../config.h", line 144: warning 2001: Redefinition of macro > HAVE_STDLIB_H.^M > cc: "io-jpeg.c", line 453: warning 562: Redeclaration of > "gdk_pixbuf__jpeg_image_begin_load" with a different storage class > specifier: "gdk_pixbuf__jpeg_image_begin_load" will have internal > linkage.^M Again, this should be reported. > cc: "io-jpeg.c", line 924: warning 604: Pointers are not > assignment-compatible.^M > > The "HAVE_STDLIB_H" redefinition is a bit troubling - could it mean that > some of the dependencies arrived at different conclusions as to there > being a stdlib.h on the system? This is a long-standing, known, and basically harmless libjpeg bug. libjpeg includes configure.in test output in its public headers, which is highly wrong, but usually doesn't hurt anything, Regards, Owen _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
