Can you provide the exact link error? There should be no
use of glib in that program...

Please reopen from NEEDINFO when you add information.

Here are the errors:

<snip>
/bin/bash ../../libtool --mode=link cc  -g   -o ottest  ottest.o
disasm.o libpango-ot.la -L/usr/local/lib -lfontconfig  
-L/usr/local/lib -lfreetype -lz 
cc -g -o ottest ottest.o disasm.o  ./.libs/libpango-ot.a
-L/usr/local/lib /usr/local/lib/libfontconfig.so
/usr/local/lib/libexpat.so -L/usr/lib -L/usr/openwin/lib
-L/usr/local/ssl/lib /usr/local/lib/libfreetype.so -lz
-R/usr/local/lib -R/usr/local/lib
ild: (undefined symbol) g_string_insert_c -- referenced in the text
segment of ./.libs/libpango-ot.a(ftxgdef.o)
ild: (undefined symbol) g_string_insert_c -- referenced in the text
segment of ./.libs/libpango-ot.a(ftxopen.o)
ild: (undefined symbol) g_string_insert_c -- referenced in the text
segment of ./.libs/libpango-ot.a(otlbuffer.o)
ild: (undefined symbol) g_string_insert_c -- referenced in the text
segment of ./.libs/libpango-ot.a(ftxgsub.o)
ild: (undefined symbol) g_string_insert_c -- referenced in the text
segment of ./.libs/libpango-ot.a(ftxgpos.o)
ild: (undefined symbol) g_string_insert_c -- referenced in the text
segment of disasm.o
ild: (undefined symbol) g_string_insert_c -- referenced in the text
segment of ottest.o
</snip>

This doens't make any sense to me at all; 

can you use 'truss' to figure out what files the
command:

cc -g -o ottest ottest.o disasm.o  ./.libs/libpango-ot.a
-L/usr/local/lib /usr/local/lib/libfontconfig.so
/usr/local/lib/libexpat.so -L/usr/lib -L/usr/openwin/lib
-L/usr/local/ssl/lib /usr/local/lib/libfreetype.so -lz
-R/usr/local/lib -R/usr/local/lib

is opening? And then maybe poke around with nm and see
which of these files references g_string_insert_c

Here's what I've figured out so far:
1. in ../opentype, disasm.c and otlbuffer.h include <glib.h>
2. <glib.h> has g_string_append_c_inline inside and G_CAN_INLINE ifdef
3. g_string_append_c_inline contains a call to g_string_insert_c

Would things clear up if G_CAN_INLINE was undef'ed?

In any event, there appears to be numerous calls to glib in libpango
so it seems that anything that links to libpango would need to link to
glib. 

Am I wrong here? It happened once before, if I recall ... ;>

This is a glib configuration problem on your system then. You
seem to be generating a static copy of 
g_string_append_c_inline in every file where glib.h is included,
which is clearly highly undesirable.

You need to sort through the #ifdefs in gutil.h and figure out
why G_CAN_INLINE is being defined although you are getting copies
of functions declared inline in header files.

I can reproduce the exact same problem with glib-2.6.0 and pango-1.8.0.


I've tried the following:
$ cat > foo.c
#include <glib/gutils.h>
G_IMPLEMENT_INLINES
G_CAN_INLINE
G_INLINE_FUNC
$ 
$ c -E `pkg-config glib-2.0 --cflags-only-I` foo.c
[...]
# 2 "foo.c"
G_IMPLEMENT_INLINES
 1
 static inline
#ident "acomp: Forte Developer 7 C 5.4 Patch 111708-05 2003/04/06"
$ 


So gutils.h thinks the proper way of inlining is using "static inline" which
indeed appears to result in a static copy of g_string_append_c_inline being
generated. From gstring.h:
/* -- optimize g_strig_append_c --- */
#ifdef G_CAN_INLINE
static inline GString*
g_string_append_c_inline (GString *gstring,
[...]
  else
    g_string_insert_c (gstring, -1, c);
  return gstring;
}
#define g_string_append_c(gstr,c)       g_string_append_c_inline (gstr, c)
#endif /* G_CAN_INLINE */


Here is an example program:
$ cat > foo.c
#include <glib/gstring.h>
void foo(void) {
    GString bar;
    g_string_append_c(&bar, 'a');
}
$ 
$ cc -c `pkg-config glib-2.0 --cflags` foo.c
$ nm foo.o
[...]
[12]    |       672|     132|FUNC |LOCL |0    |2      |g_string_append_c_inline
[14]    |         0|       0|NOTY |GLOB |0    |UNDEF  |g_string_insert_c
[...]
$ 


Where should I look next?

We just fixed this (missed marking this as a duplicate because of the
NEEDINFO)

*** This bug has been marked as a duplicate of 157536 ***