Compiling a PM sample with GCC (2023)

[Andi B.]

IMO for a most simple programs it's not worth to make a non-debug build. The difference in file size is often not worth thinking to remove debug stuff. During development you usually want to have debugging information. Of course when you fire up a debugger and want to do source code debugging. But even in release program versions it's often helpful to have debugging data to some extend in the .exe. F.i. line numbers in conjunction with the map file can often point directly to failing code line.

Suggestions - build and ship with full debugging code (compiler and linker). Only when the exe size becomes to big or you've some very time critical parts in your program, start playing with less debug settings.

[Dave Yeo]

Interestingly, the linker doesn't seem to need -g. Based on testing and also looking at the emxomfld source where unless -s is passed, the debug format is kept. Haven't looked at how GCC calls emxomfld lately but if I remember correctly, it does not pass the -s option.

[Martin Iturbide]

Hello

I wanted to try to compile something bigger, but I think I have problems with the makefile.
https://github.com/OS2World/UTIL-FILE-NewFileManager

I get this issue:

gcc -Zomf -Zmap nfm.obj nfm.def nfm.res -o nfm.exe
weakld: error: Unresolved symbol (UNDEF) '_CSPCSTA4'.
weakld: info: The symbol is referenced by:
    C:\dev\5TRYING\UTIL-FILE-NewFileManager\nfm.obj
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _CSPCSTA4 is an undefined reference
file C:\dev\5TRYING\UTIL-FILE-NewFileManager\nfm.obj(nfm.c): undefined symbol _CSPCSTA4
make: *** [nfm.exe] Error 1

Help is appreciated to know what I'm doing wrong.

Regards

[Dave Yeo]

Hello

I wanted to try to compile something bigger, but I think I have problems with the makefile.
https://github.com/OS2World/UTIL-FILE-NewFileManager

I get this issue:

gcc -Zomf -Zmap nfm.obj nfm.def nfm.res -o nfm.exe
weakld: error: Unresolved symbol (UNDEF) '_CSPCSTA4'.
weakld: info: The symbol is referenced by:
    C:\dev\5TRYING\UTIL-FILE-NewFileManager\nfm.obj
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _CSPCSTA4 is an undefined reference
file C:\dev\5TRYING\UTIL-FILE-NewFileManager\nfm.obj(nfm.c): undefined symbol _CSPCSTA4
make: *** [nfm.exe] Error 1

Help is appreciated to know what I'm doing wrong.

Regards

Lots wrong, not linking to the DLLs, wrc options not pointing out that we're dealing with a dll are some.
Here's one solution linking against the export libs by name, could also do something like -lnfmlib etc.

Code: [Select]

--- makefile.orig 2023-07-13 22:25:30.000000000 -0700
+++ makefile 2023-07-13 22:45:26.000000000 -0700
@@ -10,13 +10,16 @@
 
 HEADERS = caoj2i03.h caoj2i04.h csoj2i0a.h csoj2i0h.h csoj2i0i.h csoj2i0j.h csoj2i0k.h csoj2i0l.h cspcsta3.h cspcsta4.h nfm.h nfmlib.h perfutil.h
 OBJS = nfm.obj nfmlib.obj csoj2i0a.obj csoj2i0k.obj csoj2i0j.obj csoj2i0h.obj caoj2i03.obj caoj2i04.obj csoj2i0i.obj cspcsta3.obj cspcsta4.obj
+LIBS = nfmlib.lib csoj2i0a.lib csoj2i0k.lib csoj2i0j.lib csoj2i0h.lib \
+       caoj2i03.lib caoj2i04.lib csoj2i0i.lib csoj2i0l.lib cspcsta4.lib \
+       cspcsta3.lib
 ALL_IPF =
 INC=-I/@unixroot/usr/include -I/@unixroot/usr/include/os2tk45
 
 all : nfm.exe
 
-nfm.exe: nfm.obj nfm.res nfm.def $(HEADERS)
- gcc -Zomf -Zmap nfm.obj nfm.def nfm.res -o $@
+nfm.exe: nfm.obj nfm.res nfm.def $(HEADERS) $(LIBS)
+ gcc -Zomf -Zmap -L. $(LIBS) nfm.obj nfm.def nfm.res -o $@
  wrc nfm.res
 
 nfm.obj: nfm.c nfm.h nfm.def $(HEADERS)
