Re: ld prints "mangled" error message

Dear Eric:

Thanks for the clarification! I wasn't aware that  'char const *' and
'const char *' are two
alternative spellings of the same type in both C and C++. Btw is this
information available in the standard or is there another place? I would
like to see what other similar alternative spellings are out there that I'm
unaware of.

Thanks for your help! Best wishes,
Gyorgy

On Tue, Apr 5, 2022 at 4:21 PM Eric Blake <[email protected]> wrote:

> On Mon, Mar 28, 2022 at 06:46:03PM -0400, Gyorgy Matyasfalvi wrote:
> > Hello,
> >
> > It looks to me that undefined references to functions taking const
> pointers
> > are reported with a mangled function signature.
> >
> > ```
> >     ld: warning: cannot find entry symbol _start; defaulting to
> > 0000000000401000
> >     ld: main.o: in function `main':
> >     main.cpp:(.text+0x1f): undefined reference to `pc(char const*)'
> > ```
> >
> > I think `pc(char const*)' should be `pc(const char*)'.
>
> Why do you think that?  'char const *' and 'const char *' are two
> alternative spellings of the same type in both C and C++.  At the
> point where the linker cares about type compatibility, the obejct file
> format does not store the spelling used in the source code (*), but
> merely a condensed representation of the type (thanks to the magic of
> name mangling).  So when the linker has to output an error message, it
> reconstitutes a canonical form for spelling the underlying type it is
> reporting about, as read from the object file, with no visibility into
> which of several possible source code spellings were in use when
> building the object file.
>
> (*) The object file format might store the source-code spelling of the
> type in a debug section, but that's a different (and optional) portion
> of the object file, in relation to the portion of the file where the
> linker is trying to satisfy linkage to a mangled name representing a
> specific C++ type.
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>
>