search

LADSoft / OrangeC

OrangeC Compiler And Tool Chain
http://ladsoft.tripod.com/orange_c_compiler.html
Other
302 stars 39 forks source link

GnuCOBOL test bed #168

Open GitMensch opened 6 years ago

GitMensch commented 6 years ago

In general I'm still trying to get a working GnuCOBOL with OrangeC - which is my main interest for now as it provides a nice testsuite. Providing you with my local testbed (including all "special" headers, libraries and dll's needed) looks to be the easiest way to give you the option to reproduce different issues reported.

I've just upgraded to the last CI build which shows green, that is currently 1.0.397 - binaries: https://ci.appveyor.com/api/buildjobs/qgn0qthirt1a80qg/artifacts/dist%2Focc60371e.zip - and I can reproduce the following issues.

Just:

bonus:

I may go on with this list later, but for now: gnucobol-testbed.zip 17MB

LADSoft commented 6 years ago

handing me this was a good idea; I'm able to fix a lot of stuff beyond what you talked about here.

A couple of things are probably going to come out of this: first I now see the need for a 'modules' window and second when #line is used maybe the debugger should index the original source file...

LADSoft commented 6 years ago

I did a lot of stuff with this, now you can debug reasonably and the files run after you build them :) Still working on the msys build though...

LADSoft commented 6 years ago

as of right now cobc compiles in the IDE and runs; it compiles also with the autoconf scripts but crashes when you run it.

GitMensch commented 6 years ago

I'm starting to run the testsuite with the generated programs (currently only possible with the IDE generated one because of the libtool wrapper executables chrashing as noted in #56).

Test results so far (I won't go on for now because of #203 resulting in many errors and the crash with #207 is stopping actual run tests):

LADSoft commented 6 years ago

i've fixed all these except the binary mode issue and the broken NIST test runner. I was thinking the binary mode issue may be related to #130 because I could have sworn the behavior was wrong at one point but couldn't duplicate it later. I'll have to write a little test program and really exercise it.

GitMensch commented 6 years ago

Please reopen as not all issues are fixed yet.

LADSoft commented 6 years ago

Sorry I guess I got close-happy, I didn't intend to close this though :)

bencz commented 6 years ago

@GitMensch Interesting... I had been thinking about compiling GnuCobol with OCC a while ago... I use GNU cobol! :)

GitMensch commented 6 years ago

@bencz Won't work stable enough yet from the OrangeC side and misses adjustments in GnuCOBOL to actually be able to compile without the need to manually call occ- but it looks like we get at least near there "soon". Nonetheless you are warmly invited to join developing GnuCOBOL, it looks like it would match your compiler studies :-) [Just drop a note in the GnuCOBOL discussion boards if you have interest in this].

LADSoft commented 6 years ago

Hi Alexandre, well the first thing I thought of when Simon brought out gnucobol was you :)

This is pretty good though, tests with this are really making the compiler a lot better...

GitMensch commented 6 years ago

@LADSoft: There is a likely another string function / printf error found:

To reproduce: run cobc -fsyntax-only -w -Wconstant-expression prog.cob.txt with the following file: prog.cob.txt

The expected result is:

prog.cob:5: warning: expression '3' EQUALS '1' is always FALSE
prog.cob:6: warning: expression '3' EQUALS '2' is always FALSE
prog.cob:6: warning: expression is always FALSE
prog.cob:6: warning: expression '3' EQUALS '3' is always TRUE
prog.cob:6: warning: expression is always TRUE
prog.cob:10: warning: expression '3' EQUALS '1' is always FALSE
prog.cob:11: warning: expression '3' EQUALS '2' is always FALSE
prog.cob:11: warning: expression '3' EQUALS '3' is always TRUE
prog.cob:11: warning: expression is always FALSE

the actual result is

prog.cob:5: warning: expression '                                     3' EQUALS '                                     1' is always FALSE
prog.cob:6: warning: expression '                                     3' EQUALS '                                     2' is always FALSE
prog.cob:6: warning: expression is always FALSE
prog.cob:6: warning: expression '                                     3' EQUALS '                                     3' is always TRUE
prog.cob:6: warning: expression is always TRUE
prog.cob:10: warning: expression '                                     3' EQUALS '                                     1' is always FALSE
prog.cob:11: warning: expression '                                     3' EQUALS '                                     2' is always FALSE
prog.cob:11: warning: expression '                                     3' EQUALS '                                     3' is always TRUE
prog.cob:11: warning: expression is always FALSE

