gjh@hplb.hpl.hp.com (Graham Higgins) (11/07/90)
I've been experiencing a replicable problem with GNU C as available on terminator. I thought I'd have a bash at "bash" which somewhat cryptically appeared on the archives. It needs the GNU fileutils stuff (ls, cp, etc), so I've been trying to compile them up on the (newly-expanded) ST. gcc-as started to barf on a number of files, I got gcc to drop .s versions and looked carefully, only to find a number of statements of the form ... stab "e:\include\strings.h" which was parsed (correctly) by gcc-as escape-i and escape-s. What I can't figure out is why this particular include appears, as no other one does. Anyway, I'm still getting "Bogon Alerts" from the compiler, even when I double-backslash the paths. What concerns me is that this is standard GNU distribution fileutils, GNU C shouldn't have a problem compiling it. O.K., whether it runs or not is another thing, but it should compile up OK. I started to consider whether the GNU C port had some problem (after playing around with GNUINC = this-n-that for a while. It made no positive difference. Any ideas anyone? Gray (ever puzzled)
roeder@robin.cs.uni-sb.de (Edgar Roeder) (11/10/90)
In article <GJH.90Nov6211120@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham Higgins) writes: > gcc-as started to barf on a number of files, I got gcc to drop .s versions > and looked carefully, only to find a number of statements of the form ... > stab "e:\include\strings.h" > which was parsed (correctly) by gcc-as escape-i and escape-s. What I can't > figure out is why this particular include appears, as no other one does. I don't know which version of gcc is on terminator, but the versions derived from Jwahar Bammi's port should understand slashes (/) instead of (\) as the directory delimiter. > Anyway, I'm still getting "Bogon Alerts" from the compiler, even when I > double-backslash the paths. What concerns me is that this is standard GNU > distribution fileutils, GNU C shouldn't have a problem compiling it. O.K., > whether it runs or not is another thing, but it should compile up OK. These bogon-alerts come from a bug in the linker when you link with symbol table included (they use a wrong comparision function that cannot distinguish all three possible arrangements of the input-params). If you link with -s (no symbols), these bogon alerts should go away. BTW. I have compiled the fileutils with almost no changes (except in the Makefile). > I started to consider whether the GNU C port had some problem (after > playing around with GNUINC = this-n-that for a while. It made no > positive difference. You could of course put strings.h in the current directory, so it would't need any directory delimiter in the above .stab entry. > Any ideas anyone? > Gray (ever puzzled) You could try the gcc version and library at cs.uni-sb.de. Hope this helps! - Edgar