Re: New release of GTK+ libraries (1.3.15). Please test!

[Owen Taylor <otaylor redhat com>]

Arnaud Charlet <charlet ACT-Europe FR> writes:

> > When I came across this a few weeks ago, the problem was caused by the recent 
> > changes in glib/gobject/gvaluetransform.c. The __floatdisf and __floatdidf are 
> > caused by the conversion of int64 to float and double. gcc did not provide a 
> > shared library with these symbols; they are, I believe, in some static library.
> 
> Right, in libgcc.a, that's where they've always been.
> And if you create your shared lib with gcc -shared, gcc will rigthly put
> -lgcc -lc, which apparently automake/libtool don't.
>
> For now, I've added libgcc explciitely to the ld flags for atk, but this is
> annoying, and I suspect other people will run into this problem, so it would
> be nice to fix it in atk.

Well, it doesn't sound like anything Atk specific; but it also doesn't
sound particularly like something GObject specific. 

It looks like libtool doesn't use $(CC) -shared on Solaris, but rather
uses '$LD -G'. Making libtool use gcc -shared on gcc/Solaris
might be possible, but presumably it is not done currently for
a reason.

I'm not sure what to do here; libgcc has always been really sticky
issue, and there have been recent changes in GCC, so a workaround
for old compilers may be well break recent compilers.

Do we know why we are getting undefined symbol references when linking
a shared library? I wouldn't really expect creating an ELF shared
library to require all symbols to be defined... after all, it was
only with libtool-1.4 we even started putting dependency libraries
on the link line.

Regards,
                                        Owen