gjh@hplb.hpl.hp.com (Graham Higgins) (11/16/90)
I have *exactly* Dave Megginson's problem too (not, not *that* one :-) ). With $TMPDIR set to e:\, gcc reported ... gcc e:/cc100000.cpp : cannot find file So, I thought I'd try the cs.uni-sb.de version (yes, I *will* post it to atari.archive, but I'm temporarily, denied ftp access, so you'll just *have* to wait). On with the plot --- I tried the cs.uni-sb.de version --- Crashed and burned. However, the cs.uni-sb.de version of GNU C was posted there by Edgar Roeder (with whom I am e-corresponding). I happen to know that Edgar is a bash user --- bash allows you to use / as well as \. Soooo, I got bash and turned on the / option --- Crashed & burned *again* --- and yes, I tried it with without the / option ... surprise, Crashed & burned!. No matter *what* I set $TMPDIR to, gcc reports that it cannot find $TMPDIR/cc100000.cpp (and yes, I made sure that $TMP matched $TMPDIR, just in case). export TMPDIR=/tmp echo $TMPDIR /tmp gcc -v -o test test.c gcc: /tmp/cc1000000.cpp cannot find file. export TMPDIR=/gnu/tmp echo $TMPDIR /gnu/tmp gcc -v -o test test.c gcc: /gnu/tmp/cc1000000.cpp cannot find file. That's two different versions of GCC giving *exactly* the same problem under two different environments. Anyone any ideas? Edgar's suggestions involve looking deep into the execution process using SysMon or master --- I have neither at the moment. Graham (*still* puzzled) Higgins.
dstailey@gnu.ai.mit.edu (Doug Stailey) (11/16/90)
In article <GJH.90Nov15180640@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham Higgins) writes: > >I have *exactly* Dave Megginson's problem too (not, not *that* one :-) ). > >With $TMPDIR set to e:\, gcc reported ... > >gcc e:/cc100000.cpp : cannot find file > >So, I thought I'd try the cs.uni-sb.de version >On with the plot --- I tried the cs.uni-sb.de version --- Crashed and >burned. However, the cs.uni-sb.de version of GNU C was posted there by Edgar >Roeder (with whom I am e-corresponding). I happen to know that Edgar is a bash >user --- bash allows you to use / as well as \. Soooo, I got bash and turned on >the / option --- Crashed & burned *again* --- and yes, I tried it with without >the / option ... surprise, Crashed & burned!. No matter *what* I set $TMPDIR >to, gcc reports that it cannot find $TMPDIR/cc100000.cpp (and yes, I made sure >that $TMP matched $TMPDIR, just in case). > did you try setting the following environment variable: UNIXMODE=/.,LAHbdxrC The final character is your root directory. This example assumes it is drive C. For more info on the subject, I would usually refer you to cs.uni-sb.de, but since this archive is unavailable at the moment, I'll try to break it down from memory. The first slash indicates slashes are used as well as backslashes. The character following the dot is used to replace multiple dots in the filename. L indicates the use of symbolic links, and A enables automatic links. These are simulated, and the link information is hidden in a table in a file called .dir, which is created automatically by all UNIXMODE applications. This file is also used for long filenames, which are implemented as simulated links. H causes .dir to be completely hidden from ls. b, d & x escape me at this late hour. The capital letter following r indicates the root drive. The programs you got from cs.uni-sb.de all use UNIXMODE. The environment is very useful for porting Unix source code. Recently, I re-ported Elvis, using the libs from cs.uni-sb.de, and now it understands the long file names and links. Also, I was able to define the system type as BSD, rather than TOS, which took out everything from the original port, and allowed it to use termcap. OK, I had to keep their sync() clone, but that was all. Hope this helps. Doug -- disclaimer: This message is sold by weight, not volume. Contents may have settled during shipment.
davidli@simvax.labmed.umn.edu (11/16/90)
In article <GJH.90Nov15180640@ghiggins.hpl.hp.com>, gjh@hplb.hpl.hp.com (Graham Higgins) writes: > gcc: /tmp/cc1000000.cpp cannot find file. Query: I notice that in your examples, there are 9 characters before the '.cpp' tag on the file. TOS allows 8 characters. How does your CLI deal with more than 8 characters in the first part of the file name? At least one CLI I've come across truncates the 9th character. Others might turn the file into something like 'cc100000.0cp. -- David Paschall-Zimbel davidli@simvax.labmed.umn.edu
gjh@hplb.hpl.hp.com (Graham Higgins) (11/17/90)
++ did you try setting the following environment variable: ++ UNIXMODE=/.,LAHbdxrC Yes, UNIXMODE *is* correctly set (according to Edgar's documentation) I even reformatted my HD in order to move to 32Mb partitions, so I could get GCC on the root partition. What I don't understand is how come *whichever* GCC I use, with *whichever* cli, gives the same problem. Apparently Dave Megginson *did* have the same problem, but it went away of its own accord. Wierd. Graham (ever puzzled) Higgins
stigvi@Lise.Unit.NO (Stig Vidar Hovland) (11/17/90)
In article <1990Nov16.120053.1@simvax.labmed.umn.edu>, davidli@simvax.labmed.umn.edu writes: |> In article <GJH.90Nov15180640@ghiggins.hpl.hp.com>, gjh@hplb.hpl.hp.com (Graham Higgins) writes: |> |> > gcc: /tmp/cc1000000.cpp cannot find file. |> If the environment variable GCCEXEC is not properly set up, Gnu C will print out the above message. Try setenv GCCEXEC 'x:\iiii\gcc-' or setenv GCCEXEC 'x:\iiii\gcc_' Stig Vidar Hovland - stigvi@lise.unit.no
gjh@hplb.hpl.hp.com (Graham Higgins) (11/19/90)
++ > gcc: /tmp/cc1000000.cpp cannot find file. ++ Query: I notice that in your examples, there are 9 characters before the ++ '.cpp' tag on the file. Sorry, heavy-handed typing, it should be /tmp/cc100000.cpp. It appears that the problem arises from GCC's interpretation of pathnames for GNUINC and a few little problems like requiring quotes surrounding setenv GNUINC='c:\gnu\include' do the quotes remain for ENVIRON.PRG? If the environment variable is set by both ENVIRON.PRG and GULAM.PRG, which wins --- and when? I am running all the cross-permutations to find out which is 1. legal 2. preferable More later.
hyc@math.lsa.umich.edu (Howard Chu) (11/20/90)
In article <GJH.90Nov19120556@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham Higgins) writes: >++ > gcc: /tmp/cc1000000.cpp cannot find file. > >++ Query: I notice that in your examples, there are 9 characters before the >++ '.cpp' tag on the file. > >Sorry, heavy-handed typing, it should be /tmp/cc100000.cpp. It appears that >the problem arises from GCC's interpretation of pathnames for GNUINC and >a few little problems like requiring quotes surrounding > >setenv GNUINC='c:\gnu\include' > >do the quotes remain for ENVIRON.PRG? If the environment variable is set >by both ENVIRON.PRG and GULAM.PRG, which wins --- and when? If you run ENVIRON in your AUTO folder, every program you spawn from the desktop will get a copy of the values you set with ENVIRON. When Gulam runs and gets a setenv command, the changes that it makes are to the copy of the environment that it received. In this copy, any setenv command will completely replace whatever values it inherited from ENVIRON. If you've got things working with ENVIRON, then you don't need to set them again in Gulam. Please note - in Gulam, you leave out the '=' equals sign in the set[env] commands. e.g. setenv GNUINC c:\gnu\include -- -- Howard Chu @ University of Michigan Mac// - adv., q.v. MacToo, e.g. McHave a McHappy McDay! McThanks, McYou MacToo!
gjh@hplb.hpl.hp.com (Graham Higgins) (11/20/90)
++ Please note - in Gulam, you leave out the '=' equals sign in the set[env] ++ commands. e.g. ++ setenv GNUINC c:\gnu\include I discover that GNUINC (for the uni-sb GCC) needs to be c:/gnu/include --- i.e. forward slashed, not back-slashed --- unless anyone knows different (?). Cheers, Graham ======