Re: Problems with main

[Nicola Pero]

> Hi,
> 
> since I have upgraded to RH7.2 and since I started to use recent CVS code 
> again, I have the problem that configure does not do its job correctly
> (anymore!), I always have to pass --enable-fake-main manually, otherwise
> GNUstep wouldn't work.

If you're using RH 7.2 on linux, you shouldn't be enabling fake-main !

fake-main is a ugly hack, you don't want to use it unless it's the only
available trick on your system to have NSProcessInfo work.  On RH 7.2, the
base library determines program name and arguments by having code inside
NSProcessInfo's +load (which is executed before main) which determines the
program names and arguments by extracting them from the /proc filesystem,
and saving them.  It's very perverse or very clever depending on the point
of view :-) but it works very well, and it works without any help from the
programmer (while fake-main is much more delicate, it works by redefining
main and only works if you #include/#import Foundation/Foundation.h in the
file in which you implement main (and before main) ... and for example
fake-main wouldn't automatically work if you dynamically load gnustep-base
inside a third-party environment ... you need to help NSProcessInfo
manually to have it work in that case ... most likely, you can't get the
program arguments at all).

On RH 7.2 on linux, configure should give you the following results - 

checking if +load method is executed before main... yes

checking kernel support for /proc filesystem... yes

checking use of fake-main definition... no

My suggestion is first, to check that all gnustep-base configure files are
exactly the same as on CVS.  I sometime used to run 'autoreconf' thinking
that would fix things, and that would break them instead :-).  You detect
and fix these problems by checking that the configure files are the same
as on CVS.

Once you're sure your CVS is not messed up, run 'make distclean' (inside
gnustep-base).

Then, run ./configure (inside gnustep-base), and check that the fake-main
related check results are the same as I listed you above ... If any of
those are different, you need to try and understand why, or at least
report exactly what's wrong (why the configuration step fails if you can
figure that out) or all useful information about what can cause it to go
wrong, so that if it's a bug, we can fix it.

If instead all the checks run correctly, try compiling and installing
(gnustep-base) ... at that point every gnustep-base tool should work -
launch 'defaults read', if that runs, it's Ok ... you likely will need to
recompile every other tool/application after you have installed the new
working gnustep-base library, but once you recompile them, they should
work.