[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generation of static libraries is broken for a Rust sub-library (lib
From: |
Andrew W. Nosenko |
Subject: |
Re: Generation of static libraries is broken for a Rust sub-library (librsvg)? |
Date: |
Thu, 8 Feb 2018 02:16:02 +0200 |
What about marking librsvg_internals.a as 'noinst_'?
I never linked static library into static library (and even unsure that it
is correct at all), so cannot to say about your question directly, but from
what I know about noinst_ libtool "libraries", it can lead to result
desired by you.
On Wed, Feb 7, 2018 at 2:38 AM, Federico Mena Quintero <address@hidden>
wrote:
> Hi, everyone,
>
> I'm trying to figure out why librsvg's build setup is broken for static
> libraries. The automake/libtool machinery works fine to build
> librsvg.la, but the resulting librsvg.a is broken.
>
> Librsvg gets built from a bunch of .o files from C, and a
> librsvg_internals.a library built by Rust/Cargo. Rust properly
> compiles this internals library with PIC.
>
> After the .o files and the librsvg_internals.a are built, we use
> libtool in the usual fashion:
>
> address@hidden@/rust/target/@RUST_TARGET_SUBDIR@
> /librsvg_internals.a
>
> address@hidden@_la_LIBADD = \
> $(LIBRSVG_LIBS) \
> $(LIBM) \
> $(RUST_LIB)
>
> That is, LIBADD contains the librsvg_internals.a.
>
> The resulting librsvg.la is built just fine. However, the static
> librsvg.a is broken. For example, this is the output of "ar -t":
>
> $ cd ~/src/librsvg
> $ ar -t .libs/librsvg-2.a
> librsvg_internals.a <- this is the Rust sub-library
> librsvg_2_la-librsvg-enum-types.o
> librsvg_2_la-librsvg-features.o
> librsvg_2_la-rsvg-base-file-util.o
> [... a bunch of other .o files here ...]
>
> While I don't know all the details of how .a files are made from
> libtool, it sounds like that librsvg_internals.a should really be
> exploded into the individual .o files, and *those* put into the final
> librsvg.a library.
>
> Indeed if I have a tiny program foo.c:
>
> #include <librsvg/rsvg.h>
> int main(){
> RsvgHandle *svg = rsvg_handle_new_from_data (NULL, 0, NULL);
> }
>
> and build it like this:
>
> $ gcc -o foo foo.c `pkg-config --cflags librsvg-2.0` librsvg-2.a `pkg-
> config --libs cairo-fc gobject-2.0 gio-2.0 libxml-2.0` -lm
>
> it doesn't work; it gives me this output:
>
> librsvg-2.a(librsvg_2_la-rsvg-base.o): In function `add_node_to_handle':
> /home/federico/src/librsvg-latest/rsvg-base.c:207: undefined reference to
> `rsvg_node_ref'
> librsvg-2.a(librsvg_2_la-rsvg-base.o): In function `node_set_atts':
> /home/federico/src/librsvg-latest/rsvg-base.c:396: undefined reference to
> `rsvg_node_set_atts'
> /home/federico/src/librsvg-latest/rsvg-base.c:402: undefined reference to
> `rsvg_node_get_type'
> [... tons more of undefined symbols ...]
>
> Those symbols are indeed in the librsvg_internals.a sub-library.
>
> How can I make libtool create the toplevel librsvg.a correctly, out of
> a bunch of .o files and a librsvg_internals.a library that is already
> PIC-compiled?
>
> (This also breaks --disable-shared for the configure script.)
>
> Any suggestions are appreciated.
>
> (For reference, this is mentioned in both
> https://gitlab.gnome.org/GNOME/librsvg/issues/159 (Linux) and
> https://github.com/Homebrew/homebrew-core/issues/23772 (MacOS)).
>
> Thanks,
>
> Federico
>
>
>
>
--
Andrew W. Nosenko <address@hidden>