@@ -29,9 +32,9 @@
 nfmlib.obj : nfmlib.c nfmlib.h
  gcc $(CFLAGS) $(DEBUGFLAGS) $(INC) nfmlib.c -o nfmlib.obj
 
-nfmlib.dll : nfmlib.obj nfmlib.def
+nfmlib.dll : nfmlib.obj nfmlib.def nfmlib.res
  gcc -Zdll -Zomf -Zmap $(INC) nfmlib.obj nfmlib.def -o nfmlib.dll
- wrc nfmlib.res
+ wrc nfmlib.res nfmlib.dll
 
 nfmlib.lib : nfmlib.obj nfmlib.def nfmlib.dll
        $(shell emximp -o nfmlib.lib nfmlib.def)
@@ -42,9 +45,9 @@
 csoj2i0a.obj : csoj2i0a.c csoj2i0a.h
  gcc $(CFLAGS) $(DEBUGFLAGS) $(INC) csoj2i0a.c -o csoj2i0a.obj
 
-csoj2i0a.dll : csoj2i0a.obj csoj2i0a.def
- gcc -Zdll -Zomf -Zmap $(INC) csoj2i0a.obj csoj2i0a.def -o csoj2i0a.dll
- wrc csoj2i0a.res
+csoj2i0a.dll : csoj2i0a.obj csoj2i0a.def csoj2i0a.res
+ gcc -Zdll -Zomf -Zmap -lmmpm2 $(INC) csoj2i0a.obj csoj2i0a.def -o csoj2i0a.dll
+ wrc csoj2i0a.res csoj2i0a.dll
 
 csoj2i0a.lib : csoj2i0a.obj csoj2i0a.def csoj2i0a.dll
        $(shell emximp -o csoj2i0a.lib csoj2i0a.def)

Also need a leading underscore in the export in cspcsta4.def,

Code: [Select]

EXPORTS      _CSPCSTA4 @1

After this I get a working nfm.exe
ps to patch, IIRC,

Code: [Select]

%UNIXROOT%\usr\bin\patch.exe -p0 < makefile.diff
Got to avoid the patch.exe in \os2.

Edit: PS, the header and obj lines should also use a backslash to split into multiple lines like I did with the libs line to be more readable.

Code: [Select]

--- makefile.orig 2023-07-13 23:15:08.000000000 -0700
+++ makefile 2023-07-13 23:15:56.000000000 -0700
@@ -8,8 +8,10 @@
 CFLAGS=-Wall -Zomf -c -O2
 DEBUGFLAGS=-g
 
-HEADERS = caoj2i03.h caoj2i04.h csoj2i0a.h csoj2i0h.h csoj2i0i.h csoj2i0j.h csoj2i0k.h csoj2i0l.h cspcsta3.h cspcsta4.h nfm.h nfmlib.h perfutil.h
-OBJS = nfm.obj nfmlib.obj csoj2i0a.obj csoj2i0k.obj csoj2i0j.obj csoj2i0h.obj caoj2i03.obj caoj2i04.obj csoj2i0i.obj cspcsta3.obj cspcsta4.obj
+HEADERS = caoj2i03.h caoj2i04.h csoj2i0a.h csoj2i0h.h csoj2i0i.h csoj2i0j.h \
+          csoj2i0k.h csoj2i0l.h cspcsta3.h cspcsta4.h nfm.h nfmlib.h perfutil.h
+OBJS = nfm.obj nfmlib.obj csoj2i0a.obj csoj2i0k.obj csoj2i0j.obj csoj2i0h.obj \
+       caoj2i03.obj caoj2i04.obj csoj2i0i.obj cspcsta3.obj cspcsta4.obj
 LIBS = nfmlib.lib csoj2i0a.lib csoj2i0k.lib csoj2i0j.lib csoj2i0h.lib \
        caoj2i03.lib caoj2i04.lib csoj2i0i.lib csoj2i0l.lib cspcsta4.lib \
        cspcsta3.lib


[Martin Iturbide]

Thanks Dave.

I followed your instructions with the makefile , and it also compiles and works here.

But I don't understand this part:

ps to patch, IIRC,

Code: [Select]

%UNIXROOT%\usr\bin\patch.exe -p0 < makefile.diff
Got to avoid the patch.exe in \os2.

To be honest I haven't used patch.exe never, I was changing the makefile at hand.
This is to automatically make the update/changes on the makefile, right?

What is your technique to generate the changes between makefile.orig and the current makefile as you are attaching on the forum ?

Regards

[Dave Yeo]