Can you set a breakpoint in cobc where the " is always " message occurs and check for the error?

LADSoft commented 6 years ago

bug in sprintf... it was setting the width equal to the precision..

GitMensch commented 6 years ago

I'm in the process of rechecking this. @LADSoft Do you see any option to investigate what is wrong with the libtool wrappers?

When I call them directly I get an access violation:

$ /c/dev/gnucobol/_build_occ/cobc/.libs/cobc_ltshwrapper

Access Violation:(c:\dev\gnucobol\_build_occ\cobc\.libs\lt-cobc.exe)
CS:EIP 0023:83E58955  SS:ESP 002B:0019FF10
EAX: 00000001  EBX: 758C8484  ECX: 00527498  EDX: 004FA9D4  flags: 00010217
EBP: 0019FF1C  ESI: 00000000  EDI: 00393000
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

Stack trace:
        83e58955
        40cdb1: main + 0xe  module: ../../cobc/cobc.c, line: 8233
        47b591: __startup + 0x1c7

$ /c/dev/gnucobol/_build_occ/bin/.libs/cobcrun_ltshwrapper

Access Violation:(c:\dev\gnucobol\_build_occ\bin\.libs\lt-cobcrun.exe)
CS:EIP 0023:81E58955  SS:ESP 002B:0019FEF0
EAX: 00000001  EBX: 758C8484  ECX: 00000001  EDX: 003AF000  flags: 00010202
EBP: 0019FF20  ESI: 00000000  EDI: 003AC000
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

Stack trace:
        81e58955
        401834: main + 0xab  module: ../../bin/cobcrun.c, line: 375
        401b55: __startup + 0x1c7

Note: The referenced lines are for cobcrun the first call to internal functions. For cobc it is the access to argc, but I guess the line calculation is wrong by 2 and it is really line 8231 - also the first call to an internal function.

I've just tried to really use a static version for the MSYS based build. To achieve this fix common.h (around line 390) to allow it in general:

+#ifndef COB_EXPIMP
 #if    ((defined(_WIN32) || defined(__CYGWIN__)) && !defined(__clang__))
 #ifdef COB_LIB_EXPIMP
    #define COB_EXPIMP  __declspec(dllexport) extern
 #else
    #define COB_EXPIMP  __declspec(dllimport) extern
 #endif
 #else
    #define COB_EXPIMP  extern
 #endif
+#endif

and using:

$ cd /c/dev/gnucobol/_build_occ
$ export PATH=$PWD:$PATH # mpir.dll, pdcurses.dll and libvbisam.dll are here
$ ../configure "CC=occ --nologo" "MAKE=omake -w" "LD=olink --nologo" "CPP=ocpp --nologo" "CXX=occ --nologo" "CXXCPP=ocpp --nologo" "GREP=ogrep" "EGREP=ogrep" "NM=onm --nologo" "CPP_FOR_BUILD=ocpp --nologo" CC_FOR_BUILD="occ --nologo" AR="olib --nologo" \
    RANLIB="echo no ranlib" STRIP="echo no strip" \
    CPPFLAGS="-I$PWD -I$PWD/../build_windows -DCOB_EXPIMP=extern" \
    LDFLAGS="-L$PWD" \
    --with-vbisam --enable-static --disable-shared
$ # patch libtool script (`lib -OUT:` -> `olib -o`) here
$ omake

Leading to libcob, cobc and bin being built without any issue (first time!) and still failing in extras directory. Doing it manually with verbose compilation:

