undefined reference to _main

Brynet-Inc · Post by **Brynet-Inc** » Fri Dec 14, 2007 10:58 am

I doubt C++ would mangle the main function, because that's a programs entry point. (Often called by the crt0 object, which is typically written in assembler.)

My advice to the OP, Was to use nm.. and that should have been the end of this topic

People often get confused by the differences between main and _main, Which I believe was the case..

bluecode · Post by **bluecode** » Fri Dec 14, 2007 11:19 am

JamesM wrote:
bluecode wrote:The leading underscore has nothing to do with C++ name-mangling. It is possible to use the -fleading-underscore / -fno-leading-underscore option with gcc and g++ (iirc there is also a configure switch for that, look for yourself), look into the gcc manuals.
I know this. What made you assume we didn't?

Craze frogs post and yours. extern "C" won't fix anything here. Because if g++ prepends an underscore to a function name, than gcc would do the same thing, so the extern "C" would not remove the underscore. IMHO, but I am not 100% sure about that.

Tyler · Post by **Tyler** » Fri Dec 14, 2007 1:09 pm

bluecode wrote:
JamesM wrote:
bluecode wrote:The leading underscore has nothing to do with C++ name-mangling. It is possible to use the -fleading-underscore / -fno-leading-underscore option with gcc and g++ (iirc there is also a configure switch for that, look for yourself), look into the gcc manuals.
I know this. What made you assume we didn't?
Craze frogs post and yours. extern "C" won't fix anything here. Because if g++ prepends an underscore to a function name, than gcc would do the same thing, so the extern "C" would not remove the underscore. IMHO, but I am not 100% sure about that.

Solar wrote:

GCC does whatever you told it in its configuration.

Candy · Post by **Candy** » Fri Dec 14, 2007 1:15 pm

JamesM wrote:The question has been answered already... C++ mangles identifiers. extern "C" will fix it.

No.

GCC adds underscores to be compatible with some horrendously outdated systems. It was introduced to avoid a name clash between Fortran functions and the new C functions. Windows adopted the underscores too and set it in stone. GCC now by default adds it in Windows and a few obscure unices that use mainly Fortran, and not in all the rest. If you're making a new system, please don't add the underscores again.

If GCC mangled the name with C++ mangling it would be _Z4mainiPKc, not main. It doesn't, because there's a special thing in C++ that makes main a special never-mangled function for C compatibility. In Windows it would be __Z4mainiPKc or _main, depending on whether it's mangled as C++ or not.

bluecode · Post by **bluecode** » Fri Dec 14, 2007 1:46 pm

@Tyler: Yes I know that it has been answered by Solar, but the others were just wrong (and nobody said that so far except me). Can we close that case now?

btw. Candy is saying the same thing yet again

Craze Frog · Post by **Craze Frog** » Fri Dec 14, 2007 2:50 pm

bluecode wrote:
JamesM wrote:
bluecode wrote:The leading underscore has nothing to do with C++ name-mangling. It is possible to use the -fleading-underscore / -fno-leading-underscore option with gcc and g++ (iirc there is also a configure switch for that, look for yourself), look into the gcc manuals.
I know this. What made you assume we didn't?
Craze frogs post and yours. extern "C" won't fix anything here. Because if g++ prepends an underscore to a function name, than gcc would do the same thing, so the extern "C" would not remove the underscore. IMHO, but I am not 100% sure about that.

Sure it does have to do with C++ name mangling. It's a C++ function that is called main that isn't called main in the output object. That means it's mangled, and it's definetely not Pascal name mangling. The page I linked to explained that name mangling is implementation defined, which means that the main function is not necessary mangled in the same way as other functions. In the particular implementation of g++ C++ name mangling of the main function is just the same as the C function.

I also never said that "extern C" would fix it.

Candy · Post by **Candy** » Sun Dec 16, 2007 3:58 pm

Craze Frog wrote:Sure it does have to do with C++ name mangling. It's a C++ function that is called main that isn't called main in the output object. That means it's mangled, and it's definetely not Pascal name mangling.

It isn't c++ name mangling. There's a very clear ABI on how GCC f.ex. mangles names, and it doesn't include any _main. Especially given the 30+ threads about this exact problem that we've seen before.

Craze Frog · Post by **Craze Frog** » Mon Dec 17, 2007 7:42 am

It isn't c++ name mangling.

Then what is it?

Tyler · Post by **Tyler** » Mon Dec 17, 2007 7:55 am

Craze Frog wrote:
It isn't c++ name mangling.
Then what is it?

Protection from Fortran names, i believe was mentioned earlier. It's a C thing, not C++, and only implemented if you tell GCC to support it when configuring it.

Craze Frog · Post by **Craze Frog** » Mon Dec 17, 2007 10:32 am

Umm, I think you misunderstood something. It's not the way of mangling that matters, it's the source language.

As an example, consider void h(int) from wikipedia. VC++ mangles it as ?h@@YAXH@Z, Intel mangles it as _Z1hi and Borland as @h$qi. Still, all are C++ name manglings. Why? Because C++ was the source language. Not because they are mangled in a particular way. So even if some C++ identifiers are mangled in exactly the same way as C identifiers, that doesn't make it C name mangling. It's just means it's the same as C mangling.

AJ · Post by AJ » Mon Dec 17, 2007 11:05 am

It's the purpose of the mangling here that defines it.

When a C/C++ compiler adds a leading underscore, it is to protect that function, so that any other functions with the same name do not end up with the same symbol.

The purpose of name mangling (as it is widely understood and defined by the standard) is completely different. The reason for this is to allow function overloading (so that you can have int myfunction() and int myfunction(int, int), for example) and classes with the same function names. It is up to the compiler how this is achieved, but for any given compiler, it will be defined in the ABI.

I absolutely agree that _main is a 'mangled name' in the colloquial English definition of 'mangled'. It is not, however, an example of C++ name mangling.

Time to drop this thread yet?

Cheers,
Adam

Candy · Post by **Candy** » Mon Dec 17, 2007 12:23 pm

Craze Frog wrote:Umm, I think you misunderstood something. It's not the way of mangling that matters, it's the source language.

Read the ABI. It specifically says that main is not mangled as per that spec, the rest is.

As an example, consider void h(int) from wikipedia. VC++ mangles it as ?h@@YAXH@Z, Intel mangles it as _Z1hi and Borland as @h$qi. Still, all are C++ name manglings. Why? Because C++ was the source language. Not because they are mangled in a particular way. So even if some C++ identifiers are mangled in exactly the same way as C identifiers, that doesn't make it C name mangling. It's just means it's the same as C mangling.

There are three ABI's in use, the Microsoft one, the Borland one and the rest-of-the-world one. None of these three manglings give you _main in any possible way according to their syntax rules - they all specify it as an *exception* to those rules. Exception means it is not mangled.

Craze Frog · Post by **Craze Frog** » Tue Dec 18, 2007 9:53 am

Read the ABI. It specifically says that main is not mangled as per that spec, the rest is.

That's what I said. Just because it's mangled in a different way doesn't mean it's not mangled.

Solar · Post by **Solar** » Wed Dec 19, 2007 2:28 am

According to the C++ standard draft, "The linkage (basic.link) of main is implementation-defined."

So, both sides are "right" somehow: Formally, it is not said that main() is not mangled, but practically it's never mangled because that would require a C++-aware linker, which does not exist to my knowledge.