Re: GModule build fixes

[Owen Taylor <otaylor redhat com>]

Dan Winship <danw ximian com> writes:

> > I guess that means that configure.in has to be fixed for NetBSD
> > to export the right G_MODULE_LDFLAGS. I think this is a
> > case of the test catching a real problem.
> 
> I don't think it's reasonable to consider this a NetBSD problem. This is
> an "every platform no one has tried to build glib on yet" problem. The
> *only* reason it works right for Linux is because Linux is already
> special-cased in configure.in. This is not scalable.

Well, GLib-1.2 has the same thing, and there haven't been a lot 
of complaints for portability. It's as scaleable (or not scaleable)
as libtool, really. 

> > We want:
> > 
> >  gcc -o myprog.c myprog.c `pkg-config --cflags --libs glib-2.0 gmodule-2.0`
> > 
> > to work. Using gmodule isn't supposed to require you to use libtool.
> 
> What do you think of the idea of parsing the output of "libtool
> --config" at glib configure time and using that to find
> G_MODULE_LDFLAGS? libtool has a ton of arcane knowledge about what
> platforms require what flags. It seems pointless to try and duplicate
> that in glib.

If you can figure out the necessary magic, sure, that would be
fine. (*)

Regards,
                                        Owen

(*) My start at guessing the magic is:

G_MODULE_LDFLAGS="`( ./libtool --config ; echo eval echo \\$export_dynamic_flag_spec ) | sh`"