Author Topic: Compiling a PM sample with GCC (2023)  (Read 97085 times)

Lars

  • Hero Member
  • *****
  • Posts: 1277
  • Karma: +65/-0
    • View Profile
Re: Compiling a PM sample with GCC (2023)
« Reply #210 on: June 23, 2023, 06:37:49 am »
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

  • Hero Member
  • *****
  • Posts: 4811
  • Karma: +101/-1
    • View Profile
Re: Compiling a PM sample with GCC (2023)
« Reply #211 on: June 23, 2023, 06:52:40 am »
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

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4756
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Compiling a PM sample with GCC (2023)
« Reply #212 on: June 23, 2023, 06:22:05 pm »
Thanks Dave, Lars

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

Just these thing:
 1)
Quote
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
« Last Edit: June 23, 2023, 06:24:23 pm by Martin Iturbide »
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4756
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Compiling a PM sample with GCC (2023)
« Reply #213 on: June 23, 2023, 06:55:54 pm »
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

« Last Edit: June 23, 2023, 07:28:01 pm by Martin Iturbide »
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4756
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Compiling a PM sample with GCC (2023)
« Reply #214 on: June 28, 2023, 11:58:55 pm »
Hello

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

I got this warnings.
Quote
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
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4811
  • Karma: +101/-1
    • View Profile
Re: Compiling a PM sample with GCC (2023)
« Reply #215 on: June 29, 2023, 01:38:22 am »
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

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4756
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Compiling a PM sample with GCC (2023)
« Reply #216 on: June 29, 2023, 03:27:34 am »
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.
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4811
  • Karma: +101/-1
    • View Profile
Re: Compiling a PM sample with GCC (2023)
« Reply #217 on: June 29, 2023, 04:26:40 am »
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

  • Hero Member
  • *****
  • Posts: 4811
  • Karma: +101/-1
    • View Profile
Re: Compiling a PM sample with GCC (2023)
« Reply #218 on: June 29, 2023, 04:49:19 am »
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

  • Hero Member
  • *****
  • Posts: 1277
  • Karma: +65/-0
    • View Profile
Re: Compiling a PM sample with GCC (2023)
« Reply #219 on: June 29, 2023, 03:25:50 pm »
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.

« Last Edit: June 29, 2023, 03:51:22 pm by Lars »

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4756
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Compiling a PM sample with GCC (2023)
« Reply #220 on: June 30, 2023, 10:05:06 pm »
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:
Quote
# 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
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4811
  • Karma: +101/-1
    • View Profile
Re: Compiling a PM sample with GCC (2023)
« Reply #221 on: July 01, 2023, 04:51:03 am »
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

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4756
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Compiling a PM sample with GCC (2023)
« Reply #222 on: July 03, 2023, 04:47:58 am »
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
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4811
  • Karma: +101/-1
    • View Profile
Re: Compiling a PM sample with GCC (2023)
« Reply #223 on: July 03, 2023, 05:25:14 am »
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

  • Hero Member
  • *****
  • Posts: 4811
  • Karma: +101/-1
    • View Profile
Re: Compiling a PM sample with GCC (2023)
« Reply #224 on: July 03, 2023, 06:26:21 am »
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