makefile interpretation - help needed

[Dariusz Piatkowski]

LOL...so this is part of my on-going attempt to add shared memory monitor to the PUMonitor utility.

Alright...PUMon relies on Borland's BMAKE for makefile handling, so I figured I would take a stab at converting that to NMAKE32 instead so I can use my VAC++ 3.6.5. Heck, I started this a looonnnnggg time ago (see https://www.os2world.com/forum/index.php/topic,2646.msg29061.html#msg29061) and now that I've made the memory watch code changes I really needed to commit and get that previous attempt to produce results!!!

Ha...but OK, I am basing this work on the original makefile and in the TARGET section:

Code: [Select]

...
# Targets
all :  pumon2.exe

COMMON.LIB : $(OBJS)
@cd .\obj
-@del COMMON.LIB >nul 2>nul
@$(LIBRARIAN) COMMON.LIB @..\library.rsp;
@cd ..

pumon2.exe : COMMON.LIB pumon2.obj pumon2.res
@cd .\obj
$(CC) @&&|
pumon2.obj COMMON.LIB   ..\source\si2.lib ..\source\win32k.lib so32dll.lib tcp32dll.lib pumon2.def
|
@$(RC) pumon2.res pumon2.exe
@cd ..
...

there I find the following snippet which I'm thrown off by:

Code: [Select]

$(CC) @&&|
pumon2.obj COMMON.LIB   ..\source\si2.lib ..\source\win32k.lib so32dll.lib tcp32dll.lib pumon2.def
|

I need help understanding this.

'CC' macro expands to => CC=icc -O+ -Oc+ -Ss+ -G5 -Q+ -Gm+ -I..\include -B"/ST:327680 /NOE /E:2" -B"/PMTYPE:PM"

Seems simple at first: the compiler is called, and given the placement of that command (PUMON2.EXE target) it appears that this is the FINAL call to link everything together.

OK, but that "@&&" string right after it implies a CLI conditional execute call that will only execute the stuff following "|" if the CC call is successful, but the "|" (pipe) what is that about (what sort of CC output am I expecting to pipe into the next section???)...and if CC will execute as-is, what the heck is it processing anyways given that I do not see anything telling it to pick up a dependent, nor to create a target.

Clearly I am missing something here and having spent a couple of hours on this tonight I'm stuck...

[KO Myung-Hun]

Hi/2.

Code: [Select]

$(CC) @&&|
pumon2.obj COMMON.LIB   ..\source\si2.lib ..\source\win32k.lib so32dll.lib tcp32dll.lib pumon2.def
|


Here '@' means a response file. '&&' means a temporary file. '|' is a delimiter marking starting and ending of temporary file contents.

That is, the above line is passing 1 obj file, 5 lib files and 1 def file to $(CC) as a response file.

[Dariusz Piatkowski]

KO!

Thank you sir.

Here '@' means a response file. '&&' means a temporary file. '|' is a delimiter marking starting and ending of temporary file contents...

Translating that whole pumon2.exe target block to NMAKE32 syntax I would get:

Code: [Select]

pumon2.exe : COMMON.LIB pumon2.obj pumon2.res
@cd .\obj
        $(CC) @<< pumon2.obj COMMON.LIB   ..\source\si2.lib ..\source\win32k.lib so32dll.lib tcp32dll.lib pumon2.def
<<
@$(RC) pumon2.res pumon2.exe

It is that "@&&" that threw me for a loop here: I didn't recognize that, couldn't find it in Borland's docs (or just missed the one that actually talked about it) and certainly didn't pick up on the concept!

I do have to ask the following though: all that this CC instruction is doing is to LINK the individual objects (either OBJ or LIB) into the final EXE?

If so (and that was my initial thought) I had already written the following:

Code: [Select]

NAME = pumon2
LIBS = COMMON.lib
LINKFLAGS = /ST:327680 /NOE /PMTYPE:PM
...
$(NAME).exe : $(LIBS) $(NAME).obj $(NAME).res
   $(LINK) $(LINKFLAGS) /MAP $(OBJS) $(LIBS) $(SRC_DIR)si2.lib\
           $(SRC_DIR)win32k.lib so32dll.lib tcp32dll.lib $(NAME).def /OUT:$@
   $(RC) $(RCFLAGS)$(INC_DIR) $(NAME).res $@
...

...which I think should be sufficient, right?

Alright...let me try that out and go to the next thing: so far I'm getting stuck on the TCP/IP packet processing with a whole slew of CC errors on ipstat.cpp:

Code: [Select]

...
icc.exe -O+ -Oc+ -Ss+ -G5 -Q+ -Gm+ -I.\include\ /c /Fo.\obj\ipstat.obj .\source\ipstat.cpp;

