Message-ID:	<3518F5BD.56732C58@cs.joensuu.fi>
Date:	Wed, 25 Mar 1998 14:17:01 +0200
From:	Eugene Ageenko <ageson AT cs DOT joensuu DOT fi>
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp AT delorie DOT com
Subject:	Re: Problems with GCC 2.8.0
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 980325084712 DOT 27363A-100000 AT is>

Eli Zaretskii wrote:
> 
> On Tue, 24 Mar 1998, Eugene Ageenko wrote:
> 
> > It was because the long file name problem.
> >
> > The default value for LFn was "n" (?)
> >
> > So that it causes the problem to proceede with temporary files
> > during compilation.
> >
> > c:/djgpp/tmp/ccaaaaaa2.o(.text+0xc):module.c: multiple definition of
> > `hello'
> > c:/djgpp/tmp/ccaaaaaa1.o(.text+0xc):module.c: first defined here
> > c:/djgpp/lib/crt0.o(.data+0x92):crt0.s: undefined reference to
> > `main'
> > c:/djgpp/lib/libc.a(crt1.o)(.text+0x312):crt1.c: undefined reference
> > to `main'
> >
> > making it "y" made it OK.
> 
> Eugene, are you absolutely sure about the ccaaaaaa1.o names?  There
> shouldn't be more than 8 characters in the names of the temporary
> files, so please make sure the above is an exact quote of the error
> messages.
> 


Ok. As you could see the above output was printed to stderr in case
option -v was not given, now read the output for the -v option (LFN=n)

Here is your output

Reading specs from c:/djgpp/lib/specs
gcc version 2.8.0
 c:/djgpp/lib/gcc-lib/djgpp/2.80/cpp.exe -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__
-D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 test.c c:/djgpp/tmp/ccaaaaaa.i
GNU CPP version 2.8.0 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 c:/djgpp/include
 c:/djgpp/lib/gcc-lib/djgpp/2.80/include
 c:/djgpp/include
End of search list.
 c:/djgpp/lib/gcc-lib/djgpp/2.80/cc1.exe c:/djgpp/tmp/ccaaaaaa.i -quiet -dumpbase test.c -version -o c:/djgpp/tmp/ccaaaaaa.s
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
 c:/djgpp/lib/gcc-lib/djgpp/2.80/cpp.exe -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__
-D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 module.c c:/djgpp/tmp/ccaaaaaa.i
GNU CPP version 2.8.0 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 c:/djgpp/include
 c:/djgpp/lib/gcc-lib/djgpp/2.80/include
 c:/djgpp/include
End of search list.
 c:/djgpp/lib/gcc-lib/djgpp/2.80/cc1.exe c:/djgpp/tmp/ccaaaaaa.i -quiet -dumpbase module.c -version -o c:/djgpp/tmp/ccaaaaaa.s
GNU C version 2.8.0 (djgpp) compiled by GNU C version 2.8.0.
 c:/djgpp/bin/as.exe -o c:/djgpp/tmp/ccaaaaaa2.o c:/djgpp/tmp/ccaaaaaa.s
 c:/djgpp/bin/ld.exe -o test c:/djgpp/lib/crt0.o -Lc:/djgpp/lib -Lc:/djgpp/lib/gcc-lib/djgpp/2.80 -Lc:/djgpp/lib c:/djgpp/tmp/ccaaaaaa1.o c:/djgpp/tmp/ccaaaaaa2.o -Tdjgpp.djl -lgcc -lc -lgcc
c:/djgpp/tmp/ccaaaaaa2.o(.text+0xc):module.c: multiple definition of `hello'
c:/djgpp/tmp/ccaaaaaa1.o(.text+0xc):module.c: first defined here
c:/djgpp/lib/crt0.o(.data+0x92):crt0.s: undefined reference to `main'
c:/djgpp/lib/libc.a(crt1.o)(.text+0x312):crt1.c: undefined reference to `main'


> It would be very helpful if you could actually post everything GCC
> printed when you add -v to the command line.
> 

