Translate cobol to C on a single platform, then compile

massimo
2014-08-29
2014-09-04
  • massimo

    massimo - 2014-08-29

    hi,

    can i make the cobol to C translation (cobc -C) on a platform (suppose Linux), move the C source on the target machine (suppose Win, o some other linux), then compile and link the C code on each target?

    thanks,
    massimo

     
  • Simon Sobisch

    Simon Sobisch - 2014-08-29

    You can, as long as:

    • you use the same compiler as the generated C sources are tweaked (I think the only options here are GCC or Intel's expensive ICC)
    • the environment including configuration needs to be nearly identical between the build machines
    • you have to link manually with the correct switches

    We had to decide this in our COBOL team, too, and skipped the idea. Reasons:

    • you cannot have different compilers/configurations
    • it's likely to miss something or set something wrong with the compiler switches
    • you have to have libcob for every target machine as you want to link against it
    • if you generate libcob, you get cobc for free, there is no reason to not use it

    What we do now is the following:

    • have 1 dev machine where the code is compiled and tested
    • generate GC on every target machine that will be used later on (as you need libcob with all system specifics in there)
    • have 1 build machine for every architecture needed (x86/x64; AMD win, AMD unix, PPC, ...) [in our case totals to 5], the configuration doesn't have to be 100% identical as different GMP versions, and other system specifics are handled within libcob on the target machines [in our case totals to some hundred machines]
    • compile the tested COBOL sources on each of the build machines, compress the resulting so/dll and distribute it to the target machines

    Works like a charm :-)

    Simon

     
  • massimo

    massimo - 2014-08-29

    Simon,

    thanks. Can I please suggest me some way, or let me find some guide to build GC on a WIN machine? As you probabily guess, the C world is still a bit exhoteric for me...

    ciao,
    massimo

     
  • Simon Sobisch

    Simon Sobisch - 2014-08-29

    @Massimo: Depends highly on the compiler you want to use on Windows, there's the VC option (see FAQ entry), the GCC via MinGW option (see build guide on https://sourceforge.net/p/open-cobol/wiki/Gary%20Cutler%20Files/ - didn't checked yet but should work without patches with GC nightly tarball as well), the not-real-option GCC via Cygwin (very easy to set up, download the prerequisites via cygwin setup and do the rest "the unix way") and of course: any other compiler, if possible use an IDE like VC [integration available at least for ICC and clang] or Code::Blocks (supports nearly all compilers on Windows and imports the VC solutions) if you don't want to use your own compilers makefile.

    @Brian: please remove the vc12 references from the FAQ entry - as I've said: there is no need for a quote just kick out this information as it's not useful "standalone".

    Simon

     
    • Brian Tiffin

      Brian Tiffin - 2014-08-30

      ... please remove the vc12 references ...

      Done.

      Cheers,
      Brian

       
  • Anonymous - 2014-09-01

    thnks everybody,

    I'm already using the last 2.0 pre-built package on Windows. I guess this version uses the standard ISAM file handler http://sourceforge.net/projects/vbisam/ , am I right ?

    I'd like to make some tests on win with the Berkeley DB: I understood you have to select the file system at GC build time, so I need to build GC on win with the Berkeley option...is it correct ?

    thanks,

     
  • massimo

    massimo - 2014-09-01

    ...the previous post was mine, I forgot to log in.

    sorry,
    massimo

     
  • Simon Sobisch

    Simon Sobisch - 2014-09-01

    Here are the steps (untested):

    1. Do svn checkpout of 2.0 branch, sample folder: D:\projects\gnu-cobol-2.0
    2. Download the win-prerequistes from download area, unpack it to D:\projects\gnu-cobol-2.0\build_windows
    3. Download BDB, if necessary build it (you could download http://kiska.net/opencobol/human/msvc_mail.zip)
    4. place db*.h to D:\projects\gnu-cobol-2.0\build_windows, 32-bit to to D:\projects\gnu-cobol-2.0\build_windows\Win32, 64-bit lib to D:\projects\gnu-cobol-2.0\build_windows\x64, dlls to D:\projects\gnu-cobol-2.0\build_windows\Win32\release + debug, same for x64
    5. copy D:\projects\gnu-cobol-2.0\build_windows\config.h.bdb.win to D:\projects\gnu-cobol-2.0\build_windows\vcnnn\config.h (depending on your version)
    6. Open the solution D:\projects\gnu-cobol-2.0\build_windows\vcnnn\GNU Cobol.sln (depending on your version), open project options of libcob, change to all plattforms and all targets, replace libvbisam with libdbnn (depending on the BDB version, in the linked zip file it's libdb44).
    7. Open D:\projects\gnu-cobol-2.0\build_windows\vcnnn\defaults.h (depending on your version) and change COB_MAIN_DIR to match your directory (in the sample #define COB_MAIN_DIR "D:\projects\gnu-cobol-2.0")
    8. Press "build" and check if all works fine

    I suggest to not use the zip file linked for getting BDB but to get it from Oracle and build it from source, too.

    Simon

     
  • massimo

    massimo - 2014-09-01

    Simon,

    thank you very much, you're so kind.

     
  • massimo

    massimo - 2014-09-01

    Io triumphe,

    thanks to Simon suggestion I've been successful obtaining a GC 2.0 win32 via Micorosof VS 2010 :):):)

    but,
    my 2.0 built out of the 2.0 branch reads 2.0.20140120, while the win binary download is 2.0.20140821

    so, how can I find and download the patches to move my version to the "last" one?

    (pardon, I'm new to SVN also -- there's a lot to learn)

    ciao,
    massimo

     
  • Simon Sobisch

    Simon Sobisch - 2014-09-01

    You have the latest version (BTW: with own build BDB?) if you did a svn checkout.

    I've just didn't uploaded tarstamp.h which is included in build_win as version number yet.

    This will change someday to the revision number, along with changes to the version informations (seen in file->properties for cobc/cobcrun/libcob) and cobc/cobcrun --version - one of the changes here that are "started but unfinished work".

    Simon

     
  • massimo

    massimo - 2014-09-01

    Simon,

    BDB still to be implemented...I'll try soon.

    BTW, with this build the "add 1 to.." bug is back: https://sourceforge.net/p/open-cobol/discussion/help/thread/5c72f053/

    The bug was fixed by your upload of win binaries some days ago: how can I get the source(s) for this patch?

    thanks,
    massimo

     
    • Simon Sobisch

      Simon Sobisch - 2014-09-01

      ... MPIR is fun (or GC's usage of it ;-)

      I've did not applied any patch, just rebuild MPIR 2.6.0 with vc11 and used the gmp.h+mpir.lib+mpir.dll from these to rebuild the former version of GC. All the mpir files used are in the win_prerequisites. If you've used them it could be worth to get MPIR 2.6.0 and rebuild it with VS2010 (vc10 btw). Everything is included in the mpir download to build with vc10 (get the download from their website, build the dll project that suits you most and copy the binaries to your GC build_windows).

      Simon

       
  • massimo

    massimo - 2014-09-02

    Simon,

    I'm already using the mpir files from the win_prerequisites.
    I got the mpir download, recompiled the project:
    gmp.h are identical, both in the GC and in the mpir project
    mpir.lib and mpir.dll appear to be different
    so, should I now rebuild GC with the "new" mpir.lib, and put the "new" mpir.dll in my GC runtime dir ?

    ciao,
    massimo

     
    • Simon Sobisch

      Simon Sobisch - 2014-09-02

      It's normal that these are different as you compile with another VC version. Yes, use the same build versions (depending on which mpir project you've compiled you have a processor specific version and in any case not a dependency to vc11 runtime [at least not in mpir.dll]).

      In any case there seems to be a bug in GC (is in from the beginning) as it's get's some memory allocations for mpir/gmp via mpir/gmp function and doesn't use mpir/gmp functions for freeing the memory.
      Therefore the new version may still not work :-(

      Philipp is currently solving this ticket [bugs:#91], if your self-build version doesn't work wait until the ticket is closed, do an svn update of GC and rebuild it afterwards. I'll do the same for the binary package, too.

      Simon

       

      Related

      Bugs: #91

  • massimo

    massimo - 2014-09-02

    Simon,

    got it. In the meanwhile, I'll have some fun with GTK !

    ciao,
    massimo

     
    • Simon Sobisch

      Simon Sobisch - 2014-09-04

      So bug is solved, I guess you may got a svn update, build your package again (with/without BDB) and tried again?

      Simon

       
  • massimo

    massimo - 2014-09-04

    Simon,

    got the r413, it seems perfect. Thanks everybody.

    ciao,
    massimo

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks