Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Nov 2012 13:54:02 -0700
From:      Gary Aitken <>
To:        FreeBSD Mailing List <>
Subject:   ld; extracting from libraries; and related questions
Message-ID:  <>

Next in thread | Raw E-Mail | Index | Archive | Help
I'm trying to track down why a library I've built doesn't have the stuff
it's supposed to.  The .o files are from a more recent port of glib, built 
in a non-standard place; but the .so contains files which appear to be from
the standard /usr/ports installation.  Something strange happened when
building the lib.

Using objdump I can see that the .o contains the correct version.

Is it possible to extract a .o from a lib.a or, so I can compare
it to the .o built by the make?

Initially, I was testing via a C program that dumps out
   glib_major_version, glib_minor_version, and glib_micro_version
In order to narrow this down, I ended up having to link as follows:

 ld -o a.out /usr/lib/crt1.o garya.o \
 ~/.../ports/devel/glib20/work/glib-2.34.1/glib/gversion.o \
 ~/.../ports/devel/glib20/work/glib-2.34.1/glib/.libs/ \

When the above linked a.out runs, I see the correct value (2.34.1)
When gversion.o is left out of the link, I see the incorrect version (2.28.8)

If I link with gversion.o and -lc only, I have unresolved symbols from crt1.o:
/usr/lib/crt1.o: In function `_start':
crt1.c:(.text+0x73): undefined reference to `_fini'
crt1.c:(.text+0x7d): undefined reference to `_init'

where should they come from?  I thought maybe I should be using crt0.o 
but I don't see one anywhere.  If I try adding in /usr/lib/crti.o,
which resolves the missing symbols, I get a segv before even entering main.

I also thought the .a was simply a static version of the .so, 
but that doesn't appear to be the case,
since linking with the .a still has the unresolved symbols.

I haven't done this for a *long* while so I'm pretty out of date.
Any clarifications would be much appreciated.



Want to link to this message? Use this URL: <>