gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GnuCOBOL-users] Shipping exe files to others.


From: Brian Tiffin
Subject: Re: [GnuCOBOL-users] Shipping exe files to others.
Date: Fri, 24 Feb 2017 16:03:45 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]