I am attempting to create a runner with the following conditions..

AIX: 5.3
GCC: 3.3.2
RDS: 7.32
IDS: 9.40

have created my personal cfglgo and added

CC="gcc"
C4GLFLAGS="-fwriteable-strings"

when I attept to compile the runner I receive the errors listed below,
any ideas or comments welcome.. also, I used both
"-fwriteable-strings" and "-fwritable-strings" with the same results.




Compiling the runner ...
../cfglgo -DFGLPCVER=732 timer.c menureset.c io.c db_stop.c
usr_func
s41.c fgiusr41.c -o cdcgo-7.32.FC2 -s
gcc: `-b' must come at the start of the command line
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 2.
Stop.


--

W. R. Werner

toonsez wrote:
> I am attempting to create a runner with the following conditions..
>
> AIX: 5.3
> GCC: 3.3.2
> RDS: 7.32
> IDS: 9.40
>
> have created my personal cfglgo and added
>
> CC="gcc"
> C4GLFLAGS="-fwriteable-strings"
>
> when I attept to compile the runner I receive the errors listed below,
> any ideas or comments welcome.. also, I used both
> "-fwriteable-strings" and "-fwritable-strings" with the same results.
>
> Compiling the runner ...
> ./cfglgo -DFGLPCVER=732 timer.c menureset.c io.c db_stop.c
> usr_func
> s41.c fgiusr41.c -o cdcgo-7.32.FC2 -s
> gcc: `-b' must come at the start of the command line
> make: 1254-004 The error code from the last command is 1.

What changes did you make to cfglgo? Since you're running it as
../cfglgo, it can't (surely) be the copy installed in $INFORMIXDIR/bin
as that would mean you have source code in $INFORMIXDIR/bin which is a
horrendous no-no.

Since you have a local copy of it, it's easy to inspect what is
happening under the covers:

sh -x ./cfglgo -DFGLPCVER=732 timer.c menureset.c io.c \
db_stop.c usr_funcs41.c fgiusr41.c -o cdcgo-7.32.FC2 -s

When you see the line that executes gcc, you'll know where the '-b'
option appears, and you can then fix it (either by removing it or by
moving it to the front of the command line).

The option to GCC is -fwritable-strings (only one letter e). Be aware
that it is deprecated -- see the GCC 3.4 release notes
(http://gcc.gnu.org/gcc-3.4/).

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

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/