Whew! What a mouthful of a subject line.

Anyway, I am using a z/OS 2.1 system to try to port BASH 4.2 to work
on z/OS. I want to support older releases. The oldest that the C
compiler lets me specify is TARG(LE,ZOSV1R12). Which is, in itself, a
royal PITA. But this is causing a problem with the way that GNU's
./configure works. In my particular case, ./configure tries to
determine if the __fpurge() function exists. If it does, then it sets
some "macros" to so indicate in config.h. On z/OS 2.1, the __fpurge()
does exist. But this is the first release. So when I do a compile with
the TARG set, instead of not defining __fpurge() at all, the person
who wrote the #include wrote:

__new4201(void,   __fpurge,              (FILE *));

which, with the above TARG, generates the code:

extern struct __notSupportedBeforeOS4V2R1__ __fpurge;

which compiles. At least in the small code segment used by ./configure
to determine if __fpurge() exists. This sets a "macro" HAVE___FPURGE.
When this "macro" is defined, the actual compile of lib/sh/fpurge.c
fails with the message:

CCN3023     30      Expecting function or pointer to function.

This is because the fpurge.c program tries to use __fpurge() as a
function call. But the definition created by the <elided> #include is
for variable.

Honestly, I am so angry with whomever in the C language (or maybe LE)
group who made that <sarcastic> clever </sarcastic> __new4201() C
macro that I could pummel them. Or are they deliberately trying to
make it difficult to use GNU software? Stinking "vendor lock in". I am
basically enraged with such "clever" programmers. And I will stop
typing before I say something _really_ nasty.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to