Message-ID: <3518F5BD.56732C58@cs.joensuu.fi> Date: Wed, 25 Mar 1998 14:17:01 +0200 From: Eugene Ageenko MIME-Version: 1.0 To: Eli Zaretskii , djgpp AT delorie DOT com Subject: Re: Problems with GCC 2.8.0 References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Precedence: bulk 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 . 25.03.98 14:08 . .. 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