Getting more shared libraries out of HLFS

Kevin Day thekevinday at
Mon Dec 4 06:42:30 PST 2006

On 12/4/06, Robert Connolly <robert at> wrote:
> # Binutils shared libiberty:
> sed -e 's/libiberty.a/' \
>         -i {ld,gas,binutils,gprof,opcodes}/
> ./configure... --with-pic
> make tooldir=/usr all-libiberty &&
> mkdir libiberty/pic/dynamic &&
> cd libiberty/pic/dynamic &&
> ar x ../libiberty.a &&
> gcc -shared -o -Wl,-soname, *.o &&
> cp ../ &&
> cd ../../../ &&
> ln -vs pic/ libiberty/
> make....
> env LD_PRELOAD=$(pwd)/libiberty/ make check
> env LD_PRELOAD=$(pwd)/libiberty/ make tooldir=/usr install &&
> rm -v /usr/lib/libiberty.a &&
> install -v libiberty/ /usr/lib/ &&
> ln -vs /usr/lib/
> # I'm still checking how well this turns out, but it seems to work.
> robert

I have also done this with GCC, they store the libgcc.a in

This can be removed and replaced with a symbolic link to wherever your file is.
ln -vsf /usr/lib/ /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcc.a
and also adding
ln -vsf /usr/lib/ /usr/lib/

Once this is done, libgcov.a and libgcc_eh.a can be removed safely,
but I recommend backing up in case you ever want to create static
files again.  Some very few projects like uClibc get confused when
libgcc.a is shared, but a quick fix solved the problem for me.

The second link helps the LD find before it finds libgcc.a,
and hopefully linking things properly

I have thoroughly tested this by building a few complete workstation
and even games added like Wesnoth to see how this runs.  uClibc was
the only project that didn't like the libgcc.a being shared.  Which
was probably because it went out of its way to find where libgcc.a was
hiding and ignored

I have no clue, however, what this means when a PIC based shared
library is statically linked into a binary.  That is my only concern.

Kevin Day

More information about the hlfs-dev mailing list