Mail Archives: djgpp/1998/03/25/08:03:58
On Wed, 25 Mar 1998, Eugene Ageenko wrote:
> GNU C version 2.8.0 (djgpp) compiled by GNU C version 2.8.0.
> c:/djgpp/bin/as.exe -o c:/djgpp/tmp/ccaaaaaa1.o c:/djgpp/tmp/ccaaaaaa.s
^^^^^^^^^^^
Thanks for posting this.
Robert, it seems this is indeed some problem in GCC 2.8.0: it should have
never produce a name of a temporary file name which exceeds 8+3 DOS
limits. How could that happen?
> Now about difference between .c and .C
>
> From my point of it must be no difference if LFN set to "n". Why?
> because from DOS point of view (where are only short names) all file-names
> are given in CAPITAL letters by DEFAULT.
DOS is case-insensitive, but GCC is not. DOS case-insensitivity has
nothing to do with the way GCC gets its command-line arguments. These
arguments are NOT converted to lower-case, since the startup code doesn't
know which arguments are file names and which aren't (it cannot
lower-case everything because e.g. the -O switch is different from -o).
> So, even under W95, if I use program (say my favourite text editor), that does not
> support long names, is stores files in capital letters.
I'd say it's a bug in that editor. For example, Emacs will let you save
the file as either README or readme or REadme, as you wish. It is not a
buisness of an editor to decide how would you like to name your files.
> if I rename "ren test.c test.c" then program will go, since it would be so:
>
> But it is to difficult to rename all files always.
Well, how about switching the editors, then? ;-)
> I think as option LFN=n eliminate *ALL* long-name features (so it would not
> compile "gcc -c MyProgram.c") it MUST also treat TEST.C as test.c -> .c file,
> not .C, since under DOS (short names only) they are EQUIALENT.
The problem is that GCC gets a long command line, where it is very hard
to decide which arguments are file names. And without that distinction
you cannot lower-case the file names.
- Raw text -