Klaus Espenlaub wrote:
To continue: I resumed gmake and now the rts part of p has been built! I got a few errors which did not cause s stop of gmake, I'm not sure if they are a problem (should I worry about them?):
I would worry about them. But it's possible that they go away after you installed gpc and re-do the gpc compilation. You can check if something is wrong with the gpc driver program if you start it with option -v for the program issuing the errors. There should be either a "-D__BYTES_BIG_ENDIAN__" or a "-D__BYTES_LITTLE_ENDIAN__" in the command line for the preprocessor. Similarly for BITS and WORD.
I wouldn't trust gpc until there are no #error lines left.
True. When these things are not defined, some of the RTS will not work realiably. I think the problems are due to the fact that a previously installed GPC was used to compile the RTS. I think (hope) that this will be fixed in the next version.
Part of the problem seems to be that the automake feature doesn't pass the error code of a failed sub-compile command back to the calling make program.
Peter: can you put this on the automake todo list?
It is already on the To-Do list, namely under "Fixed Bugs". :-) IOW, it will work this way in the next version.
Nick Cremelie wrote:
...but: txtfile and binfile both crash with:
?GPC runtime error: (gpc-rts) _p_initfdr() has not been called for file (#701)
Now what's that???????
I suppose it has something to do with the "bind" functionality in gpc for binding an external file to a variable???
Not really with bindings, but anyway: There's a known bug "On IRIX work stations, _p_initfdr() must be called manually" on the To-Do list. So, I'm adding AIX there. I don't know anything about these architectures, but I agree that fixing this would be a good idea... :-/
Frank