pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Build error in graphics/librsvg

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

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 @@
 void rsvg_preserve_aspect_ratio (unsigned int aspect_ratio, double width,
                                  double height, double *w, double *h, double 
*x, double *y);
 gchar *rsvg_get_file_path (const gchar * filename, const gchar * basedir);
 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


#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

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.

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

Since: 2.6

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

Home | Main Index | Thread Index | Old Index