Now if I set LFN=y then it says:

Reading specs from c:/djgpp/lib/specs
gcc version 2.8.0
 c:/djgpp/lib/gcc-lib/djgpp/2.80/cpp.exe -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__
-D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 test.c c:/djgpp/tmp/ccaaaaaa.i
GNU CPP version 2.8.0 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 c:/djgpp/include
 c:/djgpp/lib/gcc-lib/djgpp/2.80/include
 c:/djgpp/include
End of search list.
 c:/djgpp/lib/gcc-lib/djgpp/2.80/cc1.exe c:/djgpp/tmp/ccaaaaaa.i -quiet -dumpbase test.c -version -o c:/djgpp/tmp/ccaaaaaa.s
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
 c:/djgpp/lib/gcc-lib/djgpp/2.80/cpp.exe -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__
-D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 module.c c:/djgpp/tmp/ccaaaaaa.i
GNU CPP version 2.8.0 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 c:/djgpp/include
 c:/djgpp/lib/gcc-lib/djgpp/2.80/include
 c:/djgpp/include
End of search list.
 c:/djgpp/lib/gcc-lib/djgpp/2.80/cc1.exe c:/djgpp/tmp/ccaaaaaa.i -quiet -dumpbase module.c -version -o c:/djgpp/tmp/ccaaaaaa.s
GNU C version 2.8.0 (djgpp) compiled by GNU C version 2.8.0.
 c:/djgpp/bin/as.exe -o c:/djgpp/tmp/ccaaaaaa2.o c:/djgpp/tmp/ccaaaaaa.s
 c:/djgpp/bin/ld.exe -o test c:/djgpp/lib/crt0.o -Lc:/djgpp/lib -Lc:/djgpp/lib/gcc-lib/djgpp/2.80 -Lc:/djgpp/lib c:/djgpp/tmp/ccaaaaaa1.o c:/djgpp/tmp/ccaaaaaa2.o -Tdjgpp.djl -lgcc -lc -lgcc
 c:/djgpp/bin/stubify.exe -v test

> Assuming the above is accurate, Robert, can you please help explaining
> this?  I fail to understand how come GCC 2.8.0 generates names for
> temporary files which have more than 8 characters (`ccaaaaaa1' is 9).
> Library functions which do that never exceed 8+3 limits, so how can
> the above happen?
> 

Keep me in touch please.

> > It was said that problem might be using short names or so on.
> > Nothing said about default status of LFN, said that distribution is
> > ready to run.
> 
> The above problem should never had happened.  Temporary files should
> work regardless of LFN.  If they don't, that's a bug that should be
> corrected, and corected *fast*.
> 

Hope so.

> > > > 1611416  02-02-98  22:55   lib/gcc-lib/djgpp/2.80/cc1plus.exe
> >
> > Oops. in strange place.
> 
> In GCC 2.8.0, all the compiler passes are stored in that directory,
> since you are not supposed to invoke them directly.
> 

Ok. It is the feature of GCC 2.8.0

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.

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.


 Volume in drive D is WORK       
 Directory of D:\Test\Test

.              <DIR>        25.03.98  14:08 .
..             <DIR>        25.03.98  14:08 ..
TEST     C             236  23.03.98  15:51 TEST.C
         1 file(s)            236 bytes
         2 dir(s)     576 462 848 bytes free

Of course you can type it in small letters, but using wildcards or so name would be
expanded as TEST.C, thats the problem. (And under DOS, C++ files were always .cpp,
since ".c"=".C" from DOS point of view)

You can complain that file name would be expanded as "test.c", so right, but 
under DOS 6.22 or below only. Under W95 in DOS-box, it would be always expanded
as "TEST.C" (See RIGHT column in DIR printing).

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. 

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.

That's the message.

If LFN=y then everything is allright and no problem.

Anyway I like this LFN featurem, that I have some software from UNIX where files are
typed with long names.

Regards: Eugene

- Raw text -