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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
