I noticed that most (if all) the links to GLib/GObject are broken in the online documentation. Example:
They're also broken in the documentation installed on my machine (Debian Stretch), accessible through 'devhelp'.
I took a bit of time to look into this, and it seems that 'gtkdoc-fixxref' needs explicit options to handle links toward external symbols.
gtkdoc-fixxref is the tool that fixes the cross-references in the documentation . By default, it scans for indices in the install directory . Which might defaults to '/usr/local/share' , where there's nothing to be found. So it's a bit of a broken behavior to start with.
Anyway, I'm not an expert in gtk-doc, but I had a look into GTK+ and GStreamer to see how they handle that. They do it the same way, by explicitly telling gtkdoc-fixxref where to look at.
I added equivalent commits for udisks, you can have a look on my branch.
I can't be 100% sure it fixes the issue, I still need to try to build a Debian package and compare the result.
As for the website, I don't know if there's more magic needed to make these links work. I didn't talk about 'gtkdoc-rebase', and I won't tell anything, apart that this guy is involved in the installation process.
 gtkdoc-fixxref --help
 V=1 make
Hmmm, talking about the Debian package, it might as well be a bug in the Debian package it self.
I can see that both gtk and gstreamer have a 'Build-Depends-Indep' field in their control file, indicating 'libglib2.0-doc' as a dependency. The udisks package has no such thing, so it's possible that it's build in an environment where the GLib documentation is not installed, and therefore the cross-reference links are not resolved.
It would be interesting to know whether the udisks documentation installed on Fedora has broken links to GLib symbols.
That's fixed on the Debian package, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865956. That was probably a different bug though.