$ cd extras
$ . ../tests/atconfig && . ../tests/atlocal extras-CBL_OC_DUMP.dll && $COBC -m -vv -Wall -O2 -o "CBL_OC_DUMP.dll" "$(_return_path ../../extras/CBL_OC_DUMP.cob)" -save-temps
cobc (GnuCOBOL) 3.0-dev.0
Built     Jun 10 2018 14:36:54  Packaged  Feb 01 2018 20:06:17 UTC
C version (OrangeC) "6.0.37.1"
loading standard configuration file 'default.conf'
command line:   c:\dev\gnucobol\_build_occ\cobc\cobc.exe -m -vv -Wall -O2 -o CBL_OC_DUMP.dll -save-temps ../../extras/CBL_OC_DUMP.cob
preprocessing:  ../../extras/CBL_OC_DUMP.cob -> CBL_OC_DUMP.i
return status:  0
parsing:        CBL_OC_DUMP.i (../../extras/CBL_OC_DUMP.cob)
return status:  0
translating:    CBL_OC_DUMP.i -> CBL_OC_DUMP.c (../../extras/CBL_OC_DUMP.cob)
executing:      occ --nologo
                -I/c/dev/gnucobol/_build_occ/..
                -I/c/dev/gnucobol/_build_occ/../libcob -I/usr/local/include
                -I/c/dev/gnucobol/_build_occ
                -I/c/dev/gnucobol/_build_occ/../build_windows
                -DCOB_EXPIMP=extern -yy -shared -DDLL_EXPORT -DPIC -o
                "CBL_OC_DUMP.dll" "CBL_OC_DUMP.c"
                -Lc:/Users/simon/Desktop/dev_desktop/gnucobol-stuff/_build_occ/libcob/.libs
                -L/c/dev/gnucobol/_build_occ -yy
                -Lc:/Users/simon/Desktop/dev_desktop/gnucobol-stuff/_build_occ/libcob/.libs
                -lcob -lm -lvbisam -lgmp -lpdcurses
Fatal error: Invalid stack alignment parameter return status:   1

Two questions here:

LADSoft commented 6 years ago

sorry for the long delay.

you are correct about the line 8233 thing, it should indeed be 8231. There is a vagary because the function being called has no arguments and no return value so the point just after the function call actually is on the next 'C' language line... I think I can fix it though :)

At this point i would try to verify that you indeed aren't setting the declspec declarations... what i normally do when I want to know if part of a header is being compiled but am unsure about the #defines is type garbage at the point I want to test... if this elicits a compiler error it is being compiled otherwise it isn't.

the 'fatal error' is likely due to the command line parameter -save-temps which orange c interprets as something else.

LADSoft commented 6 years ago

as I left this early last week, I think there was a problem in the headers with the 'export' declarations. They were always being enabled, and since the versions being built in the make environment used static libraries the make-built versions wouldn't run. When I changed the headers I was able to build a running version. Is that resolved to your satisfaction now?

LADSoft commented 6 years ago

I was wondering where we stood on this in general? Are some of the open issues related to this?

GitMensch commented 6 years ago

@LADSoft wrote:

Are some of the open issues related to this?

The headers part is fixed within GnuCOBOL now (you need to pass an extra define to build static versions). Also fixed within GnuCOBOL is the issue with "code in libcob may be called without changing binary mode" (this is still an issue for some parts in the testsuite but this should be solved in the testcase definitions). Building the extras directory works, too.

56 is related but doesn't need to work as long as make is usable.

220 is related as it is the reason for the float/dobule math tests failing.

When using the current CI build I cannot build cob/parser.c and others in OCIDE using build type "Debug":

;============ Compiling parser.c ============
Internal Error - Aborting compile
Compile done.  Errors: 0,  Warnings: 0

Using the "Release" build type works this time.

I was wondering where we stood on this in general?

Actually there are some main issues where the occ (CI "e" build) generated cobc and/or libcob behave different than with any other compilers.

I wasn't able to debug these issues yet (which I've tried using OCIDE, which was the reason for issues concerning OCIDE/debugger). If I remember correctly there was only one which I think I should be able to debug, all others would likely be left to you - but these will likely be long debugger runs as thousands of code lines are executed before you see that something is very wrong...

If I know that you'll do this task I'll create an updated testbed and detail some failures here (but ideally the "precision too low by 1" issue is fixed first).

LADSoft commented 6 years ago

