OS/2, eCS & ArcaOS - Technical > Programming

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

<< < (4/4)

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: ---cc = gcc
link = wlink
.
.
$(cc) $(objs) ....
$(link) .....
--- End code ---

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:

--- Quote from: Andi B. on January 24, 2022, 09:56:32 am ---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: ---cc = gcc
link = wlink
.
.
$(cc) $(objs) ....
$(link) .....
--- End code ---

--- End quote ---

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.:

--- Quote from: Dave Yeo on January 24, 2022, 07:15:22 pm ---Interesting, guess you'd use the OW crt files then, creating an OW binary. .......Perhaps part of the reason for your short exceptq report.

--- End quote ---
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.


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

--- End quote ---
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: ---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
--- End code ---

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:

--- Quote from: Andi B. on January 24, 2022, 09:16:42 pm ---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?

--- End quote ---

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


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

--- End quote ---

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

Navigation

[0] Message Index

[*] Previous page

Go to full version