There's also this:

*** Warning: Linking the shared library libglib-2.0.la against the non-libtool
*** objects  glib_probes.o is not portable!

(In reply to comment #1)
> There's also this:
> 
> *** Warning: Linking the shared library libglib-2.0.la against the non-libtool
> *** objects  glib_probes.o is not portable!

yeah, I filed a bug against dtrace a while back to get them to use $CC when compiling (https://bugzilla.redhat.com/show_bug.cgi?id=701295) so that we could fix this by doing:

    glib_probes.lo: glib_probes.d
            $(AM_V_GEN) CC="$(LIBTOOL) --mode=compile cc" dtrace -G -s $< -o $@

but I never got around to doing the glib side of it. (I don't think the updated dtrace ever made it into F15 anyway).

(In reply to Allison Lortie (desrt) from comment #0)
> the systemtap scripts that we install in /usr/share have absolute library
> paths inside of them.  this will break multiarch situations where the thing
> in /usr/share should be the same for each arch.

Corollary: We also don't support multiple versions installed in parallel. Our .stp files are /usr/share/systemtap/tapset/[glib|gobject|gio].stp.

(On F23:)

Ruby installs /usr/share/systemtap/tapset/libruby.so.2.2.stp, which fixes the parallel installability. There are also arch-specific subdirectories in /usr/share/systemtap/tapset which should be used for architecture-specific stuff.

Python has /usr/share/systemtap/tapset/libpython3.4-64.stp, which is a hideous combination of the soname and the architecture.

How about using the full installation path and soname of libglib-2.0.so.* beneath /usr/share/systemtap/tapset? Ideally, though, SystemTap would also load .stp files from a subdirectory of $libdir. I guess the problem arises because .stp files serve two purposes: defining user scripts; and naming probe points (markers) from libraries.

I'll try and come up with a patch for GLib later.

For the overall fix, I've filed https://sourceware.org/bugzilla/show_bug.cgi?id=20264.

See also: https://sourceware.org/bugzilla/show_bug.cgi?id=20203

Created attachment 329912 [details] [review]
build: Rename SystemTap scripts to include the LT version

In a vague attempt at ensuring the .stp scripts can be closely
associated with the .so files which they hard-code references to, rename
the scripts so they include the LT version — so that they are the .so
file name plus .stp.

This does not fix the fact that our .stp scripts will not work on
multiarch systems, as they are installed in an architecture-independent
directory (/usr/share/systemtap/tapset). At the moment, it is
recommended that any distribution who package the .stp files should
install them in the architecture-specific subdirectories of this (for
example, /usr/share/systemtap/tapset/x86-64).

A better long-term solution for this is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264

Created attachment 329914 [details] [review]
build: Ensure gio.stp.in is always distributed

Even if systemtap is not enabled in configure when running distcheck.

Review of attachment 329912 [details] [review]:

Looks ok to me. But maybe we should just install our tabsets in /usr/share/systemtap/tapset/x86_64/ ?

Review of attachment 329914 [details] [review]:

ok

Renaming the stap files to use the soname is slightly orthogonal to multiarch; I’ll come up with a follow-up patch for multiarch.

Attachment 329912 [details] pushed as c4695f1 - build: Rename SystemTap scripts to include the LT version
Attachment 329914 [details] pushed as c9d661b - build: Ensure gio.stp.in is always distributed

Created attachment 330589 [details] [review]
build: Include $host_cpu in tapset directory

SystemTap tapsets are architecture-specific, as they include the full
path to the .so file for each probe they reference. Hence, we should
install them in an architecture-specific path, or multiarch systems will
suffer from collisions between them.

A better long-term solution, using $libdir rather than the
non-architecture-specific $datadir, is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264; but this will do
for now.

Ping?

Review of attachment 330589 [details] [review]:

We're going to need the equivalent for Meson, at this point… But it shouldn't block landing the Autotools fix.

Comment on attachment 330589 [details] [review]
build: Include $host_cpu in tapset directory

I’ll attach a follow-up patch for meson.build shortly.

Attachment 330589 [details] pushed as 030efac - build: Include $host_cpu in tapset directory

Created attachment 364565 [details] [review]
build: Include host_machine.cpu_family() in tapset directory (Meson)

This is a corresponding change to meson.build to match commit
030efac0777cdc3330d3afa12dafa95f6449e14b

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Review of attachment 364565 [details] [review]:

Looks good

Fixed. Thanks for the reviews!

Attachment 364565 [details] pushed as 0a2b238 - build: Include host_machine.cpu_family() in tapset directory (Meson)