Compile on HP Nonstop.

[gcav]

Hi, playing with Bacon on an HP Nonstop.
Looks like the OSS inet lib does not have inet_aton

Peter, can this be bypassed in the configure?

thanks,
gc

[gcav]

This is going to be harder than expected :-D

[Pjot]

Hi gcav,

The 'inet_aton' function indeed is not POSIX compliant, I have replaced it for the POSIX 'inet_pton' function, which also is more versatile anyway.

Can you fetch the latest beta and see if it works for you?

Thanks,
Peter

[gcav]

This will take a while as the HP Nonstop OSS has some idiosyncrasies that need addresed

So far:
-moved out the inet_to_aton thing
-HPNSK_OSS does not have which, so bypased that check, but all binaries accounted for.
-HPnsk Korn shell does not like TYPEDEF -A so building with BASH.


Peter last 2 errors I received:

/users/gus/bacon-4.1/build: c89 -Werrors=2 -Wnowarn -D__TANDEM -D_XOPEN_SOURCE_EXTENDED=1 -Wextensions -Wsystype=oss -Wcplusplus -c bacon.bac.c
void *__b2c__hash_find_value_do(__b2c__htable *name, char *key) { __b2c__htable *table; unsigned short pos; if(name == NULL || key == NULL) { return(NULL); } pos = HASH(key) & 65535; table = __b2c__hash_find_key(name, pos, key);
^
"/users/gus/bacon-4.1/build/bacon.bac.functions.h", line 157: error(4759): cast
to incomplete array type "char *[]" is not allowed

void *__b2c__hash_find_value_do(__b2c__htable *name, char *key) { __b2c__htable *table; unsigned short pos; if(name == NULL || key == NULL) { return(NULL); } pos = HASH(key) & 65535; table = __b2c__hash_find_key(name, pos, key);
^
"/users/gus/bacon-4.1/build/bacon.bac.functions.h", line 157: error(123):
expected an expression

Error limit reached.
2 errors detected in the compilation of "bacon.bac.c".
Compilation terminated.

I attached a porting guide from HP which might be of use to you.

[Pjot]

Hi gcav,

That's interesting. I can see that the compiler 'c89' uses a '-Wcplusplus' compile flag. BaCon can be compiled with g++ or clang++, but it usually needs additional C++ compile flags to make this work. For example, "-x c++" to make sure the code is taken as C++. And also "-Wno-write-strings" and "-Wno-pointer-arith" to allow direct strings and pointer arithmetic (usually now allowed in C++).

The porting guide you have posted seems to be a plain text file in ISO-8859-14 format, and even then it is hard to read (no layout, lots of unreadable characters).

I would really enjoy porting BaCon to the HP NonStop (Tandem) platform, but it would help if I would have access to this platform. Do you know an emulator or VM which I can use?

Alternatively, if there is a possibility to provide temporary (limited) access remotely to your platform, then this is fine too of course. In that case, please send me a PM with details.

Thanks and regards,
Peter

[gcav]

Sept 28, 2020 20:03:39 GMT 1 Pjot said:

Hi gcav,

That's interesting. I can see that the compiler 'c89' uses a '-Wcplusplus' compile flag. BaCon can be compiled with g++ or clang++, but it usually needs additional C++ compile flags to make this work. For example, "-x c++" to make sure the code is taken as C++. And also "-Wno-write-strings" and "-Wno-pointer-arith" to allow direct strings and pointer arithmetic (usually now allowed in C++).

The porting guide you have posted seems to be a plain text file in ISO-8859-14 format, and even then it is hard to read (no layout, lots of unreadable characters).

I would really enjoy porting BaCon to the HP NonStop (Tandem) platform, but it would help if I would have access to this platform. Do you know an emulator or VM which I can use?

Alternatively, if there is a possibility to provide temporary (limited) access remotely to your platform, then this is fine too of course. In that case, please send me a PM with details.

Thanks and regards,
Peter

Oops... sorry about the attachment. Meant to attach a PDF. I will repost.

about the -Wcplusplus flag... I am experimenting with some of the flags and the native compiler.

I will point you to the manuals..


g

[gcav]

Hi Peter.

HP Nonstop docs
search under "oss porting" to read the PDF I meant to attach previously.

Also, take a look at:
IDI-TR-6-99.pdf (110.18 KB)

As for access, I am not in the position to offer that to you at the moment.
I will try in a couple of months. In the meantime, we can work
around here, I will continue trying to clear out some issues.
Take a look at the PDF and ask away, there are some things you must
learn for this machine.

gc

[Pjot]

Thanks gcav,

I found the "OSS Porting" documentation, especially chapters 7 and 9 are useful but show some warnings.

Apart from the 'inet_aton()' function, which now has been replaced, there are some other libc functions used by BaCon, and which should be replaced as well: setitimer() which is in POSIX 2001, and setlinebuf(). But this can be done.

However, and more disturbingly, chapter 9 mentions the following:

The following C source code utilities might be available on your UNIX workstation:
• m4 is a general-purpose macro preprocessor for C programs.
<....>
You should perform your source code analysis before porting to the OSS environment. Therefore, these tools are not provided with the OSS environment.

If the M4 utility is not available in OSS (either the GNU version or otherwise), then we can stop here right now. The presence of M4 is an absolute requirement for BaCon to perform its code generation. Without M4 on your system BaCon simply will not work.

As often, documentation may not reflect reality, so can you verify if your environment has M4 available?

Best regards
Peter

[gcav]

Someone ported M4-1.4.15 to TNS.
Let me try installing it.

g

[gcav]

Hi Peter.

M4 works, and bacon.sh created bacon.bac.m4

Im stuck with these 2 errors. And the current avaliable doc/pdf for the compiler
has a wrong error description for error(123) and no entry for error(4759).
I have opened a ticket with HP to explain this doc discrepancies.

thx,
gc

[Pjot]

Hi gc,

So for m4, that is good news. The BaCon code generator creates an ".m4" file containing patterns which are used to recognize which functions need to be included in the generated source code. The 'm4' utility then parses this file to define the list of required functions. This way, we do not need an external 'libbacon.a' file anymore.

Regarding the compilation problem, I again did look at your compile command:

# /users/gus/bacon-4.1/build: c89 -Werrors=2 -Wnowarn -D__TANDEM -D_XOPEN_SOURCE_EXTENDED=1 -Wextensions -Wsystype=oss -Wcplusplus -c bacon.bac.c

The '-Werrors=2' flag means that the c89 compiler will stop after the first 2 errors. Probably this is just top of the iceberg. The parameter '-Wcpluscplus' means that the compiler should take the source code as c++ files (according to the porting guide). This may lead to all kinds of unexpected (and unwanted) results.

The _XOPEN_SOURCE_EXTENDED macro enables the POSIX.1 and POSIX.2 environment, as well as XPG4V2 functions and the sockets API. So this is something we need.

The OSS Porting Guide shows some very basic compile commands. I propose to start with these simple commands and forget about the 'configure'-script for now. This script is mainly meant as a wrapper, allowing the creation of an extended Makefile.

To compile BaCon, we just need the shell script version and the BaCon version into the same directory. Then, can you run both the below commands and send me the output? These commands compile the code using the 2 C-compilers available in OSS.

Command 1 using c89

# bash ./bacon.sh -c c89 -o -D_XOPEN_SOURCE_EXTENDED bacon


Command 2 using c99

# bash ./bacon.sh -c c99 -o -D_XOPEN_SOURCE_EXTENDED bacon


For both of them I am pretty sure they will show a lot of errors. In fact, they do so on my Linux system. The c89 and c99 names refer to older C standards (year 1989 and 1999 respectively) of which I already know BaCon is not compliant to.

However, if the errors are more or less the same in Linux and HP NonStop, then adapting the BaCon code generator will probably be easier, as I can test it in my own Linux environment.

Thanks in advance,

Peter

[Pjot]

Hi gcav,

With just a few minor adjustments, the BaCon code can be compiled in C89 mode on my Linux system. This works for me now:

# bash ./bacon.sh -c c89 -o -D_DEFAULT_SOURCE -o -D_XOPEN_SOURCE_EXTENDED bacon.bac

For HP NonStop, when looking at the supplied macros, I think OSS needs the following line, including '-linet' to link with the sockets library:

# bash ./bacon.sh -c c89 -o -D__TANDEM -o -D_XOPEN_SOURCE_EXTENDED -linet bacon.bac

Can you download the attachment in this post, put both files into the same directory and try this last command?

Thanks,
Peter

Attachments:

bacon.zip (168.95 KB)

[gcav]

Hi Peter.

I downloaded the code and:
a) bacon.sh looks uses which to check for some tools. I removed that check
b) im sending you two zips, one with a list_makebuild using the defines from the normal build
and a sceond one with 2 more defines I added, might be useful for compare purposes.