Sorry I accidentally closed it. I've fixed the parser.c issue now... if you want to make a package for me to debug the other problems you have please do, but be aware I probably won't get to it for several weeks. The update of the assembler and switch of the floating point code is likely to be time-intensive... although I may at least go looking for a floating point library so I don't have to implement all that from scratch :)

GitMensch commented 5 years ago

Just checked how far I get with cobc/cobcrun and a static lib generated with MSYS2 and only OrangeC tools (current CI build). Result: Everything is build and the executables are broken:

Access Violation:(C:\dev\gnucobol\build_occ\cobc\cobc.exe)
CS:EIP 0023:59003D83  SS:ESP 002B:0019FF0C
EAX: 00000001  EBX: 00000001  ECX: 00554CA8  EDX: 005264BC  flags: 00010207
EBP: 0019FF78  ESI: 023C0068  EDI: 003F2000
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

Access Violation:(C:\dev\gnucobol\build_occ\bin\cobcrun.exe)
CS:EIP 0023:748B5653  SS:ESP 002B:0019FF24
EAX: 00000000  EBX: 00000001  ECX: 00461746  EDX: 004616B6  flags: 00010246
EBP: 0019FF78  ESI: 022B0070  EDI: 0029C000
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

Does this tell you anything?

LADSoft commented 5 years ago

the second one died probably in kernel32.dll, the first one either in some other dll or off at a random address... I guess I really should show the data at the eip so we can tell if it is really processing code lol!

LADSoft commented 5 years ago

this seems to be due to the definition of 'COB_EXPIMP' in libcob\common.h. It needs to be aliased to 'declspec(dllimport) to build with the IDE, because you are building the library as a DLL there. However in the command line build you are statically linking the library so it needs to be aliased to either nothing or 'extern' to prevent unwanted behaviors. Once I changed it for the command line build cobc.exe at least ran although it can't currenty find files it needs :)

GitMensch commented 5 years ago

I guess I really should show the data at the eip so we can tell if it is really processing code

Yes, please do so.

COB_EXPIMP ....

Yes, I have to recheck what I did there, likely configure should add something to CFLAGS when building a static library (which is no good idea for different reasons, but it should work).

After doing this and at least checking the failed tests in the GnuCOBOL internal test suite I'll update the testbed.

LADSoft commented 5 years ago

I modified the exception dumps to show cs:eip: e894cd093ecf46570aa39c4c6dc15cfe98766ab7

LADSoft commented 5 years ago

are you still planning on coming up with a new version of the testbed? #56 is held up by that right now.

GitMensch commented 5 years ago

are you still planning on coming up with a new version of the testbed?

Actually the current trunk in GnuCOBOL has most stuff integrated (including the OCIDE project files). You'd primarily need:

For tests:

For now I can report an access violation. Without debug:

Access Violation:(C:\\dev\gnucobol\build-occ\tests\cobol85\NC\NC132A.exe)
CS:EIP 0023:00412AA1  SS:ESP 002B:0019F0DC
EAX: 00000000  EBX: 02CE3BEF  ECX: 00000003  EDX: 004194DC  flags: 00010202
EBP: 0019F0E0  ESI: 00000002  EDI: 0030A000
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

CS:EIP  8A 03 43 2A 02 E1 F8 75 05 2B C0 5B 5D C3 0F BE

Stack trace:
                        412aa1
                        4037d4

With debug:

Access Violation:(C:\\dev\gnucobol\build-occ\tests\cobol85\NC\NC132A.exe)
CS:EIP 0023:00416451  SS:ESP 002B:0019F270
EAX: 00000000  EBX: 02D38EE7  ECX: 00000003  EDX: 0041D53D  flags: 00010202
EBP: 0019F274  ESI: 00000002  EDI: 003D9000
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

CS:EIP  8A 03 43 2A 02 E1 F8 75 05 2B C0 5B 5D C3 0F BE

Stack trace:
                        416451
                        405ff1
                        4010a5
                        401091
                        40988f

Can you "see" something there? Shouldn't the stack trace reference source files?

Interestingly the runtime dll libcob can only catch the SIGSEGV if the NC132A is compiled as dll itself. In this case we get a clean SIGSEGV with error reporting showing that the error happened for "line 595", find the code below:


