Re: Build error in graphics/librsvg

[Rhialto <rhialto%falu.nl@localhost>]

On Sun 08 Jul 2012 at 17:24:38 +0200, Rhialto wrote:
> However, I see that LIBTOOL is used, and that should know how to make
> shared libraries too. In fact, -fPIC -DPIC is seen in the .work.log
> file, even if I don't edit the original Makefile, but not on all commands:
> 
> no PIC        [*] 
> /pkg_comp/obj/pkgsrc/graphics/librsvg/default/.wrapper/bin/libtool 
> /pkg_comp/obj/pkgsrc/graphics/librsvg/default/.wrapper/bin/libtool 
> no PIC        <.> /usr/pkg/bin/libtool --silent --tag=CC --mode=compile cc 
> PIC   [*] /pkg_comp/obj/pkgsrc/graphics/librsvg/default/.wrapper/bin/cc 
> PIC   <.> /pkg_comp/obj/pkgsrc/graphics/librsvg/default/.gcc/bin/gcc 
> no PIC        [*] 
> /pkg_comp/obj/pkgsrc/graphics/librsvg/default/.wrapper/bin/cc 
> no PIC        <.> /pkg_comp/obj/pkgsrc/graphics/librsvg/default/.gcc/bin/gcc 
> 
> I'm not sure yet what to make of this.

Looking at it a bit longer, it seems to me that he first 4 lines are for
creating a shared object, .libs/blah.o, and the last 2 for a plain
object file, for making a plain static library. So nothing out of the
ordinary.

However, looking with objdump -x at the .libs/*.o files, they're full
with the R_X86_64_PC32 relocations that the error message complained
about. They also have some R_X86_64_PLT32 ones, which are, iirc, the
ones that are supposed to be used in PIC files, right? At least they're
not in any of the plain static .o files.

Ah, of course, plain relocations can be used inside PIC object files,
just not for external symbols (which may come from an external shared
library). So somehow gcc thought it had an internal reference to the
symbol where it really was an external one (to a different object file
for the same library).

Soo... some grepping later I found this:

--- rsvg-image.h.orig   2012-07-08 22:08:18.000000000 +0200
+++ rsvg-image.h        2012-07-08 22:05:46.000000000 +0200
@@ -51,7 +51,7 @@
 G_GNUC_INTERNAL
 void rsvg_preserve_aspect_ratio (unsigned int aspect_ratio, double width,
                                  double height, double *w, double *h, double 
*x, double *y);
-G_GNUC_INTERNAL
+// G_GNUC_INTERNAL
 gchar *rsvg_get_file_path (const gchar * filename, const gchar * basedir);
 G_GNUC_INTERNAL
 cairo_surface_t *rsvg_cairo_surface_new_from_href (RsvgHandle *handle, const 
char *href, GError ** error);

which looks exactly like the sort of lying to the compiler which will
make it get its revenge! (And I must say that the code evokes a rather
worrying amount of warnings from the compiler...)

Indeed, removing G_GNUC_INTERNAL from that declaration makes the library
link. I am now proceeding to the things that were requiring the library.
For the moment I'd say that the above patch or an equivalent should be
added to librsvg.





Extracted from 
http://developer.gnome.org/glib/2.30/glib-Miscellaneous-Macros.html:

G_GNUC_INTERNAL

#define G_GNUC_INTERNAL __attribute__((visibility("hidden")))

This attribute can be used for marking library functions as being used
internally to the library only, which may allow the compiler to handle
function calls more efficiently. Note that static functions do not need
to be marked as internal in this way. See the GNU C documentation for
details.

When using a compiler that supports the GNU C hidden visibility
attribute, this macro expands to __attribute__((visibility("hidden"))).
When using the Sun Studio compiler, it expands to __hidden.

Note that for portability, the attribute should be placed before the
function declaration. While GCC allows the macro after the declaration,
Sun Studio does not.

G_GNUC_INTERNAL
void _g_log_fallback_handler (const gchar    *log_domain,
                              GLogLevelFlags  log_level,
                              const gchar    *message,
                              gpointer        unused_data);

Since: 2.6

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- There's no point being grown-up if you 
\X/ rhialto/at/xs4all.nl    -- can't be childish sometimes. -The 4th Doctor