Re: [AD] umain in unsharable part

[m.versteegh@xxxxxxxxxx]

> 
> But even if the END_OF_MAIN trickery doesn't gain anything very
> significant on Unix, there's no argument for removing it because
[snip]

I don't think we should remove it. Just remove umain.o to the
liballeg_unsharable part of the lib.

> 
> I wasn't aware of the problem with overriding functions in
> shared libraries.  Actually, it seems to work, apart from the
> complaint about `_mangled_main_address' -- if this variable
> exists (a void *, but that doesn't matter much), then there's no
> problem linking, and my main function was called in preference
> to Allegro's.  I don't know how reliable this is though.

Hmm.  Doesn't the complaining about _mangled_main_adress mean that
umain.o is linked in the executable, since that's the place the thing
is defined, and also the only place it's used?
If you do a static linking not using END_OF_MAIN and providing
your own main() before linkeing with allegro you don't get
any complaintes at all.
So I'd say you get 2 main symbols in one executable, which
feels wrong to me.

Surely putting the umain.o file in liballeg_unsharable cannot do  any harm?
it a very small function anyway.

> 
> Something else which may be useful is the linker's `wrapper'
> feature, allowing you to rename a symbol from one object file
> making it appear differently to the others.  You could use this
> to rename the Fortran or Python `main' function to something
> else (e.g. Allegro's `_mangled_main'), and set up the
> _mangled_main_address variable as Allegro expects, pointing at
> this function.  That all feels rather hairy, though.

I did try this approach, but didn't succeed. But I was in a hurry, so
I'm not sure I didn't overlook something ;-)