Compiling a PM sample with GCC (2023)

[Lars]

you can pick a different output name:

template.res: main.rc .....
   wrc -q main.rc template.res

That would spare the additional file copy/rename.

[Dave Yeo]

Missed that, tried

Code: [Select]

-fo=name        - set the output resource file to namewhich seemed right but didn't work as expected.

wipfc seems to have a problem with importing ipf files.
This works as expected,

Code: [Select]

template.hlp: $(ALL_IPF)
        ipfc template.ipf -o template.hlp
Can't get it to correctly import the ipf's with wipfc, lots of warnings and the help only shows the help for file, so it imports the first import and no more. Documentation is lacking

[Martin Iturbide]

Thanks Dave, Lars

I changed the makefile (file attached) with the procedure and it works. I removed the gcc warnings.

Just these thing:
 1)

template.res: main.rc .....
   wrc -q main.rc template.res

Did not work for me, not sure exactly what else to change. 

2) wipfc also gave me the same issue..

Regards

[Martin Iturbide]

Hello

About generating the HLP file, I was trying to get the most lazy way to update the IPF file so I can remove the warnings on wipfc.

Using "dlg.ipf", from the "Template sample", I imported it to VyperHelp (Open source) and exported it again as .IPF (like dlg2.ipf).

Check the difference picture attached. There are some interesting difference like it does not uses "name" and change it for "id"

If I run:
- wipfc dlg.ipf -o dlg.hlp
I get a lot of warnings and an error.

And running:
- wipfc dlg2.ipf -o dlg2.hlp
It works fine, no warnings, and generate the dlg2.hlp file.

Is there an old IPF format and newer one?

Regards

[Martin Iturbide]

Hello

Here goes a funky one, the InkPS sample, it compiles, it works:

I got this warnings.

gcc -Wall -Zomf -c -O2 inkps.c -o inkps.obj
inkps.c: In function 'ClientWndProc':
inkps.c:244:35: warning: cast from pointer to integer of different size [-Wpoint
er-to-int-cast]
  244 |              newptlCur.x = (LONG) (SHORT) mp1;
      |                                   ^
inkps.c:292:35: warning: cast from pointer to integer of different size [-Wpoint
er-to-int-cast]
  292 |              newptlCur.x = (LONG) (SHORT) mp1;
      |                                   ^

If I fix it to "newptlCur.x = (LONG) mp1;"
The warnings are gone, the app will run, but the drawing mouse the area will not work.

Regards

[Dave Yeo]

This seems to work.

Code: [Select]

--- inkps.c.orig        2023-06-28 14:54:38.000000000 -0700
+++ inkps.c     2023-06-28 16:14:56.000000000 -0700
@@ -241,7 +241,7 @@

              fButton1 = TRUE;

-             newptlCur.x = (LONG) (SHORT) mp1;
+             newptlCur.x = (SHORT) (LONG) mp1;

              newptlCur.y = (LONG) (SHORT) ((LONG) mp1 >> 16);

