[gccsdk] gcc does not like _main

Jan-Jaap van der Geer jjvdgeer at inbox.com
Tue May 12 14:09:09 PDT 2009

Ben Avison <bavison at riscosopen.org> wrote:

> On Sun, 2009-04-26 at 20:48 +0100, John Tytgat wrote:
> > _main is what we have in UnixLib wrapping the user supplied
> > main() and not as is replaceble. As far as I remember, all
> > identifiers starting with an underscore are reserved for user
> > code so a bit questionable that Vala uses this.

> Identifiers starting with two underscores, or one underscore
> followed by a capital letter, are the ones that are reserved to
> the C runtime library. So Vala is within its rights to use
> "_main" according to the C standard, and I'd argue UnixLib should
> be changed.

> You'll note that the shared C library doesn't export a "_main"
> symbol (even though it defines one for internal use).

Not really knowing what I was doing, but inspired by this comment,
I went looking for this _main function. I did not find the actual
definition, but I did find a header file with this line:

extern int _main (void);

in gccsdk/gcc4/recipe/files/libunixlib/incl-local/internal/unix.h

I commented it out to see what happens. To my surprise, everything
seemed fine when I build the compiler after that.

I build a RISC OS compiler and run that. Using this I can compile
programs that define a _main, while the release version fails. So
it seems to me we should just remove that extern line, but then I
hardly know what I am talking about...

Should I commit this change?

On a whole different subject, even though I build the compiler with
"./build-it -static riscos", the final result contains ELF files.
Had not used shared libraries on RISC OS before, but it looks very
neat to me. Strange thing though, using the compiler, I get this

*gcc test.c
/ADFS::HardDisc4.$/Projects/GCC4/MyOwnBuild/!GCC/bin/ld: warning:
libgcc_s.so.1, needed by /GCCSOLib:/libunixlib.so, not found (try
using -rpath or -rpath-link)


*info sharedlibs:lib.libgcc_s/so/1
libgcc_s/so/1 WR/R    ELF       22:29:54 12-May-2009  172 Kbytes

it seems to be there... Why is this?

GCC does not seem to know about -rpath[-link] so I am not sure
where the -rpath[-link] should be used.

(The compilation went just fine, BTW)


More information about the gcc mailing list