#define cob_u8_t        unsigned 
#define cob_u8_ptr      cob_u8_t *

#define cob_s64_t       __int64
#define cob_u64_t       unsigned __int64

#define COB_S64_C(x)        x ## I64
#define COB_U64_C(x)        x ## UI64

#define COB_BSWAP_64_CONSTANT(val)  ((cob_u64_t) (      \
    (((cob_u64_t) (val) &                   \
      (cob_u64_t) COB_U64_C(0x00000000000000FF)) << 56) |   \
    (((cob_u64_t) (val) &                   \
      (cob_u64_t) COB_U64_C(0x000000000000FF00)) << 40) |   \
    (((cob_u64_t) (val) &                   \
      (cob_u64_t) COB_U64_C(0x0000000000FF0000)) << 24) |   \
    (((cob_u64_t) (val) &                   \
      (cob_u64_t) COB_U64_C(0x00000000FF000000)) <<  8) |   \
    (((cob_u64_t) (val) &                   \
      (cob_u64_t) COB_U64_C(0x000000FF00000000)) >>  8) |   \
    (((cob_u64_t) (val) &                   \
      (cob_u64_t) COB_U64_C(0x0000FF0000000000)) >> 24) |   \
    (((cob_u64_t) (val) &                   \
      (cob_u64_t) COB_U64_C(0x00FF000000000000)) >> 40) |   \
    (((cob_u64_t) (val) &                   \
      (cob_u64_t) COB_U64_C(0xFF00000000000000)) >> 56)))

static cob_u8_t b_8[8]; /* SUB-3 */
static cob_u8_t b_14[20];   /* TABLE-A */

