[GnuCOBOL-users] LGPL requirement for static linking (was: Re: Shipping exe files to others.)

[Simon Sobisch]

For static linking make sure to get the license dependencies right -
they often differ when you want to statically link a library.
See COPYING.LESSER or the nice summary at
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

And this is only the part for libcob, libvbisam, libc, libgmp (all
licensed as LGPL) - you'd have to recheck the other dependencies.

In short: if you want to ship the executable as one file you will also
have to provide all *object files* of your generated COBOL source (or
the source, whatever you like more) as this would allow the user to
relink it with a modified version.
This is not necessary if you let GnuCOBOL be installed on the system
beforehand and just use this version for dynamic library loading.

Simon

> Date: Fri, 24 Feb 2017 16:03:45 -0500
> From: Brian Tiffin <address@hidden>
> To: address@hidden, address@hidden
> Subject: Re: [GnuCOBOL-users] Shipping exe files to others.
> 
> John Culleton (home) wrote:
>>  
>>
>> When compiling a program into an exe file for distribution elsewhere
>> must the new user also have Gnu Cobol
>> installed?
>>  
>> John Culleton
>>  
> 
> Are you willing to dig a little?
> 
> It is possible to build a binary with a statically linked libcob, and
> all other dependencies as dynamic (at least on GNU/Liux) but it requires
> a tommy-two-step compile process.
> 
> First, use -save-temp and -v with cobc to get the compile commands used.
> 
> For instance:
> 
> Starting with a simple program, statically.cob
> 
>        identification division.
>        program-id. statically.
> 
>        data division.
>        working-storage section.
> 
>        procedure division.
>        display "hello"
>        goback.
>        end program statically.
> 
> Then a compile pass
> 
> prompt$ cobc -v -save-temp -x statically.cob
> 
> cobc (GnuCOBOL) 2.0-rc3.0
> Built     Feb 24 2017 13:48:33  Packaged  Nov 05 2016 15:27:33 UTC
> C version "5.4.0 20160609"
> loading standard configuration file 'default.conf'
> command line:   cobc -v -save-temp -x statically.cob
> preprocessing:  statically.cob -> statically.i
> return status:  0
> parsing:        statically.i (statically.cob)
> return status:  0
> translating:    statically.i -> statically.c (statically.cob)
> executing:      gcc -c -I/usr/local/include -Wno-unused -fsigned-char
>                 -Wno-pointer-sign -pipe -o "statically.o" "statically.c"
> return status:  0
> executing:      gcc -Wl,--export-dynamic -o "statically" "statically.o"
>                 -Wl,--no-as-needed -L/usr/local/lib -L/usr/local/lib
> -lcob -lm
>                 -lvbisam -lgmp -lncurses -ldl
> return status:  0
> 
> ####
> 
> Capture the gcc lines for inclusion in a Makefile
> 
> # Creating a static binding to libcob
> .RECIPEPREFIX = >
> 
> statically: statically.cob
>> cobc -save-temp -x statically.cob
>> gcc -c -I/usr/local/include -Wno-unused -fsigned-char
> -Wno-pointer-sign -pipe -g -o "statically.o" "statically.c"
>> gcc -o "statically" "statically.o" -Wl,--no-as-needed -L/usr/local/lib
> -L/usr/local/lib -Wl,-Bstatic -lcob -lvbisam  -Wl,-Bdynamic -lm -lgmp
> -lncurses -ldl
> 
> ####
> 
> The magic there is the -Wl,-Bstatic before -lcob and then -Wl,-Bdynamic
> for the rest.  In my particular build case, using VBISAM, the libvbisam
> linkage was also moved into the -Bstatic block (the order of -lm had to
> be shuffled around a little to come after -Bdynamic)
> 
> This make rule is fairly resilient to change, as cobc is still used in
> the first step to get a clean preprocessor pass from .cob sources (or
> .cbl if you prefer) and then the gcc commands are executed a second time
> on post C codegen to rejig things.
> 
> You go from
> 
> prompt$ cobc -x statically.cob
> prompt$ ls -l statically
> -rwxrwxr-x 1 btiffin btiffin 13408 Feb 24 14:54 statically
> 
> 
> to
> 
> prompt$ make -B statically
> cobc -save-temp -x statically.cob
> gcc -c -I/usr/local/include -Wno-unused -fsigned-char -Wno-pointer-sign
> -pipe -g -o "statically.o" "statically.c"
> gcc -o "statically" "statically.o" -Wl,--no-as-needed -L/usr/local/lib
> -L/usr/local/lib -Wl,-Bstatic -lcob -Wl,-Bdynamic -lm -Wl,-Bstatic
> -lvbisam -Wl,-Bdynamic -lgmp -lncurses -ldl
> 
> prompt$ -l statically
> -rwxrwxr-x 1 btiffin btiffin 969264 Feb 24 15:03 statically
> 
> Which is a full on one meg binary that displays "hello".
> 
> prompt$ ldd statically
>         linux-vdso.so.1 =>  (0x00007ffffdf6c000)
>         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe5bdbea000)
>         libgmp.so.16 => /usr/local/lib/libgmp.so.16 (0x00007fe5bd972000)
>         libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5
> (0x00007fe5bd74a000)
>         libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
> (0x00007fe5bd51a000)
>         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe5bd312000)
>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe5bcf42000)
>         /lib64/ld-linux-x86-64.so.2 (0x000055bf7230c000)
> 
> There are no runtime dependencies on libcob or libvbisam, the code is
> included in the executable (hence the one meg size).  Without the static
> vbisam, the binary is roughly 600K with just libcob included.
> 
> prompt$ ./statically
> hello
> 
> This is possible because the autotools builds of libcob (and vbsiam).
> libtool actually generates a libcob.a and libvbisam.a static copy that
> can be linked against.
> 
> I'd have no clue how to go about this with a VStudio build without
> experimenting a little bit, but I'm going to guess that with the proper
> tweaking, it is also possible on the Windows side.  cobc -v is handy as
> it displays all the steps, and can be used to good effect to capture and
> tweak the tool chain.
> 
> But, be wary of libdb licensing, and make sure it is not included as a
> static link in the build, or you need to pay attention to the sleepy cat
> third clause.  Otherwise, just include instructions on how to get
> dynamic libraries for libdb, libncurses, libgmp, (the other external
> dependencies (or build with vbisam as shown here).  ldd can be used to
> view the requirements of any final executable, or something like the
> 'depends' tool on Windows.
> 
> As an after thought, libncurses (or PDCurses) and libgmp can also ship
> with .a files, so you could theoretically build a dependency free
> GnuCOBOL executable, but that might take a little work on the tectonics.
>  Here I ended up with a 1.6 meg binary, but -ldl still needed to be
> dynamic, which is in the nature of a dynamic loader library ;-) and I
> left libc as dynamic as well.
> 
> Have good, make well,
> Brian