Date: Sat, 4 Jul 1998 18:18:20 -0400 (EDT) Message-Id: <199807042218.SAA18906@delorie.com> From: DJ Delorie To: ams AT ludd DOT luth DOT se CC: djgpp-workers AT delorie DOT com In-reply-to: <199807042204.AAA01315@sister.ludd.luth.se> (message from Martin Str|mberg on Sun, 5 Jul 1998 00:04:19 +0200 (MET DST)) Subject: Re: Trying to compile v2/alphas/980628/djlsr202.zip natively Precedence: bulk > 1. Where is libc/compat/stdio/vfscanf.c? It's vfscanf.S, not vfscanf.c. > 2. I'm using gcc281b.zip, so this happens: > ld -s ../../../lib/crt0.o symify.o ../../../lib/libdbg.a ../../../lib/libc.a -o ../../../bin/symify.exe ../../../lib/libgcc.a -T ../../../lib/djgpp.djl > E:/DJGPP.202/BIN/ld.exe: cannot open ../../../lib/libgcc.a: No such file or directory (ENOENT) > > as libgcc.a lives in ..../../lib/gcc-lib/djgpp/2.81. How should this > really be setup to be portable? We'd need to convert it to use $(CROSS_GCC) instead of ld, so that gcc can locate these files. > 3. After a while the making stops because it don't know how to make > makefile.oh. I corrected this by changing top level makefil.inc from: Looks good to me but I'll check it after I apply it. > 4. Later on this: > makemake: scanning libemu for object files > make ./../../lib/libemu.a > make.exe[2]: `../../lib/libemu.a' is up to date. > ./../../hostbin/dxegen.exe ./../../bin/emu387.dxe __emu_entry src/emu387.o id_emu.o src/emudummy.o -L../../lib -L../../lib/gcc-lib/djgpp/2.81 -lgcc -lc -lgcc > ld -X -S -r -o dxe__tmp.o -Le:/djgpp.202/lib src/emu387.o id_emu.o src/emudummy.o -L../../lib -L../../lib/gcc-lib/djgpp/2.81 -lgcc -lc -lgcc -T dxe.ld > Error: input file has more than one section; use -M for map > make.exe[1]: *** [../../bin/emu387.dxe] Error 1 > > Ughh! What to do now? Last time I saw this, it happened because dxegen wasn't handling endianness or structure sizes in a portable way, so the COFF headers get mangled.