liba52 make fail
ken at linuxfromscratch.org
Fri Dec 19 06:28:08 PST 2008
On Fri, Dec 19, 2008 at 01:28:19PM +0200, Lauri Kasanen wrote:
> Using static libraries does not prevent linking them, it just might be more complicated.
> However, for the original problem, build requiring -fPIC, you can just force it by adding that flag to your CFLAGS and CXXFLAGS before running configure. That has worked for me several times (on a pure64 bit CLFS build too).
Yes, that is the general way to force it. I have the following in
my current scripts (for x86_64), there used to be a few more but the
upstreams have caught up with the platform.
if [ $ARCH = x86_64 ]; then
sed -e 's%-O3%-O3 -fPIC%' \
cp makefiles/makefile.linux Makefile
gpl-ghostscript (this is from cblfs) :
sed -i "s/CFLAGS='/&-fPIC /g" src/unix-dll.mak
for liba52, which started this, I had the following in the configure
(but I've commented out the package, I decided I didn't need it)
for ffmpeg (the old snapshot still in BLFS)
(I think this is not needed with recent snapshots).
My view of static libraries is that most of us need to avoid them,
and failing that, we need to know when they have been used so that
we can keep track of what to rebuild after a vulnerability becomes
known. I admit I haven't yet applied that to the base LFS/clfs
systems (did a bit in my last LFS, identified that module-init-tools
needs static libz - not really a surprise). If in doubt
(particularly, mozilla products and tcl) I rename the static libs
to filename.a.hidden so that if I later need them I can temporarily
restore them to the original name. I also do that for static libs
that I can't otherwise prevent (compare fedora - they do the DESTDIR
install, then remove them). For all my desktop packages I attempt
to build without static libs.
Getting rid of static libs also saves some space. Application
hackers are, of course, free to build and use them where it makes
das eine Mal als Tragödie, das andere Mal als Farce
More information about the blfs-support