Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!toumon!wucc!ytsuji From: ytsuji@wucc.waseda.ac.jp (Y.Tsuji) Newsgroups: comp.sys.atari.st Subject: Re: GCC compile error Message-ID: <5652@wucc.waseda.ac.jp> Date: 15 May 91 14:21:40 GMT References: <9105082156.aa25310@Bonnie.ics.uci.edu> Organization: The Centre for Informatics, WASEDA Univ. Lines: 31 In article , wolfram@akela.informatik.rwth-aachen.de (Wolfram Roesler) writes: > bferrer@Bonnie.ICS.UCI.EDU writes: > > >can't find d:\tmp/cc100000.s > > I had that problem too. It seems that gcc had not fully been ported from > Unix, so some filespecs still use slashes. > However, the slashes arent really the problem since TOS can deal with > filenames containing slashes. So, the file mentioned above would have > the name `tmp/cc100000.s' and be in the root directory of drive d. > Since the part of the filename is longer than 8 chars, TOS runs into > trouble. As nobody has asked me to post my own port of GNU C, I'll be just guessing what has happened, but excuse me. It seems the environment string of TMPDIR or something is set as 'd:\tmp' instead of 'd:/tmp' or the compiler expects to be under some master such as MiNT or something which converts the filename delimiter (just guess). I didn't know that TOS accepted slashes! I have thought only the newish DESKTOP command interpreter did so. Oh, no. Wolfram says slashes are part of the filename, not the delimiter. Quite right. The filenames are usually stored somewhere called filename pools that cope with arbitrarily long names, various mount devices, file name links, symbolic links etc. Therefore the unix style filenames have very little in common with the 'real' name stored in the conventional part of the media called directory. The filename pools can exist as part of the library or supplied by the operating system (command line interpreter can incorporate them) which could be running under some native OS such as TOS. Ytsuji@wucc.waseda.ac.jp