Closed ghost closed 1 year ago
Do you get a different result (for example actual crash report output) when adding -g
?
In any case it seems that you need to link to some libraries which your manual invocation doesn't do. You may want to generate import libraries from the matching DLLs using oimplib, then re-compile with linking those and retest running then.
Note: when working with makefiles you commonly can use omake CC=occ
(possible more, depending on the Makefile)
Do you get a different result (for example actual crash report output) when adding
-g
?
No.
In any case it seems that you need to link to some libraries which your manual invocation doesn't do. You may want to generate import libraries from the matching DLLs using oimplib, then re-compile with linking those and retest running then.
occ compiled without any errors. If there are symbols not resolved (missing libraries), it should report to me.
Note: when working with makefiles you commonly can use
omake CC=occ
(possible more, depending on the Makefile)
Crashed. Access Violation and Stack trace printed. This program is full of bugs. Better use msys2 make.
thank you for the reports... we've had a couple of omake crashes (one of which I couldn't duplicate) so maybe now I can finally fix it... I'll look at this later on today...
@hgntn
still can't get omake to crash - what OS are you on? OS Version? Command shell?
Thanks
@hgntn
still can't get omake to crash - what OS are you on? OS Version? Command shell?
Thanks
This thread is about the program compiled by occ, it crashed when running, not omake.
I've already fixed a problem with the program crashing, unaligned WCHAR was bad for windows API... there was another issue though in that I had to use -DWRITE_REFERENCE to get it to rewrite reference.png (the version in the release didn't work for some reason)
Anyway in the first box you also said:
' But omake crashed for no reasons. '
I've had a number of reports of omake crashing but I can never duplicate it, and I'm very interested in fixing this, so I was wondering what OS and version of the OS you are using?
I've already fixed a problem with the program crashing, unaligned WCHAR was bad for windows API... there was another issue though in that I had to use -DWRITE_REFERENCE to get it to rewrite reference.png (the version in the release didn't work for some reason)
So hello.exe no longer crash now?
Anyway in the first box you also said:
' But omake crashed for no reasons. '
I've had a number of reports of omake crashing but I can never duplicate it, and I'm very interested in fixing this, so I was wondering what OS and version of the OS you are using?
Also Windows 8.1 64 bit like @tn1997tn with Command Prompt shell, an additional information is I have not updated Windows since I bought this PC (I disabled Windows Updates).
yeah hello.exe doesn't crash any more. CI.EXE does crash a long way in after opening tons of windows and even going fullscreen, but it seemed like gcc also had problems with that so I didn't look too closely.
The compiler doesn't compile right now. I will try to get it fixed tomorrow night and push what I've got so far. Not having much luck with omake, made a couple of improvements but nothing that would make a difference unless you happend to be using
omake -j 0
as that crashes in the current version... but that is nonsensical anyway
I pushed a new version, it will take a while to build...
Steps to reproduce:
Clone https://github.com/erkkah/tigr and go to examples/hello, compile it using this command:
occ -I../.. hello.c ../../tigr.c -o hello
It compiled without errors but when I run
hello.exe
it crashed immediately on my system. The program compiled by gcc works as expected.Note: first I tried to edit Makefile, replacing gcc with occ and use omake. But omake crashed for no reasons. I tried msys2 make. Msys2 make worked but occ failed:
Then I realized I will have more luck running occ directly.
Update: first have to edit tigr.c at line 2733 (I'm using the bugfixes branch) to comment out
#import <Cocoa/Cocoa.h>
due to https://github.com/LADSoft/OrangeC/issues/798