🚀 go-pugleaf

The call to it support the proper execution of mixed (C and C++) programs
that have a C main.  The support is on purpose and unless you can come up
with a good reason, will always be in FSF released gcc.

Why can you not have libgcc.a available to link against?  I cannot think
of any good reasons.

The _start idea does not work, because the _start used is vendor
supplied, and we have no control over it.  There is also little
desire to provide one, just look at GNU emacs for reasons as I
understand them.

You are using gcc in non-standard ways, therefore you have to expect to
go to a little extra work.  If you had not defeated the inclusion of
libgcc.a on a link line, the problem would not exist, right?

For you, the solution may be to just comment out the call to
expand_main_function.  Seems really easy, simple to maintain, and will
always work.  Why can't you just bite the bullit on this one?

> Message-Id: <9204150101.AA18863@life.ai.mit.edu>
> From: Christopher Maeda <cmaeda@mc8.mach.cs.cmu.edu>
> Date: Tue, 14 Apr 92 20:59:55 EDT
> To: bug-gcc@prep.ai.mit.edu
> Cc: cmaeda@cs.cmu.edu
> Subject: __main
> Reply-To: cmaeda@cs.cmu.edu

> Why do all C programs call __main?  The change logs seem to say __main
> is for C++ programs and shared libraries.

> The reason I care or even know about this is that I'm using gcc2 to
> build mach kernels which are not linked against gcc's libraries.
> Thus, I either have to stick a null definition of __main in mach's
> libraries or convince you that two wrongs don't make a right.  I
> clearly don't need whatever __main provides and it's a bug that I
> should even have to think about it.

> A less intrusive approach to this might be to fold __main into
> __start.  Then if you don't link with the gnu __start (or whatever
> function is in crt0), you don't have to worry about __main.