Only short exceptq report although .xqs file was there, why?

[Andi B.]

Thanks for explanation. Have to test.

Usually I use makefiles and gcc -c (compile only) and link with whatever I choose in the makefile. Something like -

Code: [Select]

cc = gcc
link = wlink
.
.
$(cc) $(objs) ....
$(link) .....

[Lars]

... and in that case you will need to specify -Zomf as a compiler switch because there is nothing massaging this switch into the linker ...

[Dave Yeo]

Thanks for explanation. Have to test.

Usually I use makefiles and gcc -c (compile only) and link with whatever I choose in the makefile. Something like -

Code: [Select]

cc = gcc
link = wlink
.
.
$(cc) $(objs) ....
$(link) .....

Interesting, guess you'd use the OW crt files then, creating an OW binary. As Lars mentioned, did you use -Zomf as a CFLAG? Or .obj as a suffix and GCC was smart enough to create an OMF object file. Also be hard to do things like the equivalent of -Zhigh-mem. I guess for a simple C program it would work. Perhaps part of the reason for your short exceptq report.
It'll fall down with CPLUS source where you use g++ instead of gcc (same rules for linking). When I moved to GCC 9.2.0 for building Mozilla, it was trying to call a response file from another response file, which doesn't work. Went through similar back around FF4 when the linker cmd line grew to over 64KB (32KB?) and piping the cmd line failed. Then we ended up linking directly with wl.exe, it was hard. This time I linked directly with emxomfld, 873 object files (most consisting of 15 source files) plus libraries created a long cmd line (900 odd words) and was tricky to get working. Here's the sh script I ended up with, renamed to .txt to post. Note the needed libraries.

[Andi B.]

Interesting, guess you'd use the OW crt files then, creating an OW binary. .......Perhaps part of the reason for your short exceptq report.

That's what I tried the last days. Not the problem with exceptq. The failing program (why I started this thread) was made with wcc/wlink.

Then we ended up linking directly with wl.exe, it was hard.

This is what I remember. I thought it would be a good choice cause it worked with Mozilla. But now it seems it's not. Beside the topic of this thread - which compiler/linker combination allows debugging with idebug?

Now I think I've to try again gcc for compiling and linking.

Edit: Okay, this works. At least with a short test

Code: [Select]

gcc -lcx -O0 -Wall -Wextra -c -Ie:\c\include -Zomf -g -D__DEBUG__ -D__DEBUG_PMPRINTF__ main.c -o main.obj
gcc -lcx -Zexe -Zomf -Zmap -g -g main.obj  -Lpmprintf.lib
Source level debugging with idebug works. exceptq report is generated and seems fine. Guess -lcx is only needed during linking and I can remove it from CFLAGS.

[Dave Yeo]

This is what I remember. I thought it would be a good choice cause it worked with Mozilla. But now it seems it's not. Beside the topic of this thread - which compiler/linker combination allows debugging with idebug?

Basically LDFLAGS=-g -Zomf. All the OS/2 linkers should work, the usual is wl.exe as we have the source. We stopped using ilink for Mozilla as it couldn't handle the code size, IIRC the limit was 32 MB

Now I think I've to try again gcc for compiling and linking.

Should be fine. Linking against libcx will give exceptq support, LDFLAGS+=-lcx, -Zmap for map files.