[Top][All Lists]

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

Re: Help with static linking

From: Kip Warner
Subject: Re: Help with static linking
Date: Sat, 01 Jun 2013 16:27:46 -0700

On Fri, 2013-05-31 at 08:31 -0500, Robert Boehne wrote:
> Statically linking libc  is a recipe for disaster, so either read and 
> understand why, or just take my word for it.

I'm in agreement and standard libraries are something I'm fine with not
statically linking against, although it's not unusual for some games to
ship their own prefixed within their own installation. Although usually
when I see this, they're not statically linked, but separate shared
objects. Regardless, I understand what you are saying.

> I don't quite understand why you think you need the rest linked
> statically, 

Libraries like the following may not be present on the end user's system


These ones, especially the latter two, I'd prefer to statically link
with and there shouldn't be any harm in doing that.

> BUT the easiest way to do that would be to add LT_INIT to
> to use Libtool, and add --static-libtool-libs to the
> target's LDFLAGS.

Ok, so I tried the following in my,

        LDFLAGS="$LDFLAGS --static-libtool-libs"

The linker flag ended up making another check fail...

        AC_CHECK_LIB([ocrad], [OCRAD_version], [], [AC_MSG_ERROR([GNU
        OCRAD library is required, but unavailable...])])

So what I ended up doing was moving the LDFLAGS= line to near the end of
the just before AC_OUTPUT. It configures fine, but when I
build, I get the following during CXXLD build step...

        g++-4.7.real: error: unrecognized command line option

Same result if I move the LDFLAGS= initialization into as

        myproduct_LDFLAGS = --static-libtool-libs

> That will cause all of the Libtool libraries to be linked statically when 
> possible.

Just for my sake, when you say Libtool libraries, are you talking about
libraries that Libtool uses, or libraries that I mentioned above that I
am trying to statically link against?

> If you are only targeting Linux desktop systems, png, gobject, gio, and glib 
> should already be there, and in most cases already in memory, so you will 
> benefit from zero additional memory use for the code pages.  This also goes 
> for all the dependencies of these libraries.  I'm not familiar with zzip, so 
> if it isn't a Libtool library you will have to make sure it is linked like 
> this:
> -Wl,-static -lzzip -Wl,call_shared

This is the for zziplib. I don't really have much
meaningful experience with libtool, but based on my reading of this, I
think it is using it:


Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]