Created attachment 352344 [details] [review]
configure.ac: explicitly set link_all_deplibs=yes

Some distros such as Ubuntu and Debian set it to 'no',
while others might keep it to 'unknown' (which defaults to 'yes').
And this causes troubles when linking with libm (undefined reference
to 'sincosf').

FYI log of failure was

make[2]: Entering directory '/media/M2/GNOME/_BUILD/clutter-gtk/clutter-gtk'
  CC       gtk-clutter-util.lo
  CCLD     libclutter-gtk-1.0.la
  GISCAN   GtkClutter-1.0.gir
/opt/dev/GNOME/lib/libcogl-path.so: error: undefined reference to 'sincosf'
collect2: error: ld returned 1 exit status
linking of temporary binary failed: Command '['/bin/bash', '../libtool', '--mode=link', '--tag=CC', '--silent', 'gcc', '-o', '/media/M2/GNOME/_BUILD/clutter-gtk/clutter-gtk/tmp-introspectedfeqx84/GtkClutter-1.0', '-export-dynamic', '-g', '-O2', '/media/M2/GNOME/_BUILD/clutter-gtk/clutter-gtk/tmp-introspectedfeqx84/GtkClutter-1.0.o', '-L.', 'libclutter-gtk-1.0.la', '-L/opt/dev/GNOME/lib', '-Wl,--export-dynamic', '-lgmodule-2.0', '-pthread', '-lgtk-3', '-lclutter-1.0', '-lcogl-path', '-latk-1.0', '-lcogl-pango', '-lcogl', '-lgmodule-2.0', '-pthread', '-lwayland-egl', '-lgbm', '-ldrm', '-lEGL', '-lXrandr', '-ljson-glib-1.0', '-lgio-2.0', '-lgdk-3', '-lpangocairo-1.0', '-lpango-1.0', '-lgdk_pixbuf-2.0', '-lcairo-gobject', '-lcairo', '-lgobject-2.0', '-lglib-2.0', '-lwayland-cursor', '-lwayland-client', '-lxkbcommon', '-lwayland-server', '-lX11', '-lXext', '-lXdamage', '-lXfixes', '-lXcomposite', '-lXi', '-L/opt/dev/GNOME/lib']' returned non-zero exit status 1
/opt/dev/GNOME/share/gobject-introspection-1.0/Makefile.introspection:159: recipe for target 'GtkClutter-1.0.gir' failed
make[2]: *** [GtkClutter-1.0.gir] Error 1

No, this is wrong.

First of all, Clutter-GTK does not use sincosf directly; second, no dependency of Clutter-GTK uses sincosf, that grep can see. Additionally, if you want to link against libm you should use LT_LIB_M and add $(LIBM) to the linker dependencies.

It seems to me your build environment is broken, and that toggling random libtool flags isn't such a good idea.

Review of attachment 352344 [details] [review]:

No. Debian/Ubuntu will have to fix this on their own.

(In reply to Emmanuele Bassi (:ebassi) from comment #3)
> No, this is wrong.
> 
> First of all, Clutter-GTK does not use sincosf directly; second, no
> dependency of Clutter-GTK uses sincosf, that grep can see.

Sure, not directly... Cogl uses it tho, however the problem is that although the clutter-gtk Makefile includes -lm in libclutter-gtk-1.0.la [1] (as per both cogl's .la and for the added $(LIBM) in Makefile.am, as per Bug 658146), libtool doesn't pick it.

> It seems to me your build environment is broken, and that toggling random
> libtool flags isn't such a good idea.

This is not "random", libm isn't just picked by libtool when link_all_deplibs isn't set to 'yes' because as you says, there's not a direct dependency on it.

While setting it to 'yes' (or 'unknown' as is mostly is other distros) just makes libtool to use libm anyway.

> Additionally, if you want to link against libm you should use
> LT_LIB_M and add $(LIBM) to the linker dependencies.

This is already the case as said, but this is not picked when generating the .gir file

At the same time, [2] fixes the problem, but this triggers some warnings [3] which are quite weird.

Adding just 'm' to GtkClutter_@CLUTTER_GTK_API_VERSION_AM@_gir_LIBS also works, but it's not a solution I like either...

[1] https://pastebin.ubuntu.com/24624960/ 
[2] https://pastebin.ubuntu.com/24625210/
[3] https://pastebin.ubuntu.com/24625215/

(In reply to Marco Trevisan (Treviño) from comment #5)
> (In reply to Emmanuele Bassi (:ebassi) from comment #3)
> > No, this is wrong.
> > 
> > First of all, Clutter-GTK does not use sincosf directly; second, no
> > dependency of Clutter-GTK uses sincosf, that grep can see.
> 
> Sure, not directly... Cogl uses it tho

No, it doesn't.

Running `git grep sincosf` on Cogl doesn't yield any result.

> however the problem is that although
> the clutter-gtk Makefile includes -lm in libclutter-gtk-1.0.la [1] (as per
> both cogl's .la and for the added $(LIBM) in Makefile.am, as per Bug
> 658146), libtool doesn't pick it.

Then libtool is entirely broken, or, at least, the libtool modifications that Ubuntu is employing.

> > It seems to me your build environment is broken, and that toggling random
> > libtool flags isn't such a good idea.
> 
> This is not "random", libm isn't just picked by libtool when
> link_all_deplibs isn't set to 'yes' because as you says, there's not a
> direct dependency on it.

Transitively, libm is a dependency through Cogl; this does not mean *everything* must *explicitly* link against libm just because it links against Cogl. If transitive dependencies aren't picked up by the linker, then we should just pack it in and go home because *everything* will break.

> > Additionally, if you want to link against libm you should use
> > LT_LIB_M and add $(LIBM) to the linker dependencies.
> 
> This is already the case as said, but this is not picked when generating the
> .gir file

Then this looks like a problem in the introspection generation, not in the general libtool linking, which is something I can believe more far more easily. Ideally, this should be fixed in the introspection scanner — and, as far as I know, there have already been fixes in that area in order to support non-libtool build systems.

Personally, I'd rather spend time porting Clutter-GTK away from Autotools than messing around with libtool any longer.

Mh, it seems jhbuild doesn't pick the proper location for my libm, once I define something more in LD_LIBRARY_PATH things are working properly.

So indeed it's not a bug here.