Re: CFGLGO: AIX 5.3 RDS 7.32 and GCC compile error

Obviously, I put the copy in my own personal working directory, as it has the same name as the original (in reference to cfglgo) and would be difficult for two files of the same name to reside in the same directory. I found the problem and have corrected it... the -b flag was a lark, and related to cross platform compiling. Apparently IBM in their wisdom decided the CFLAG variable should be hard coded assuming the use of XLc. What needed to be done was in cfglgo add CC="gcc" and modify CFLAG="-DAIX51 -DNATIVE_ENDIAN=BIG_ENDIAN -maix64" and all seems to work correctly. Of course, I've taken it upon myself to have my cfglgo only work with gcc, so I'm no better than those folks with the Itty Bitty Machines, eh? So, as you say, I've deprecated the writable-strings, though I'm not sure where the one "e" actually can be found? Alas, I am but a proselyte to GCC. -- W R Werner

toonsez wrote: > Obviously, I put the copy in my own personal working directory, as it > has the same name as the original (in reference to cfglgo) and would be > difficult for two files of the same name to reside in the same > directory. Yes - I do that sort of thing depressingly often too. > I found the problem and have corrected it... the -b flag was a lark, > and related to cross platform compiling. Apparently IBM in their > wisdom decided the CFLAG variable should be hard coded assuming the use > of XLc. What needed to be done was in cfglgo add > > CC="gcc" > > and modify > > CFLAG="-DAIX51 -DNATIVE_ENDIAN=BIG_ENDIAN -maix64" > > and all seems to work correctly. Looks about right. > Of course, I've taken it upon myself > to have my cfglgo only work with gcc, so I'm no better than those folks > with the Itty Bitty Machines, eh? So, as you say, I've deprecated the > writable-strings, though I'm not sure where the one "e" actually can be > found? You might (or might not) find it necessary to reinstate the -fwritable-strings option in your CFLAG line. It's there because under some circumstances, I4GL (c-code - at any rate) can try to modify a read-only string that is part of a file name. In the p-code interpreter, there's less danger of the string being read-only in the first place -- it was probably read into dynamically allocated memory from the p-code interpretable. > Alas, I am but a proselyte to GCC. > > -- > W R Werner > -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/