From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <199807051736.TAA14049@sister.ludd.luth.se>
Subject: Re: Trying to compile v2/alphas/980628/djlsr202.zip
To: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Date: Sun, 5 Jul 1998 19:36:53 +0200 (MET DST)
Cc: djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
In-Reply-To: <9807051601.AA14695@clio.rice.edu> from Charles Sandmann at "Jul 5, 98 11:01:04 am"
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

According to Charles Sandmann:
> > More info on the libemu troubles. As I said before
> > > Error: input file has more than one section; use -M for map
> > 
> > objdump reports four sections on src/emu387.o. This is what dxegen tries
> > ...
> > So where does this .eh_fram section come from?
> 
> This is obviously a new "feature" of 2.8.1 ...  it looks like some 
> exception handling stuff (which probably won't work in a DXE...)

> > lib/dxe.ld (handmade diff):
> >     *(.bss)
> > +    *(.eh_fram)
> >     *(COMMON)

> Excellent analysis and fix.  You get a gold star and an award for creative
> problem solving!

Oh! Thanks. I was wondering who was the author of DXE, because all
troubles are not overcome yet. This change is to use gcc to pick up
the right directories instead of hardcoded values: 
--- src.org/makefile.inc        Sat May 30 21:33:24 1998
+++ src/makefile.inc    Sun Jul  5 04:49:22 1998
@@ -54,7 +54,11 @@
 C = $(LIB)/crt0.o
 L = $(LIB)/libc.a

-LINK = $(CROSS_LD) -s $(LDFLAGS) $(filter %.o,$^) $(filter-out
%.o,$^) -o $@ ${LIB}/libgcc.a -T ${TOP}/../../lib/djgpp.djl
+LINK = $(CROSS_GCC) -s $(LDFLAGS) -nostartfiles $(filter %.o,$^)
$(filter-out %.o,$^) -o $@
 EXE = $(HOSTBIN)/stubify.exe $@

 OBJS := $(addsuffix .o, $(basename $(SRC)))

But then compilation in src/libemu fails. I had to do this change
(handmade patch):
--- src.org/libemu/makefile
+++ src/libemu/makefile
$(BIN)/emu387.dxe : src/emu387.o src/emudummy.o
-       $(HOSTBIN)/dxegen.exe $(BIN)/emu387.dxe __emu_entry src/emu387.o id_emu.o src/emudummy.o -L../../lib -lgcc -lc -lgcc
+       $(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

I. e. hardcode the lib/gcc-lib/djgpp/2.81 directory to make the linker
find the library libgcc.a. This is because dxegen uses ld. So I think
somebody has to in and change dxegen.

Hmm, while writing this the idea (hit me) that perhaps it's possible to use
DXE_LD="gcc -Wl,a,lot,of,options" when compiling dxegen? 

> > So is this the right thing? And what happens when you're compiling on a
> > non-DJGPP platform?

Well, DJ? What happens?


Dead Can Dance, Within the Realm of a Dying Sun,

							MartinS