Linking Statically with glibc and libstdc++

views:

138

answers:

+2 Q:

Linking Statically with glibc and libstdc++

Hey all,

I'm writing a cross-platform application which is not GNU GPL compatible. The major problem I'm currently facing is that the application is linked dynamically with glibc and libstdc++, and almost every new major update to the libraries are not backwards compatible. Hence, random crashes are seen in my application.

As a workaround, I distribute binaries of my application compiled on several different systems (with different C/C++ runtime versions). But I want to do without this. So my question is, keeping licensing and everything in mind, can I link against glibc and libstdc++ statically? Also, will this cause issues with rtld?

+6 A:

You don't need to.

Copy the original libraries you linked against to a directory (../lib in this example) in your application folder.

Like:

my_app_install_path

.bin
lib
documentation

Rename you app for something like app.bin. Substitute your app for a little shell script that sets the enviroment variable LD_LIBRARY_PATH to the library path (and concatenate the previous LD_LIBRARY_PATH contents, if any). Now ld should be able to find the dynamic libraries you linked against and you don't need to compile them statically to your executable.

Remember to comply with the LGPL adding the given attribution to the libraries and pointing in the documentation where the source can be downloaded.

Vitor Py 2010-07-09 15:41:09

@Vitor: This is best solution I think! I anyway distribute all third-party dependencies (ie, zlib, libssh, openssl, yada yada...) as shared libraries with the package. The only requirement I impose on users is that they have the standard C/C++ runtime installed on their system. If what you say works, I already have the infrastructure: The app is basically a service, so all scripts are already in place!!

themoondothshine 2010-07-10 04:47:09

@Vitor: I have another question: Will newer versions of RTLD be able to dynamically load all libraries even if they're compiled on really old systems? That is, I wouldn't have to worry about ld causing runtime issues if I ship libstdc++ and glibc with my app, right?

themoondothshine 2010-07-10 04:55:55

@themoondothshine Never had a problem with ld not being able to load all libraries. I've been doing this for the last 3 years to ship a closed-source GIS package on Linux.

Vitor Py 2010-07-10 14:59:19

@themoondothshine Also, I suggest you to target against a LSB version. QtCreator ships this way. Google Chrome does too. And if I recall correctly, so does Skipe. I don't think there's another way to ship closed source on Linux.

Vitor Py 2010-07-10 15:04:07

@Vitor: Thanks! That takes care of all my doubts!! Will definitely link against LSB versions of the libraries.

themoondothshine 2010-07-12 06:06:44

@Vitor: May I pester you with another question: So what files do you package with your binary? Here's what I thought I'd go about doing this: use ldd to determine the apps dependencies and package all listed files. This is the standard approach right?

themoondothshine 2010-07-12 12:43:58

Just ship everything that doesn't belong to the LSB version you target - you can write a few scripts to do this to you parsing the ldd results. A few things should never be shipped like the X11 libraries. Pack a rpm or a deb with the explicit lsb dependency and you're set.

Vitor Py 2010-07-12 13:45:03

I must question what the heck you are doing with the poor library functions?

I have some cross platform software as well. It runs fine on Linux systems of all sorts. Build with the oldest version of software that you want to support. The glibc and libstdc++ libraries are really very backward compatible.

I have built on CentOS 4 and run it on RHEL 6 beta. No problems. I can build on stable Debian and run it on testing.

Now, I do sometimes have trouble with some libraries if I try to build on, say old Debian and try to run it on CentOS 5.4. That is usually due to distribution configuration choices that are different, like choosing threading or non-threading.

Zan Lynx 2010-07-09 15:57:53

@Zan: Let me tell you exactly what happened: I used to compile my binaries on CentOS 3.9 (with an old version of glibc -- 2.3.something). Now, this binary began crashing on CentOS 5.4 and the core dumps just didn't point anywhere. I finally went to the developers of CentOS and they were surprised that the application worked for almost a month without incident on CentOS 5.4. They'd suggested I use Fedora's MockBuild system, but I decided to go for compiling natively on multiple platforms. So what I'm doing with the library functions isn't as much the problem as it is of backwards compatibility.

themoondothshine 2010-07-10 04:42:23

+5 A:

glibc is under the LGPL. Under section 6. of LGPL 2.1, you can distribute your program linked to the library provided you comply with one of five options. The first is to provide the source code of the library, along with the object code (source is optional, not required) of your own program, so it can be relinked with the library. You can alternatively provide a written offer of the same. Your own code does not have to be under the LGPL, and you don't have to release source.

libstdc++ is under the GPL, but with a major exception. You can basically just distribute under the license of your choice without providing source for either your own code or libstdc++. The only condition is that you compile normally, without e.g. proprietary modifications or plugins to GCC.

IANAL, and you should consider consulting one if you need real legal advice.

Matthew Flaschen 2010-07-09 16:00:58

ansaurus

tags:

views:

answers:

Linking Statically with glibc and libstdc++

related questions