[AD] umain in unsharable part

[m.versteegh@xxxxxxxxxx]

On Sat, Mar 10, 2001 at 12:13:56AM +0200, Juha-Matti Tapio wrote:
> I have been looking into making Python bindings for Allegro (on Linux)
> but I am a bit uncertain on how to handle END_OF_MAIN-trickery.
> 
> Obviously I can't have the main function within the extension module
> because Python interpreter owns the main loop. Can anyone come up with
> a way that doesn't involve patching either Python interpreter or
> Allegro?

This was posted on the [AL] list and reminded me of something

On a related subject:
Some time ago I created fortran bindings for a small part of allegro
(g77, gcc's fortran compiler) in linux.
The problem is that g77 does the same sort of END_OF_MAIN trick as allegro does
to do some 'before-main' fortran initialisations. Luckily the fortran tricks were well
documented, and the docs explained what functions you'd need to call to create
your own main, and as long as you include your own main before
libfc2.a the linker would pick your main (instead of g77's one) and everything would be ok.
Looking in allegro's umain.c shows it's not too hard to add allegro's
initialisation to your own main either.

But...

since allegro's umain.o is put in the shared part of the lib you'll get
duplicate instances of 'main' if you provide your own main (the runtime
linker does not pick the firts main it sees because it can only
load the whole lib as one chunk)  so creating your own main which
does both allegro's initialisation and g77's only works when you
statically link the lib.

So...

I propose we put umain.o in the liballed_unsharable part.

Martijn Versteegh