Re: Help with static linking

[Kip Warner]

On Sun, 2013-06-02 at 10:45 -0400, Paul Smith wrote:
> I'm removing automake from this thread as I'm getting two copies of
> every mail.  Hope no one minds.

No problem. I'll try to remember to do the same.

> This is because GCC has some of its internal functionality implemented
> in libraries, which are linked dynamically by default.  This is
> especially true if your program is written in C++, because the STL is
> provided with the compiler and is very compiler-specific.  However, even
> some low-level C functionality is implemented as a shared library.

Understood. Good explanation.

> If the runtime system has an older version of the compiler with older
> versions of these libraries, you can run into trouble (again, C++ is the
> biggest culprit: the C helper libraries are pretty stable, release to
> release, in general).
> 
> This is easily solved, though.  You just have to add the -static-libgcc
> and, if you use C++, -static-libstdc++ to the link line, then these
> helper libraries are linked statically and doesn't matter what version
> of GCC is installed on the system.

That's a great solution. So what I've done in my configure.ac is the
following...

        LDFLAGS="$LDFLAGS -static-libgcc -static-libstdc++"

What I should probably do is have that conditionally done based on some
flag to ./configure, but I'm not sure what would be the most appropriate
thing to call it. I know --enable-static is a convention with specific
semantics with libtool.

Another thing, I see the the libstdc++.so.6 and libgcc_s.so.1 removed
from its dependencies according to objdump, but I did note the addition
of a new one, ld-linux-x86-64.so.2. Do you think that will be a problem?

> These libraries have a special exception to the GPL, which allows them
> to be statically linked in straightforward situations without the result
> being GPL-licensed.  See the license for details.

Aye, I think I've got everyone a bit sketched out about my needs. Rest
assured, it's all GPL'd <http://rod.gs/A2m>.

> However, using the "old image" method is, IMO, not a good solution for
> any larger-scale development.  It's slow, difficult to manage, and
> generally painful.

Agreed.

> My recommendation for this situation is to instead create a "sysroot",
> which is basically a directory structure containing the dev files for a
> given distribution: header files and libraries (.so and .a).  You don't
> need any bin, man, etc. files.  Pick a pretty old distribution (the
> oldest that you want to support).  The current-minus-one Debian or Red
> Hat distros are good choices, generally, because they usually have such
> old versions of everything that it's unusual to find another mainstream
> distro with older versions.
> 
> Alternatively, if you prefer to distribute different packages for
> different systems, you can create multiple sysroots: one for each
> system.  They're not that big and are easy to manage.
> 
> Then use GCC's --sysroot flag to point the compiler at the sysroot
> directory structure rather than your system's headers and libraries.
> 
> Now your build environment is portable and completely divorced from the
> version of the underlying build system and the result will run on any
> distribution which has the same or newer versions of libraries as your
> sysroot.
> 
> It's a bit of effort to set up but it's a LOT nicer than dealing with
> virtual machines with older releases loaded, or whatever.

I wonder if I could do this for a GNU/Linux i386 binary and amd64, and a
w32 binary via mingw sysroot, if such a thing is possible.

> Regarding autoconf: using the above setup you have two choices I can
> see.  First you can just go with it as-is, and hope the result works
> well (it probably will).  Second you can try to build your packages as
> if you were cross-compiling, which is a little safer since autoconf
> won't try to use your build system to infer things about your host
> system, if it detects that they're different.  However, not all packages
> have perfect support for cross-compilation so it may be more work.

Thanks a lot Paul. I'll get back to you guys if I have issues.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com

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