Re: Name Mangling changed from egcs 1.1.2 to gcc 2.95

["Brad M. Garcia" <bgarcia at fore dot com>]

On Mon, 1 Nov 1999, Martin v. Loewis wrote:

> Thanks for your bug report. I have problems reproducing that problem,
> though.

This will do it:

junk.cc
-------------------------------------------------------------------------
typedef void snmpSecEnv;

struct snmpGroupProperties;

struct snmpTableGroup {
    void mkGroup(const snmpGroupProperties* a1,
                 const snmpSecEnv* a2, const void* a3);
};

void snmpTableGroup::mkGroup(const snmpGroupProperties* a1,
                             const snmpSecEnv* a2, const void* a3) {
}
-------------------------------------------------------------------------

gcc 2.95 gives:
    mkGroup__14snmpTableGroupPC19snmpGroupPropertiesPCvT2

egcs 1.1.1 gives:
    mkGroup__14snmpTableGroupPC19snmpGroupPropertiesPCvPCv

I guess egcs 1.1.1 did the name-mangling compression before resolving
typedefs, thus missing this case.

Unfortunately, the act of fixing that little bug has resulted in what
basically amounts to a new name-mangling strategy.  So you can no longer
link together code compiled with gcc 2.95 with code compiled with egcs
1.1.2.  It would be good if a backwards-compatibility flag could be
added.

> I don't know how you've produced the other symbol; whatever compiler
> did so, it was a bug in that compiler (perhaps an egcs snapshot??)

It was the released version of 1.1.1.
I've confirmed that 1.1.2 does the same thing as 1.1.1.

> No. The linker is not involved with C++ mangling. There is one thing
> you can do: write an assembler file (by hand), implementing the
> missing symbol by jumping to the existing one.

If this was the only symbol that had the problem, I would do that.
I was hoping for a more generic solution.  Oh well.

Brad Garcia
   ___/  __ /  __ /  ___/ "...there is only about a one in 1,700 chance
  __/   /  /  / _/  __/       that it is due to chance." 
_/    ____/ _/ _| ____/    - Dr John Murray, of the UK's Open University