g:\code\tools\toolkit\H\STACK16\netinet\in_systm.h(30:17) : error EDC3263: Syntax error - expected ";" or "," and found "n_short".
g:\code\tools\toolkit\H\STACK16\netinet\in_systm.h(31:17) : error EDC3263: Syntax error - expected ";" or "," and found "n_long".
g:\code\tools\toolkit\H\STACK16\netinet\in_systm.h(33:17) : error EDC3263: Syntax error - expected ";" or "," and found "n_time".
g:\code\tools\toolkit\H\STACK16\netinet\ip.h(60:17) : error EDC3320: Syntax error - found "u_char ip_tos" : "u_char" is not a type name.
...


[Lars]

The first thing that I would do if I were you is to make sure you are linking in and working with the 32-bit TCPIP stack and not the 16-bit TCPIP stack !

What you need to do is to not define (or to undefine) the TCPV40HDRS define.
Once you have done that you will also need to include the "types.h" header file before the in_systm.h file.
I found out that including the needed header files for network programming is often a trial and error game...

Somewhere around is a TCPIP toolkit which also lists all functions. For each function it will tell you what header files you need to include in what order ...

[Dariusz Piatkowski]

Hi Lars!

The first thing that I would do if I were you is to make sure you are linking in and working with the 32-bit TCPIP stack and not the 16-bit TCPIP stack !

What you need to do is to not define (or to undefine) the TCPV40HDRS define.
Once you have done that you will also need to include the "types.h" header file before the in_systm.h file.
I found out that including the needed header files for network programming is often a trial and error game...

Somewhere around is a TCPIP toolkit which also lists all functions. For each function it will tell you what header files you need to include in what order ...

Excellent pointer, as it turns out I started to head that way as I reviewed the H files to understand why the 16-bit stuff was getting pulled in.

This led me down the path you suggested, which was to comment out the TCPV40HDRS define, that however did not make a difference, the complier is still picking up the 16-bit H stuff.

I did search through all the project files (pumon that is), so there probably is an include of a separate H from the OS/2 Toolkit that's somehow causing that outcome.

Need to do a little more digging into things.

For what's it worth, here is the CMD file I used to setup the ENV for NMAKE32 execution, which in turn calls CC, does anything there jump out at you (I'm only relying on the IBMCPP 3.6.5 & Toolkit, the GCC stuff is excluded):

Code: [Select]

@ECHO OFF
SET CXXMAIN=G:\code\tools\Ibmcpp
SET TKMAIN=g:\code\tools\toolkit
SET GCCMAIN=g:\usr

rem Add the OS2_TOOLKIT INCLUDE directories to the mix
SET INCLUDE=%TKMAIN%\H\ARPA;%TKMAIN%\H\NET;%TKMAIN%\H\NETINET;%TKMAIN%\H\NETNB;%TKMAIN%\H\RPC;%TKMAIN%\SPEECH\H;%TKMAIN%\H\GL;%TKMAIN%\H;%INCLUDE%
SET INCLUDE=%TKMAIN%\H\LIBC;%TKMAIN%\H\LIBC\SYS;%TKMAIN%\H\MACHINE;%TKMAIN%\H\PROTOCOL;%TKMAIN%\H\RPC;%TKMAIN%\H\STACK16;%TKMAIN%\H\SYS;%INCLUDE%
SET LIB=%TKMAIN%\LIB;

rem DO NOT use the GCC INCLUDE directories
rem SET INCLUDE=%GCCMAIN%\INCLUDE;%INCLUDE%

rem ***********************************************************
rem IBM C and C++ Compilers for OS/2 environment variable settings
rem Licensed Materials - Property of IBM
rem (C) Copyright IBM Corp. 1991, 1997   All Rights Reserved
rem ***********************************************************

SET BEGINLIBPATH=%CXXMAIN%\DLL;%BEGINLIBPATH%
SET DPATH=%CXXMAIN%\HELP;%CXXMAIN%\LOCALE;%DPATH%
SET HELP=%CXXMAIN%\HELP;%HELP%
SET INCLUDE=%INCLUDE%;%CXXMAIN%\INCLUDE;
SET IPFC=%CXXMAIN%\BIN;%IPFC%
SET LIB=%LIB%;%CXXMAIN%\LIB;
SET CPP_DBG_LANG=CPP
SET LANG=en_us
SET NLSPATHTEMP=%CXXMAIN%\MSG\%%N
SET NLSPATH=%NLSPATHTEMP%;%NLSPATH%
SET NLSPATHTEMP=
SET PATH=%CXXMAIN%\BIN;%PATH%

/* Kick off the NMAKE app */
g:\code\tools\toolkit\bin\nmake32.exe /nologo /f %1
exit

Should I have the VACPP 3.6.5 INCLUDE dirs ahead of Toolkit stuff?

EDIT
====
Nope, that last part did NOT make a difference, so that 16-bit stuff is coming from somewhere else.

[Dave Yeo]