on build_p zip it is missing defines to u_short..
when I add 2 more defines in the other build.zip we mostly get these 2 errors.

Before any changes you made, I tested with some other defines, and I got stuck on 2 errors..
void __b2c__hash_del_do(__b2c__htable *name, char *key) { __b2c__htable *found; unsigned short pos; if(name ==
NULL) { return; } pos = HASH(key) & 65535; found = __b2c__hash_find_key(name, pos, key);

^
"/users/gus/bacon_trunk/build/bacon.bac.functions.h", line 168: error(4759):
cast to incomplete array type "char *[]" is not allowed


and void __b2c__hash_del_do(__b2c__htable *name, char *key) { __b2c__htable *found; unsigned short pos; if(name ==
NULL) { return; } pos = HASH(key) & 65535; found = __b2c__hash_find_key(name, pos, key);

^
"/users/gus/bacon_trunk/build/bacon.bac.functions.h", line 168: error(123):
expected an expression


this last one looks like a missing argument for sure.
I will try and look ath this last error.
I asked for the Compiler doc and HP does not have them ready,
so only the compiler description is avaliable.

I am also sending you the man page of the c89 compiler.

Regards,
gc.

Attachments:

build.tgz (214.15 KB)

build_p.tgz (208.86 KB)

c89.txt (123.95 KB)

[Pjot]

Thanks gcav,

The actual conversion of the code seems to be working fine, which is good news. The problem now only is with the actual compilation.

Looking at the "list_makebuild" files, there are a lot of warnings regarding sign and rounding errors. Though these need to be addressed, we can ignore them for now.

Some errors are simply not true ("missing return statement at end of function"), however, these may be caused by previous errors.

So now, there are two blocking issues I can see from the log files.

(1) the c89 compiler seems to be not able to read the system-supplied network header files. This has nothing to do with BaCon. Apparently we need some kind of command line argument so the c89 compiler can accept the network code. According to the Porting Guide, we should take care of the following (page 183):

To compile an OSS application module that contains OSS sockets calls:
• Define _XOPEN_SOURCE_EXTENDED as 1 at compile time.
• Define _TANDEM_SOURCE in the module or at compile time. This toggle is not needed for strictly compliant applications.
• Link the module with the sockets SRL or DLL, or the static sockets library, if it uses any of the Internet domain support functions listed in Table 14.

In earlier pages the Porting Guide simply mentions "you must define _XOPEN_SOURCE_EXTENDED", so I thought my command line was correct (see page 115).

But now, I guess the command line should be "-D_XOPEN_SOURCE_EXTENDED=1" so it actually sets a value:

# bash ./bacon.sh -c c89 -o -D__TANDEM -o -D_XOPEN_SOURCE_EXTENDED=1 -linet bacon.bac


(2) The c89 compiler cannot handle Variadic Macros. The BaCon code uses variadic macros a lot, so we need a compiler which can accept this. As the concept of variadic macros was standardized in 1999 I do not expect the OSS c89 compiler to work.

Instead, we could try the c99 compiler, which also should available in HP NonStop. The c99 compiler should be compliant to the 1999 standard and (hopefully) also includes support for variadic macros. Then the command line should the be:

# bash ./bacon.sh -c c99 -o -D__TANDEM -o -D_XOPEN_SOURCE_EXTENDED=1 -linet bacon.bac


There's a lot of trial and error here, and even though in Linux the c89 (and c99) compiler works, and the generated code is ANSI compliant, we still may run into unforeseen problems, like with the C pre-processor (variadic macros) or other things yet to be discovered...

HTH,
Peter

[gcav]

Oct 4, 2020 7:40:30 GMT 1 Pjot said:

Thanks gcav,

# bash ./bacon.sh -c c99 -o -D__TANDEM -o -D_XOPEN_SOURCE_EXTENDED=1 -linet bacon.bac


There's a lot of trial and error here, and even though in Linux the c89 (and c99) compiler works, and the generated code is ANSI compliant, we still may run into unforeseen problems, like with the C pre-processor (variadic macros) or other things yet to be discovered...

HTH,
Peter

Hi Peter, I tried with the C99 and looks like the variadic macros error went away.  I added Wextensions as we will need to eventually incorporate some Guardiand Library calls to support some native calls. This reduced the total error s to 38. plus warnings.

Take a look. lso attached the C99 man page.  I will look at the present errors and poke around a bit.

gc.

Attachments:

c99 (115.4 KB)

LISTING (14.54 KB)