Mail Archives: djgpp-workers/2002/06/13/14:44:21
> > I think we should rationalize how we want to support all the
> > internationalization (instead of 1Mb of linked data in each image)
> > at the same time.
>
> It would be great if we could use a DXE for that, if we can keep the
> exe's footprint small enough.
I have a prototype in my v2.04 cvs work area which allows both multiple
symbol exports and imports from the main image. It analyzes the DXE
you propose to build, creates a transfer vector, and an interface
.o which looks like the library calls normally might.
It's completely backward compatible with the current DXE, the
loader size is similar to the DXE footprint (a few hundred bytes).
The tools to keep transfer vectors consistent if you add something
doesn't work properly, there's a little problem with statics (like
errno) which you want to be external when linking. The current
libc has multiple procedures/declarations in some modules which
need to be split up. There are C++ issues I haven't messed with.
I don't have libc working that way yet.
I haven't analyzed how many sharable modules there should be, or
what should be in them.
- Raw text -