Re: [Tiny-cobol-users] Up and running.

[David E. <de...@us...>]

John R. Culleton wrote:

 > David Essex wrote:
 > ...
 >
 >> If you are only moving the TC compiled programs, since you
 >> are using a static TC run-time, all you need are the COBOL
 >> program binary(s) and the run-time config file 'htrtconf'.
 >
 > First my goal is to move as little as possible, to give the
 > user an application that will run on any Linux system without
 > much fuss and feathers.
 >
 > Given that goal, is the compiled static binary and the control
 > file sufficient?

The short answer is YES, that is all you need.
Once copy of the run-time config file 'htrtconf' placed in the default 
install location.


 > Does Berkeley DB need to be moved also or is that included in
 > the static compiled binary?

Yes, the TC run-time uses the Berkeley DB and the ncurses (if the screen 
section and/or display/accept AT ... are used) libraries.
You can check for for missing library dependencies using the 'ldd 
program' command.



 > Also I need a little help with the htcobolrc file compile
 > options. Here are the options:
 > # Specify the compiler default action
 > # P     - preprocess
 > # PC    - preprocess,compile
 > # PCA   - preprocess,compile,assemble
 > # PCAL  - preprocess,compile,assemble,link to executable
 > # PCAX  - preprocess,compile,assemble,link to executable
 > # PCAS  - Preprocess, compile, assemble, link to static library
 > # PCAM  - Preprocess, compile, assemble, link to shared library
 > # (compiler default=PCAL)
 > COMPILE_DEFAULT: PCAL
 > #COMPILE_DEFAULT: PCAS
 > #COMPILE_DEFAULT: PCAM
 > #
 >
 > Assuming that I want everything rolled into one binary, is the
 > correct choice PCAS or PCAX?

The PCAS/PCAX options do not roll everything into one binary.

These options create a library (static or shared) from the COBOL sources.


 > Also, what is the difference between PCAL and PCAX? They have
 > identical definitions above.

Yes, The PCAL and PCAX options are identical.


TC generates GNU assembler form the COBOL sources then uses the GCC tool 
chain to create objects, libraries or binary executables.

Are trying to create a binary executable, form the COBOL sources, 
without any shared libraries dependencies.
If so then yes, in theory that can be done.
Assuming that the static libraries are available on your system for all 
dependencies.