3 ms·
> The way you'd have to do static linking isn't something that is easy to set up in most build systems, it's trivial in CMake which is the most used buildsyste
by jcelerier 5y ago
> The way you'd have to do static linking isn't something that is easy to set up in most build systems,
it's trivial in CMake which is the most used buildsystem in languages with a linker, just set -DBUILD_SHARED_LIBS=0 on the command line
> and deprives you of the ability to do certain post-build steps (such as signing the build)
why would it ? I build my app as a set of static libs linked together in the end and there's no trouble signing it... and it does not make sense for people who will build their own custom version of your app to sign it.
here's a guide inspired by instructions given by Cisco to rebuild one of their proprietary apps for instance on iOS:
https://github.com/freedesktop/gstreamer/blob/master/README.static-linking#L109 https://github.com/freedesktop/gstreamer/blob/master/README....
- jcranmer 5y ago> it's trivial in CMake which is the most used buildsystem in languages with a linker, just set -DBUILD_SHARED_LIBS=0 on the command line Building or using static libraries isn't hard. Doing so in a way that doesn't violate the LGPL's replacement requirement is. The document you yourself linked says this about developing statically-linked libraries with the GPL: > If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. If you're distributing an object format, you need a .o that could be linked with the user's custom version of the LGPLed library. Building such a .o file cannot be done easily with tools, and that is what I'm referring to.
- jcelerier 5y agoI don't understand, if you can build your app statically then you have the .o ; a static library libfoo.a is just an archive of .o files that pretty much any Unix system can extract
- jcranmer 5y agoThe final link line in a build system for an application is generally `cc -o app file1.o file2.o file3.o ... -llib1 -lib2 -llib3`. Turning that link line into one that produces an app.o that can be combined with liblgpllib.a to produce an equivalent app file is nontrivial. (And before you say just add all the .o files into a single .a file, no, that is not equivalent. Because Unix linking sucks).
- jcelerier 5y ago... how is that not equivalent ? ar is just tar with less features. At worse extract the .o's from the .a beforehand if that causes issues but I'd really like to know where this differs
- dathinab 5y agoGPLs definition of "object" is not a .o file but "anything which is not source code".