Thanks Dave.

I followed your instructions with the makefile , and it also compiles and works here.

But I don't understand this part:

ps to patch, IIRC,

Code: [Select]

%UNIXROOT%\usr\bin\patch.exe -p0 < makefile.diff
Got to avoid the patch.exe in \os2.

To be honest I haven't used patch.exe never, I was changing the makefile at hand.
This is to automatically make the update/changes on the makefile, right?

Yes, it could also be a patch for the whole directory. Options include --dry-run, to see what will happen with no actual changes. Git format patches need -p1 instead of -p0, it is related to the depth of the subdirectory. For large patches it doesn't hurt to capture the output by redirecting stdout and stderr. If the patch fails, it will leave files like makefile.org and makefile.rej so you can revert or fix by hand.
 

What is your technique to generate the changes between makefile.orig and the current makefile as you are attaching on the forum ?

Yes, to catch the changes, something like cp makefile makefile.orig (could be makefile.bak or whatever), then after making changes,

Code: [Select]

diff -u makefile.orig makefile > makefile.patch
Can also do whole directories, cp newfilemanager/ newfilemanager.orig or such, then from above the directory,

Code: [Select]

diff -ru newfilemanager/ newfilemanager.orig/ > newfilemanager.diff
Which made a huge patch here. Make clean did not clean everything is the big problem, in both directories. There's other options such as -w to ignore white space, which IIRC includes line endings
diff --help | less to see all the options
There's also git diff, svn diff and such to create similar patches that can be applied much the same way tasking care with the -p parameter. Patch will let you know if it can't find the files to patch or ask about a reversed patch if already applied. Reversed patching undoes a patch, see the help.

[Martin Iturbide]

FYI:

I updated this two on github.

- https://github.com/OS2World/DEV-SAMPLES-C-PM-Simple
- https://github.com/OS2World/UTIL-FILE-NewFileManager

Both compiles and works with gcc. I will work slowly with NewFileManager to see if I can remove all warnings.

Regards

[Martin Iturbide]

FYI

On this I also removed the warnings, compiled with gcc and keeps working
- https://github.com/OS2World/DEV-SAMPLES-C-PM-NBBASE

Regards

[Martin Iturbide]

Hello

Now I'm with this sample:  https://github.com/OS2World/DEV-SAMPLES-C-PM-CNRMENU
Can I have some suggestion on how to fix this warnings?

Code: [Select]

gcc -Wall -Zomf -c -O2 ctxtmenu.c -o ctxtmenu.obj
ctxtmenu.c: In function 'CtxtmenuSetView':
ctxtmenu.c:375:12: warning: 'strcat' accessing 281 or more bytes at offsets 412 and 692 may overlap 1 byte at offset 692 [-Wrestrict]
  375 |     (void) strcat( pi->szCnrTitle, pi->szDirectory );
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ctxtmenu.c:375:12: warning: 'strcat' accessing 281 or more bytes at offsets 412 and 692 may overlap 1 byte at offset 692 [-Wrestrict]
gcc -Wall -Zomf -c -O2 edit.c -o edit.obj
gcc -Wall -Zomf -c -O2 populate.c -o populate.obj
gcc -Wall -Zomf -c -O2 sort.c -o sort.obj
sort.c: In function 'DateCompare':
sort.c:192:38: warning: '%02u' directive writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-overflow=]
  192 |     (void) sprintf( szDate1,"%04u%02u%02u",date1.year, date1.month, date1.day );
      |                                      ^~~~
sort.c:192:29: note: directive argument in the range [0, 255]
  192 |     (void) sprintf( szDate1,"%04u%02u%02u",date1.year, date1.month, date1.day );
      |                             ^~~~~~~~~~~~~~
sort.c:192:12: note: 'sprintf' output between 9 and 12 bytes into a destination of size 9
  192 |     (void) sprintf( szDate1,"%04u%02u%02u",date1.year, date1.month, date1.day );
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sort.c:193:38: warning: '%02u' directive writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-overflow=]
  193 |     (void) sprintf( szDate2,"%04u%02u%02u",date2.year, date2.month, date2.day );
      |                                      ^~~~
sort.c:193:29: note: directive argument in the range [0, 255]
  193 |     (void) sprintf( szDate2,"%04u%02u%02u",date2.year, date2.month, date2.day );
      |                             ^~~~~~~~~~~~~~
