This isn't really consistent with how other TARGET() sensitive functions work, and IMO the way that LE (C library) did this was incredibly myopic. (They add new functions for GNU compatibility and then don't test their include files with a typical autoconf configure script :-)
You can patch configure or the generated config.h to tail on a section that #undefs these HAVE_s for z/OS < 2.1 I also suggest opening an APAR. The good news is that this will probably be the easiest part of your bash port :-) Will you be trying to add local spawn compatibility with the z/OS shell? A bash port that did that (better) would be fantastic. Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Sep 12, 2014 at 7:29 AM, John McKown <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