@@ -289,7 +289,7 @@
       case WM_MOUSEMOVE:
          if ( fButton1 && fInPath )
          {
-             newptlCur.x = (LONG) (SHORT) mp1;
+             newptlCur.x = (SHORT) (LONG) mp1;

              newptlCur.y = (LONG) (SHORT) ((LONG) mp1 >> 16);

I'm not sure how casts actually work in C but it seems to me to be better to cast to a bigger variable, like SHORT to LONG then the other way where things might get truncated. Or in this case where the pointer is 32 bit, to cast to LONG, which IIRC is 32 bit whereas a SHORT is 16 bit and can't hold the whole pointer and gets truncated, high bits removed I assume.
Looking at the assembler output, my fix has the same assembler output as the original that GCC complained about. Your fix, were the mouse pointer stopped working resulted in somewhat different assembler output, here's the diff (attached) where inkps.new.S is the same as the original but with my patch and inkps.martin.S is your fix that broke the mouse.
Add -S to CFLAGS to get the assembly and change the name of the output if desired

[Martin Iturbide]

Thanks Dave

The warnings are gone and the sample keeps working fine:
- https://github.com/OS2World/DEV-SAMPLES-C-PM-InkPS

I don't understand Assembly, but I didn't know you can produce that with gcc, good to know that. I will check to see what I can learn.

I also posted:
- https://github.com/OS2World/DEV-SAMPLES-C-PM-Template
- https://github.com/OS2World/DEV-SAMPLES-C-PM-DIVE-BeeHive

Thanks for your help.

[Dave Yeo]

Generally, C compilers create assembly and then assemble it, using as.exe in the case of GCC. Another handy thing is seeing the preprocessor output (cpp.exe), using -E, helps sometimes to see things like the include files or macro expansions.

[Dave Yeo]

Another problem is the use of C_INCLUDE_PATH in compile.cmd, after running it a few times,

Code: [Select]

[H:\tmp\inkps_b1]set C_INCLUDE_PATH
C_INCLUDE_PATH=W:/usr/include;W:\usr\include\os2tk45\inc;W:\usr\include\os2tk45\
gl;W:\usr\include\os2tk45;W:/usr/include;W:\usr\include\os2tk45\inc;W:\usr\inclu
de\os2tk45\gl;W:\usr\include\os2tk45;W:/usr/include;W:\usr\include\os2tk45\inc;W
:\usr\include\os2tk45\gl;W:\usr\include\os2tk45;W:/usr/include;W:\usr\include\os
2tk45\inc;W:\usr\include\os2tk45\gl;W:\usr\include\os2tk45;

Could remove the %C_INCLUDE_PATH% from the end but it is good practice to have it there. Could have a gccenv.cmd or such that is only run once and has the various SET commands. Or something like this,

Code: [Select]

--- makefile.orig       2023-06-28 19:35:40.000000000 -0700
+++ makefile    2023-06-28 19:45:14.000000000 -0700
@@ -11,7 +11,8 @@
        wrc inkps.res

 inkps.obj : inkps.c inkps.h
-       gcc -Wall -Zomf -c -O2 inkps.c -o inkps.obj
+       gcc -Wall -Zomf -c -O2 -I/@unixroot/usr/include \
+           -I/@unixroot/usr/include/os2tk45 inkps.c -o inkps.obj

 inkps.res : inkps.rc
        wrc -r inkps.rc

So the makefile works standalone. The -I is the include search path and need to search usr/include first to avoid picking wrong include files, things break using the toolkits stdlib.h and such.  The \ is a line continues thing to make it more readable.

[Lars]

This seems to work.

Code: [Select]

--- inkps.c.orig        2023-06-28 14:54:38.000000000 -0700
+++ inkps.c     2023-06-28 16:14:56.000000000 -0700
@@ -241,7 +241,7 @@

              fButton1 = TRUE;

-             newptlCur.x = (LONG) (SHORT) mp1;
+             newptlCur.x = (SHORT) (LONG) mp1;

              newptlCur.y = (LONG) (SHORT) ((LONG) mp1 >> 16);

@@ -289,7 +289,7 @@
       case WM_MOUSEMOVE:
          if ( fButton1 && fInPath )
          {
-             newptlCur.x = (LONG) (SHORT) mp1;
+             newptlCur.x = (SHORT) (LONG) mp1;

              newptlCur.y = (LONG) (SHORT) ((LONG) mp1 >> 16);

I'm not sure how casts actually work in C but it seems to me to be better to cast to a bigger variable, like SHORT to LONG then the other way where things might get truncated. Or in this case where the pointer is 32 bit, to cast to LONG, which IIRC is 32 bit whereas a SHORT is 16 bit and can't hold the whole pointer and gets truncated, high bits removed I assume.
Looking at the assembler output, my fix has the same assembler output as the original that GCC complained about. Your fix, were the mouse pointer stopped working resulted in somewhat different assembler output, here's the diff (attached) where inkps.new.S is the same as the original but with my patch and inkps.martin.S is your fix that broke the mouse.
Add -S to CFLAGS to get the assembly and change the name of the output if desired

Unfortunately, the handling of message WM_BUTTON1DOWN (as all the other WM_BUTTON... and WM_MOUSE... messages) is a bit convoluted as it did not go through "the shift from 16-bit to 32-bit".

And therefore:

POINTL newptlCur;
....
newptrlCur.x = (SHORT)SHORT1FROMMP(mp1);
newptlCur.y = (SHORT)SHORT2FROMMP(mp1);

The additional cast to (SHORT) is necessary because Dmitry Kuminov already found out that the SHORTnFROMMP macros do not properly cast the value to the signed type, that's why you have to do it.
The additional cast from SHORT to LONG should not be necessary as it is always ok to cast to a bigger type (unless you changed signedness !).

That's basically equivalent to what David has been doing but using the Macros gives a better clue of what you are actually accessing. They also properly cast from a pointer to an integer value (and therefore will avoid the gcc pointer cast warning).

Likewise for all the other WM_BUTTON... and WM_MOUSE.... messages.

[Martin Iturbide]

Thanks for the corrections on InkPS. It is still working fine.

I followed Lars' advice with:
 newptrlCur.x = (SHORT)SHORT1FROMMP(mp1);
 newptlCur.y = (SHORT)SHORT2FROMMP(mp1);

Works fine with no warnings.

And Dave, you are right that sometime the INCLUDES on compile.cmd gave me problems on the CMD session. I didn't know that you can add the "INCLUDE" on the gcc calls, good learning for me.

I tried to use some variables on the makefile like:

# make makefile
#
# Tools used:
#  Compile::Resource Compiler
#  Compile::GNU C
#  Make: make

CFLAGS=-Wall -Zomf -c -O2
DEBUGFLAGS=-g
INC=-I/@unixroot/usr/include -I/@unixroot/usr/include/os2tk45

all : inkps.exe

inkps.exe : inkps.obj inkps.def inkps.res
   gcc -Zomf inkps.obj inkps.def inkps.res -o inkps.exe
   wrc inkps.res

inkps.obj : inkps.c inkps.h
   gcc $(CFLAGS) $(INC) inkps.c -o inkps.obj

inkps.res : inkps.rc
   wrc -r inkps.rc

clean :
   rm -rf *exe *res *obj *lib

Regards

[Dave Yeo]

Good, it is nice that running make standalone works. Could also do it this way, both work.

Code: [Select]

--- makefile.orig       2023-06-30 19:38:02.000000000 -0700
+++ makefile    2023-06-30 19:44:36.000000000 -0700
@@ -8,6 +8,7 @@
 CFLAGS=-Wall -Zomf -c -O2
 DEBUGFLAGS=-g
 INC=-I/@unixroot/usr/include -I/@unixroot/usr/include/os2tk45
+CFLAGS += $(INC)

 all : inkps.exe

@@ -16,7 +17,7 @@
        wrc inkps.res

 inkps.obj : inkps.c inkps.h
-       gcc $(CFLAGS) $(INC) inkps.c -o inkps.obj
+       gcc $(CFLAGS) inkps.c -o inkps.obj

 inkps.res : inkps.rc
        wrc -r inkps.rc

Also see that DEBUGFLAGS is unused. Should be able to do "make debug" to get a debug version. This works.

Code: [Select]

--- makefile.orig       2023-06-30 19:38:02.000000000 -0700
+++ makefile    2023-06-30 19:41:08.000000000 -0700
@@ -6,11 +6,15 @@
 #  Make: make

 CFLAGS=-Wall -Zomf -c -O2
-DEBUGFLAGS=-g
+DEBUGFLAGS=-g -Og
 INC=-I/@unixroot/usr/include -I/@unixroot/usr/include/os2tk45

 all : inkps.exe

+debug : CFLAGS += $(DEBUGFLAGS)
+
+debug : inkps.obj inkps.exe
+
 inkps.exe : inkps.obj inkps.def inkps.res
        gcc -Zomf inkps.obj inkps.def inkps.res -o inkps.exe
        wrc inkps.res

GCC uses the last optimization flag on the command line, -Og for "make debug". -Og optimizes in a debugger friendly way.

[Martin Iturbide]

Hi

This is a very basic question that I don't know. When you compile it as "make debug", does the exe file generate some kind of debug log? where is it stored?

Regards

[Dave Yeo]

Hi

This is a very basic question that I don't know. When you compile it as "make debug", does the exe file generate some kind of debug log? where is it stored?

Regards

It defaults to being stored in the binary, unless stripped. Lxlite is a good stripper,

Code: [Select]

H:\tmp\inkps_b2>lxlite inkps.exe
┌[ lxLite ]───────────────────────────────────┬[ Version 1.3.9 ]┐
├ Copyright 1996,97 by FRIENDS software       ├    All rights   ┤
├ Copyright 2001,03 by Max Alekseyev          ├     reserved    ┤
├ Copyright 2008-10 by OS/4 team              ├                 ┤
├ Copyright 2011    by Steven H. Levine       ├                 ┤
├ Copyright 2017-23 by bww bitwise works GmbH └─────────────────┘
├ The file inkps.exe contains 9992 bytes of debug information
├                   inkps.exe initial: 23213 final: 6054 gain: 74.0%
├┤Total gain: 17159 bytes

It is possible to have a separate debug file, means messing with the linker cmd line. Need to remember how.
Generally there is no need for the debug version unless someone wants to use a debugger or if getting trps, the debug data makes the trps more informative.
Not sure why we hardly ever get trps, perhaps the PM exception handler gets first dibs when an exception happens.

[Dave Yeo]

OK, the symfile option is one way to do it, I think it only works with wlink and needs to invoked on the link command like this,

Code: [Select]

-Zlinker "option symfile=inkps.dbg"

A little harder to make it work with "make debug", more variables like this seems to work,

Code: [Select]

--- makefile.orig 2023-06-30 19:38:02.000000000 -0700
+++ makefile 2023-07-02 21:24:22.000000000 -0700
@@ -5,14 +5,24 @@
 #  Compile::GNU C
 #  Make: make
 
+EXEEXT=.exe
+PRGNAME=inkps
 CFLAGS=-Wall -Zomf -c -O2
-DEBUGFLAGS=-g
+LDFLAGS=-Zomf
+DEBUGCFLAGS=-g -Og
+DEBUGLDFLAGS=-Zlinker "option symfile=$(PRGNAME).dbg"
 INC=-I/@unixroot/usr/include -I/@unixroot/usr/include/os2tk45
 
-all : inkps.exe
+all : $(PRGNAME)$(EXEEXT)
 
-inkps.exe : inkps.obj inkps.def inkps.res
- gcc -Zomf inkps.obj inkps.def inkps.res -o inkps.exe
+debug : CFLAGS += $(DEBUGCFLAGS)
+
+debug : LDFLAGS += $(DEBUGLDFLAGS)
+
+debug : inkps.obj $(PRGNAME)$(EXEEXT)
+
+$(PRGNAME)$(EXEEXT) : inkps.obj inkps.def inkps.res
+ gcc $(LDFLAGS) inkps.obj inkps.def inkps.res -o $(PRGNAME)$(EXEEXT)
  wrc inkps.res
 
 inkps.obj : inkps.c inkps.h
@@ -22,4 +32,4 @@
  wrc -r inkps.rc
 
 clean :
- rm -rf *exe *res *obj *lib
\ No newline at end of file
+ rm -rf *exe *res *obj *lib *dbg


Seems simpler for these simple programs to leave the debug stuff in the binary