sort.c:193:12: note: 'sprintf' output between 9 and 12 bytes into a destination of size 9
  193 |     (void) sprintf( szDate2,"%04u%02u%02u",date2.year, date2.month, date2.day );
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Regards

[Dave Yeo]

This works,

Code: [Select]

diff -ur cnrmenu_b1.orig/CNRMENU.H cnrmenu_b1/CNRMENU.H
--- cnrmenu_b1.orig/CNRMENU.H 2023-05-23 17:23:18.000000000 -0700
+++ cnrmenu_b1/CNRMENU.H 2023-07-20 16:35:18.000000000 -0700
@@ -125,7 +125,7 @@
     // Used to keep track of frame windows associated with OtherWindow menuitems
     HWND hwndFrame[ IDM_OTHERWIN_LASTITEM - IDM_OTHERWIN_ITEM1 + 1 ];
 
-    CHAR szCnrTitle[ CCHMAXPATH + 20 ]; // Container title
+    CHAR szCnrTitle[ CCHMAXPATH + 19 ]; // Container title
     CHAR szDirectory[ CCHMAXPATH + 1 ]; // Directory being displayed
     CHAR achWorkBuf[ CCHMAXPATH + 1 ];  // Instance work buffer
 
diff -ur cnrmenu_b1.orig/SORT.C cnrmenu_b1/SORT.C
--- cnrmenu_b1.orig/SORT.C 2023-06-09 15:19:50.000000000 -0700
+++ cnrmenu_b1/SORT.C 2023-07-20 16:27:14.000000000 -0700
@@ -184,7 +184,7 @@
 {
     CDATE date1 = ((PCNRITEM) prc1)->date;
     CDATE date2 = ((PCNRITEM) prc2)->date;
-    CHAR  szDate1[ 9 ], szDate2[ 9 ];
+    CHAR  szDate1[ 12 ], szDate2[ 12 ];
     INT   iResult;
 
     pv = pv;    // to keep the compiler happy

But not really sure about making szCnrTitle smaller. Making the date larger should be fine, maybe waste 3 bytes *2. Running both I don't see a difference running the executables.

[Martin Iturbide]

Thanks Dave

It compiles, it works. I just got this warning now:

gcc -Wall -Zomf -c -O2 ctxtmenu.c -o ctxtmenu.obj
ctxtmenu.c: In function 'CtxtmenuSetView':
ctxtmenu.c:375:12: warning: 'strcat' accessing 280 or more bytes at offsets 412
and 691 may overlap 1 byte at offset 691 [-Wrestrict]
  375 |     (void) strcat( pi->szCnrTitle, pi->szDirectory );
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ctxtmenu.c:375:12: warning: 'strcat' accessing 280 or more bytes at offsets 412
and 691 may overlap 1 byte at offset 691 [-Wrestrict]

Regards

[Dave Yeo]

Looks like I screwed up and didn't do a make clean.
This part of the patch is unneeded,

Code: [Select]

-    CHAR szCnrTitle[ CCHMAXPATH + 20 ]; // Container title
+    CHAR szCnrTitle[ CCHMAXPATH + 19 ]; // Container title

The makefile should have referenced cnrmenu.h on the first line of the recipe at line 22,

Code: [Select]

ctxtmenu.obj : ctxtmenu.c cnrmenu.h
        gcc -Wall -Zomf -c -O2 ctxtmenu.c -o ctxtmenu.obj

So that when I touched the header a rebuild of ctxtmenu.obj should be triggered. Not sure how to fix the warning.

[Lars]

The problem is that szDirectory is a character array of 260 bytes and szCnrTitle is a byte array that is shorter. Gcc can detect that. Either you make szCnrTitle at least as large as szDirectory or you just ignore it.

[Dave Yeo]

The problem is that szDirectory is a character array of 260 bytes and szCnrTitle is a byte array that is shorter. Gcc can detect that. Either you make szCnrTitle at least as large as szDirectory or you just ignore it.

I see this,

Code: [Select]

    CHAR szCnrTitle[ CCHMAXPATH + 20 ]; // Container title
    CHAR szDirectory[ CCHMAXPATH + 1 ]; // Directory being displayed


[Lars]

Then, gcc computed that concatenation via strcat might overflow from szCnrTitle into szDirectory. In that case, szCnrTitle has to be the theoretical maximum of the string length that could result from concatenation. You either have to likely double the size of szCnrTitle or use pointers pointing to array locations in order to trick the compiler in giving up on determining maximum string lengths.