Re: pseudo-random things compiling gtk+-2.2.1 under HP-UX 11.11

[Owen Taylor <otaylor redhat com>]

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