Don't use the toolkit that came with 3.65, use the latest. There's various reasons for this including that when 3.65 was released there likely was only the 16 bit TCPIP headers.
If you don't have a copy of the os2tk45 toolkit, you can install it with yum.

[Dariusz Piatkowski]

Hi Dave,

Don't use the toolkit that came with 3.65, use the latest. There's various reasons for this including that when 3.65 was released there likely was only the 16 bit TCPIP headers.
If you don't have a copy of the os2tk45 toolkit, you can install it with yum.

I had considered and actioned this as well, party because of some of your prior posts on the subject of setting up the correct ENV for being able to use the Toolkit along with multiple kinds of compilation and DEV tools.

Having said that, I am differentiating here between the VACPP 3.6.5 install, which does have it's own H files, and the actual OS/2 Toolkit (README - IBM OS/2 DEVELOPER'S TOOLKIT VERSION 4.5.2.) 4.5.2, which is the version I have the current install of.

More specifically, the OS/2 Toolkit install is the os2tk45-4_5_2-6_oc00.zip contents having replaced the standard/original OS/2 Toolkit install (CSD LEVEL XR04004). So in effect I'm still pointing to my \code\tools\toolkit install directory as opposed to the \usr\... stuff that things eventually went to.

Subsequently, my current setup is intended to be an upgraded "out of the box" combination of VACPP and OS/2 Toolkit (with all the various upgrades), which AFAIK as supposed to be complementary in a sense that what VACPP does NOT provide for, the OS/2 Toolkit itself should.

VACPP being the C/C++ standard stuff and OS/2 Toolkit being the OS/2 specific stuff.

As such, so long as I am not attempting to rely on a whole bunch of GCC stuff I should simply be able to execute the "native" OS/2 DEV toolset: VACPP & OS/2 Toolkit.

Alright...thanks for the suggestions, back to my snooping in the meantime as somewhere in there is an answer...and maybe that's just a tail I'm chasing between my very own legs, but that does point to continuing weakness of our platform: how the heck do you make sense of all of these things? LOL

[Tom]

Dariusz,

Are you aware of the book "Mastering Make" (2nd edition) by Tondo, Nathanson and Yount? (ISBN 0-13-121906-5)
It also covers NMake and Borland's Make on OS/2 plus versions for DOS and UNIX. It is from 1994.

[Dave Yeo]

Hi Dariusz, simply changing the SET TKMAIN=g:\code\tools\toolkit to SET TKMAIN=%UNIXROOT%\usr\include\os2tk45 should be all that is required to use your script with os2tk45.

[Dariusz Piatkowski]

Tom!

Are you aware of the book "Mastering Make" (2nd edition) by Tondo, Nathanson and Yount? (ISBN 0-13-121906-5)
It also covers NMake and Borland's Make on OS/2 plus versions for DOS and UNIX. It is from 1994.

Most helpful indeed, thank you kindly!

[Dariusz Piatkowski]

Dave,

Hi Dariusz, simply changing the SET TKMAIN=g:\code\tools\toolkit to SET TKMAIN=%UNIXROOT%\usr\include\os2tk45 should be all that is required to use your script with os2tk45.

Perhaps the time has finally come for me to abandon the original Toolkit install (along with all the upgrades) and deploy the os2tk45 RPM package as you suggest!

As it stands right now:

1) I was able to fix the 16-bit TCP/IP stack issue by cleaning up the ordering of my INCLUDE statement setup, apparently having the 16-bit H stuff ahead of the 32-bit caused me a problem...seems silly given that every single H file I looked at did check for TCPV40HDRS having been defined first...but...

2) The problem I now run into is that the code is written to use the 16-bit stuff, so something like soclose() belongs in unistd.h on the 32-bit stack and well the stars aren't quite aligned for me (LOL, OK I knew it wouldn't be THIS easy, but I took a stab at it anyways) and just adding unistd.h isn't enough
- there were several other structures that changed names between the two stacks as well, but at least those were easy to spot, track and change

Sooo....the last time I was able to compile this was in 2021, and that was to increase the number of CPUs being recognized. While I used the Borland MAKE for that, I did successfully use the as-is VACPP & Toolkit install I have here, and yet today the outcome is different, which means that my Toolkit environment changed in some way.

Yeah, needless to say the os2tk45 may be just about the only viable option to get to a working environment...!!!

As always, thanks for all the help!

[Dariusz Piatkowski]

Last update (I think ? ) on this topic: I went back to declaring TCPV40HDRS so that I wouldn't have to fight - what seems like a bigger battle - migrating to the full 32-bit stack.

Found my ENV issue that was preventing me from successfully building, that was the wrong order of directories in my INCLUDE statement, having fixed that I now have all the source compiling.

I do have some new questions re: memory stats/usage APIs, but I'll toss that into a separate thread.

Thanks everyone for the feedback and suggestions!