/* breaking here: */

  if (((int)memcmp (b_14 + 3 * (((cob_s64_t)COB_BSWAP_64(*(cob_s64_t *)(b_8))) - 1), (cob_u8_ptr)"222", 3) == 0))
  { ...

Otherwise it looks quite good (the testsuite reports ~20 errors because of wrong line ending [I'll check later this week what MSVC does in those places]) and I think we have ~5 "real" errors left.

GitMensch commented 5 years ago

Rechecked with latest building version from Appveyor and a plain msys2 environment + source_configure placed in build-occ, getting to

CS:EIP 0023:83603D83  SS:ESP 002B:0019FF0C
EAX: 00000001  EBX: 00000001  ECX: 00569298  EDX: 0053A68C  flags: 00010207
EBP: 0019FF78  ESI: 023E0040  EDI: 002FC000
 DS:     002B   ES:     002B   FS:     0053   GS:     002B

There was some bad part when doing so - do you remember or see from that stack trace where the issue was?

LADSoft commented 5 years ago

the main thing with compiling gnu cobol using automake was that the headers were in conflict about how to link the libraries. As I recall the headers were set up to use the DLL linkage (and this is what you used in the IDE) but the automake scripts tried to link statically. This resulted in crashing programs...

I'm temporarily off working on libcxx sigh... hopefully we can get that wrapped up soon and I get can back to all the other stuff that has been put on hold...

GitMensch commented 5 years ago

Note: (to have the information in one place): to prevent nearly every test from failing because of an unexpected warning message: adjust config.h after running configure and comment #define HAVE_ATTRIBUTE_ALIGNED 1 (or even better: implement this attribute :-)

As I recall the headers were set up to use the DLL linkage (and this is what you used in the IDE) but the automake scripts tried to link statically. This resulted in crashing programs...

Yes, this was the point. Rechecked: that's what the auto* calls: olib -! .libs/libcob.lib .libs/common.o .libs/move.o .libs/numeric.o .libs/strings.o .libs/fileio.o .libs/call.o .libs/intrinsic.o .libs/termio.o .libs/screenio.o .libs/reportio.o .libs/cobgetopt.o .libs/mlio.o - so it still creates a static library (because it does not know enough about OrangeC and assumes it cannot link correctly).

Do you see any option to provide an error message instead of a stacktrace in the case of "bad linking"?

As a workaround: This may be adjusted by building the libcob directory first, then cd there and manually do: occ -! -o.libs/libcob.dll .libs/common.o .libs/move.o .libs/numeric.o .libs/strings.o .libs/fileio.o .libs/call.o .libs/intrinsic.o .libs/termio.o .libs/screenio.o .libs/reportio.o .libs/cobgetopt.o .libs/mlio.o -lvbisam -lcjson -lgmp -lpdcurses -L/c/Users/simon/Desktop/dev_desktop/code/build_occ -Wd && mv .libs/libcob.l .libs/libcob.lib

This leads to the compiled executables not returning a stack trace on each invocation leading to the next issue that the libtool wrapper executables (cobc/cobc.exe, which should call the "real" executable cobc/.libs/cobc.exe) don't work at all. By compiling the wrapper with occ +v .libs/lt-cobc.c -o cobc.exe -Wc -DLT_DEBUGWRAPPER and comparing the result with a "normal MinGW+GCC" build I've found that the generation of the cobc_ltshwrapper/cobcrun_ltshwrapper script is the actual difference, it prefixes the tool called with lt- but the binary is still generated without - so it isn't found by the wrapper and the wrapper just exists with a fatal status. This leaves us with another manual thing to do: cp cobc/.libs/cobc.exe cobc/.libs/lt-cobc.exe && bin/.libs/cobcrun.exe bin/.libs/lt-cobcrun.exe... (or adjusting the define TARGET_PROGRAM_NAME in the two C wrapper sources).

Also seen again: when we reconfigure then the libtool script is recreated and needs a change (to not run bad commands):

-old_archive_cmds="lib -OUT:\$oldlib\$oldobjs\$old_deplibs"
+old_archive_cmds="olib -! \"\$oldlib\$oldobjs\$old_deplibs\""

I'll stop testing the version generated on MinGW with the configure script and auto* for now...

LADSoft commented 5 years ago

I think the 'bad linking' problem is meant to be addressed in #352

GitMensch commented 5 years ago

I think the 'bad linking' problem is meant to be addressed in #352

If you fix both when checking the issue - fine. The mentioned issue was about what looks like an "endless cpu-friendly loop on initialization" while the "bad linking" I've referenced here was directly resulting in a stack trace as soon as the application is started.

LADSoft commented 5 years ago

yeah my response to #352 was going to be to add the diagnostic so that we know in advance of running the program if there is some sort of problem with the definitions... I think it would really be a performance hit to try to diagnose bad linkage of this form at run-time???? I suppose we would have to bracket every call in the program with some sort of cookie and then see if it is in the expected place when the call returns... but the call might not return either...

bencz commented 5 years ago

@GitMensch have you tried compiling GnuCobol using OCC-IL?

GitMensch commented 5 years ago

@GitMensch have you tried compiling GnuCobol using OCC-IL?

That was the plan but I've not came this far yet... Do you want to give it a try and report here?

LADSoft commented 4 years ago

here is the current results of 'omake check' today. I was amazed when it actually passed one of the 'run' checks...

## ------------- ##
## Test results. ##
## ------------- ##

ERROR: 895 tests were run,
577 failed (10 expected failures).
6 tests were skipped.
LADSoft commented 4 years ago

@GitMensch, was wondering if the results (above) were significantly different than what you had done in the past?

GitMensch commented 4 years ago

Yes, the results were much better. If you add testsuite.log we can have a look for things that occur again and again.

LADSoft commented 4 years ago

thanks...

I took a look at it... there are some newly introduced problems with declspec(dllexport) and also a change I made broke compatibility between the test suite and oimplib.exe. I feel that fixing these issues will possibly improve the situation dramatically.

Let me fix those over the weekend and retest and I'll get back to you...

LADSoft commented 4 years ago

so I think occ is ok... I think I messed up when modifying cobc.c and it wasn't building DLLs properly for the cobol programs.

Hard to test though; if I compile cobc statically I run into a problem because cobcrun doesn't work properly if compiled statically (presumably because it needs to be linked dynamically against libcob.dll to share the same runtime state the program has if it is to work) and if I compile cobc dynamically there is a conflict because libcob.lib (which is the object data not the import declarations) is being dragged into the cobc.exe compile, which causes conflicts between libcob.lib and the libcob.dll.

Can I work through this somehow without massive rewrites on my end?

LADSoft commented 4 years ago

ok i figured out the trick to make it compile (with more handholding of course). And it was much better in terms of passing tests. It got through the runtime tests up to about 615 where it started testing file I/O and started failing... After a few hours scratching my head why the file tests were failing I figured out there is test code in the occ runtime library 'lock' functions that prints to the console and after fixing that at least some of the file tests passed. Right now I'm trying to get past #631, it locks up when running it sigh.

GitMensch commented 4 years ago

Sounds like a good progress and also like this is useful to verifying your split work. As I have not the old testsuite in mind I suggest you set it up again using the current dev tarball [going with 3.1-dev for the moment] and drop the testsuite.log here. Having a look at testsuite.log will show issues like debug output quite soon. If you have an issue with a single test you may skip it with omake check TESTSUITEFLAGS="--list" to get the max number, then issue omake check TESTSUITEFLAGS="1-614 616-maxnum"`.

LADSoft commented 4 years ago

thank you for fixing the dev branch for mostly working with Orange C. I was able to build and at least try to run the tests and overall it was much easier than before.

there was a small problem in bin/makefile:

COBCRUN = "$(top_builddir)/pre-inst-env" cobcrun$(EXEEXT) collided with top-level quotes when running help2man. I had luck just changing the double quotes to single quotes.

There is also some problem with the cobc and bin directories but I don't know if it is your problem or mine; the executables in those directories don't do anything and I have to copy the version out of the corresponding .libs directory to be able to test.

Then there is some problem with the declspec(align(8)) in prog.c.l.h causing a warning from OCC which is probably causing most tests to fail; I will see if I can implement that declspec option :smile:

as of earlier today I was having problems with libcob and indexed databases; EOF wouldn't be detected properly. I'm presuming this is due to a change I made to the OCC runtime library at some point... I will work on this as soon as I get the tests running again... then we'll see where we are...

Thanks by the way for the TESTSUITEFLAGS comment that will help a lot :smile:

LADSoft commented 4 years ago

much better...

## ------------- ##
## Test results. ##
## ------------- ##

ERROR: 998 tests were run,
5 passed unexpectedly,
33 failed (23 expected failures).
18 tests were skipped.

my problem with the indexed files was that VBISAM.H didn't know about ORANGEC....

there are still a few failures with indexed files but in a different place. testsuite.log

GitMensch commented 4 years ago

thank you for fixing the dev branch for mostly working with Orange C. I was able to build and at least try to run the tests and overall it was much easier than before.

Good to finally know that the effort I did some months a go worked out :-)

there was a small problem in bin/makefile:

Thank you for mentioning it, the "early-dev" version already looks different and I hope to find the time to merge those changes to "dev", maybe today. I'll drop a note when this is done.

There is also some problem with the cobc and bin directories but I don't know if it is your problem or mine; the executables in those directories don't do anything and I have to copy the version out of the corresponding .libs directory to be able to test.

I think this comes down to a problem in OrangeC. Those libtool generated executables are a wrapper that setup the environment and then run the real executable, it would be good if you could debug running those and see where strange things happen.

my problem with the indexed files was that VBISAM.H didn't know about ORANGEC....

Sounds like you have a patch to share, don't you?

Just to know this - did you used msvc built' libraries and just converted the import libraries or did you actually created any of those dependencies with OrangeC itself? Note: I suggest to include cJSON - it will be statically included within libcob if you place cJSON.c and cJSON.h into the libcob folder before running configure.

5 passed unexpectedly, 33 failed (23 expected failures).

That's much better than any previous test run I did - congrats to making OrangeC definitely a better environment for complex projects in the last years!

The assembler part seems to have a new issue (failing test # 5), if I remember correct the test # 660 never worked with OrangeC but with every other compiler (but to fix this we'd likely need a more complicated debug run of this test).

Failing test # 734 seems to be a bad warning in the linker which I think was solved before (definition of not function neither used nor declared).

Those unexpected pass with vbisam look strange, but we should ignore them for now; similar for failing indexed tests, they are not unlikely to be errors in this version of GnuCOBOL, combined with the VBISAM version used.

LADSoft commented 4 years ago

I think this comes down to a problem in OrangeC. Those libtool generated executables are a wrapper that setup the environment and then run the real executable, it would be good if you could debug running those and see where strange things happen.

ok i'll look at it...

my problem with the indexed files was that VBISAM.H didn't know about ORANGEC....

Sounds like you have a patch to share, don't you?

not sure what to do with it

Just to know this - did you used msvc built' libraries and just converted the import libraries or did you actually created any of those dependencies with OrangeC itself?

at this point I wanted to keep it simple, so, out of the box dlls. I definitely want to replace the DLLs with the orange-c built ones to see what happens though...

I'm building MPFR right now, got it to run the tests for me but having problems. The latest was that there are bugs in MPFR if you don't include one of the HAVE_*_IEEEE_FLOAT flags... whenever it rebuilds I'll try it again lol...

Note: I suggest to include cJSON - it will be statically included witIhin libcob if you place cJSON.c and cJSON.h into the libcob folder before running configure.

ok will look at that

That's much better than any previous test run I did - congrats to making OrangeC definitely a better environment for complex projects in the last years!

thank you. The stuff you've thrown at me has really helped!

The assembler part seems to have a new issue (failing test # 5), if I remember correct the test # 660 never worked with OrangeC but with every other compiler (but to fix this we'd likely need a more complicated debug run of this test).

Failing test # 734 seems to be a bad warning in the linker which I think was solved before (definition of not function neither used nor declared).

will look at it later!

LADSoft commented 4 years ago

on the wrapper program problem, it was trying to run .libs/lt-cobc.exe Apparently I needed no-fast-install when running the config script to choose cobc.exe? Would that cause other problems? Anyway I modified libtool to use cobc.exe and it started working.

on #660, theoretically setting COBPRINTER or one of the other related defines for the printer should have pumped the data to a file. I couldn't get that to work though. It always wanted to put printer output on the console, but i don't know if that is because the console got opened for the printer or if the else state in cob_display was being activated.

Is there possibly a default file # for printers that cobc is using here, seems like I remember that from MSDOS? OCC doesn't support defaults beyond the first three file ids.

I'll fix #5 and #734.

LADSoft commented 4 years ago

so apparently when you add json the DLL breaks... hopefully all it is is that dlpe seems to have gotten the headers wrong when writing the DLL... really hope I don't have to write the compact version of the import table like the microsoft tools do... will try to fix it later.

LADSoft commented 4 years ago

@GitMensch

I fixed the problem linking with cJSON.

meanwhile I figured out where to find the latest libvbisam.dll and it seems you are in the process of getting a new version released? So I made a patch file with the change for Orange C, if you want it let me know where to submit it to.

this was good a bunch of bugs were fixed but I think I need to get back to #297 again now lol!

GitMensch commented 4 years ago

I figured out where to find the latest libvbisam.dll

the main issue is that there isn't really an official version of this library...

it seems you are in the process of getting a new version released?

I want to do this since years keeping different patches and important features under an official umbrella - it looks like I'll be able to do this somewhere in the second half of this year [the official source tree will be converted from CVS (@ SourceForge) to Git (likely with temporarily being in a local svn repo) which will be then registered as project on GitLab].

So I made a patch file with the change for Orange C, if you want it let me know where to submit it to.

I suggest to just send me a patchfile and I'll come back to this when I work on VB-ISAM.

Concerning GnuCOBOL you may have a try to use BDB instead of VB-ISAM (especially when you try to compile, link and maybe even make it with OrangeC). BDB features its own testsuite which may also highlights some things for OrangeC...

LADSoft commented 4 years ago

I figured out where to find the latest libvbisam.dll

the main issue is that there isn't really an official version of this library...

yeah I had to drag it out of your RC1 binaries lol!

Concerning GnuCOBOL you may have a try to use BDB instead of VB-ISAM (especially when you try >to compile, link and maybe even make it with OrangeC). BDB features its own testsuite which may >also highlights some things for OrangeC...

I'll leave this issue open so I remember to get back to it... eventually... next time I work on autoconfig projects I'm trying to clean up MPFR build...

GitMensch commented 3 years ago

Current "building recipe", needs any posix environment (msys/msys2/cygwin should work):

first time only:

For tests: