Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.os2.programmer.misc > #400 > unrolled thread

C++ library names

Back to article view | Back to comp.os.os2.programmer.misc

Contents

  C++ library names James Moe <jimoeDESPAM@sohnen-moe.com> - 2011-09-09 01:32 -0700
    Re: C++ library names Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-09 08:05 -0400
      Re: C++ library names Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-09-09 15:25 +0000
    Re: C++ library names KO Myung-Hun <komh@chollian.net> - 2011-09-09 21:09 +0900
    Re: C++ library names Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-09-09 13:17 +0100
    Re: C++ library names "Lars Erdmann" <lars.erdmann@arcor.de> - 2011-09-10 10:23 +0200
      Re: C++ library names Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-10 07:25 -0400
      Re: C++ library names Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-09-12 17:24 +0100
        Re: C++ library names Goran <goran.pusic@gmail.com> - 2011-09-13 00:24 -0700
          Re: C++ library names Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-13 07:22 -0400
            Re: C++ library names Goran <goran.pusic@gmail.com> - 2011-09-13 05:06 -0700
    Re: C++ library names James Moe <jimoeDESPAM@sohnen-moe.com> - 2011-09-10 12:15 -0700
      Re: C++ library names "Rich Walsh" <spamyourself@127.0.0.1> - 2011-09-11 03:08 +0000
        Re: C++ library names Marty <net@comcast.martyamodeo> - 2011-09-15 10:03 -0700
          Re: C++ library names "Lars Erdmann" <lars.erdmann@arcor.de> - 2011-09-15 19:46 +0200

#400 — C++ library names

Hello,
  Is it to be expected that different C++ compilers produce libraries
with completely different public function names?
  For instance, I have the Xerces 2.2.0 XML library DLL produced by
VAC365 or VAC400, and trying to compile a program with GCC 3.3.5 against
that library. The linker is not happy:

weakld: error: Unresolved symbol (UNDEF)
'__ZN11xercesc_2_316XMLPlatformUtils9TerminateEv'.

The corresponding entry in the DLL .lib file is:
Terminate__16XMLPlatformUtilsFv

  The disparity in the expected and actual public symbols make using the
DLL rather a challenge.
  Is there any way to resolve this? (Besides compiling xerces from the
source?)

-- 
James Moe
jmm-list at sohnen-moe dot com

[toc] | [next] | [standalone]

#402

I don't use C++, but I believe this is a common problem.

On 9/9/2011 4:32 AM, James Moe wrote:
> Hello,
>    Is it to be expected that different C++ compilers produce libraries
> with completely different public function names?
>    For instance, I have the Xerces 2.2.0 XML library DLL produced by
> VAC365 or VAC400, and trying to compile a program with GCC 3.3.5 against
> that library. The linker is not happy:
>
> weakld: error: Unresolved symbol (UNDEF)
> '__ZN11xercesc_2_316XMLPlatformUtils9TerminateEv'.
>
> The corresponding entry in the DLL .lib file is:
> Terminate__16XMLPlatformUtilsFv
>
>    The disparity in the expected and actual public symbols make using the
> DLL rather a challenge.
>    Is there any way to resolve this? (Besides compiling xerces from the
> source?)
>

[toc] | [prev] | [next] | [standalone]

#405

On 2011-09-09, Peter Flass <Peter_Flass@Yahoo.com> wrote:
> I don't use C++, but I believe this is a common problem.

This is not "a problem"; it is one of the design decisions.  One which
SOM was supposed to fight...

Hope this helps,
Ilya

[toc] | [prev] | [next] | [standalone]

#403

Hi/2.

James Moe wrote:
> Hello,
>    Is it to be expected that different C++ compilers produce libraries
> with completely different public function names?

Yes. To avoid this, you should use 'extern "C"', in case of a DLL on 
OS/2, APIENTRY, which is _System, as well.

>    For instance, I have the Xerces 2.2.0 XML library DLL produced by
> VAC365 or VAC400, and trying to compile a program with GCC 3.3.5 against
> that library. The linker is not happy:
>
> weakld: error: Unresolved symbol (UNDEF)
> '__ZN11xercesc_2_316XMLPlatformUtils9TerminateEv'.
>
> The corresponding entry in the DLL .lib file is:
> Terminate__16XMLPlatformUtilsFv
>
>    The disparity in the expected and actual public symbols make using the
> DLL rather a challenge.
>    Is there any way to resolve this? (Besides compiling xerces from the
> source?)
>

I think, recompiling the sources is the best and easy way.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.3
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1GHz with 512 MB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

[toc] | [prev] | [next] | [standalone]

#404

> Is there any way to resolve this? (Besides compiling xerces from the source?)

No.

[toc] | [prev] | [next] | [standalone]

#407

This "problem" is called "name mangling" and every C++ compiler will produce 
different function names (Watcom, Borland, IBM, etc.) .

The best solution would be to export the public DLL functions with SYSTEM 
calling convention.
If you have the sources to the DLL, that would be the way to go. The header 
file listing the public functions should then
explicitely specify SYSTEM to be the calling convention.

Then, you can use the DLL with any other compiler that supports SYSTEM 
calling convention which all OS/2 compilers do as it is the default
calling convention of the OS.

I don't know if builing with SYSTEM calling convention will prevent C++ 
specific things like inheritance and polymorphism as I know too little about 
C++.
In the latter case you will need to build the DLL with the same compiler 
that is used to build the application using the DLL.

Lars


"James Moe" <jimoeDESPAM@sohnen-moe.com> schrieb im Newsbeitrag 
news:-N-dnagR4OiAUvTTnZ2dnUVZ5oWdnZ2d@giganews.com...
> Hello,
>  Is it to be expected that different C++ compilers produce libraries
> with completely different public function names?
>  For instance, I have the Xerces 2.2.0 XML library DLL produced by
> VAC365 or VAC400, and trying to compile a program with GCC 3.3.5 against
> that library. The linker is not happy:
>
> weakld: error: Unresolved symbol (UNDEF)
> '__ZN11xercesc_2_316XMLPlatformUtils9TerminateEv'.
>
> The corresponding entry in the DLL .lib file is:
> Terminate__16XMLPlatformUtilsFv
>
>  The disparity in the expected and actual public symbols make using the
> DLL rather a challenge.
>  Is there any way to resolve this? (Besides compiling xerces from the
> source?)
>
> -- 
> James Moe
> jmm-list at sohnen-moe dot com 

[toc] | [prev] | [next] | [standalone]

#408

On 9/10/2011 4:23 AM, Lars Erdmann wrote:
> This "problem" is called "name mangling" and every C++ compiler will
> produce different function names (Watcom, Borland, IBM, etc.) .

Yes, it is the fact that every compiler does it differently that is the 
problem.

[toc] | [prev] | [next] | [standalone]

#413

> This "problem" is called "name mangling" [...]

No it isn't.  It's many programmers' simplistic statement of the 
problem, but name mangling is merely a symptom of the actual problem, 
which is a lack of binary compatibility across compilers, which 
stretches to a lot more things than just symbol names.  M. Zakharevich 
hit the nail squarely on the head:  DirectToSOM C++ solves this.  It's a 
pity that (a) the class library wasn't compiled to SOM by the IBM 
compiler, and (b) GCC isn't capable of DirectToSOM C++.

[toc] | [prev] | [next] | [standalone]

#414

On Sep 12, 6:24 pm, Jonathan de Boyne Pollard <J.deBoynePollard-
newsgro...@NTLWorld.COM> wrote:
> > This "problem" is called "name mangling" [...]
>
> No it isn't.  It's many programmers' simplistic statement of the
> problem, but name mangling is merely a symptom of the actual problem,
> which is a lack of binary compatibility across compilers, which
> stretches to a lot more things than just symbol names.  M. Zakharevich
> hit the nail squarely on the head:  DirectToSOM C++ solves this.  It's a
> pity that (a) the class library wasn't compiled to SOM by the IBM
> compiler, and (b) GCC isn't capable of DirectToSOM C++.

Binary compatibility? Meh. C and C++ as __languages__ do not have
that.

I personally am not a fan of binary compatibility and I believe people
are overrating this. If code from different toolchains or languages
needs to speak to each other, there's integration technologies. One of
them is called "the C interface used by the platform (OS)". That's a
dumb one (effective, though, and any monkey gets it). There's more
(or, rather, very) complex stuff like COM of MS. There's also "VM as
integration technology" (Java, .NET). Finally, there's also "one
compiler version integration" of C++. There's all this choice since
forever.

We would gain little with putting binary compatibility into C or C++.

Goran.

[toc] | [prev] | [next] | [standalone]

#415

On 9/13/2011 3:24 AM, Goran wrote:
> On Sep 12, 6:24 pm, Jonathan de Boyne Pollard<J.deBoynePollard-
> newsgro...@NTLWorld.COM>  wrote:
>>> This "problem" is called "name mangling" [...]
>>
>> No it isn't.  It's many programmers' simplistic statement of the
>> problem, but name mangling is merely a symptom of the actual problem,
>> which is a lack of binary compatibility across compilers, which
>> stretches to a lot more things than just symbol names.  M. Zakharevich
>> hit the nail squarely on the head:  DirectToSOM C++ solves this.  It's a
>> pity that (a) the class library wasn't compiled to SOM by the IBM
>> compiler, and (b) GCC isn't capable of DirectToSOM C++.
>
> Binary compatibility? Meh. C and C++ as __languages__ do not have
> that.
>
> I personally am not a fan of binary compatibility and I believe people
> are overrating this. If code from different toolchains or languages
> needs to speak to each other, there's integration technologies. One of
> them is called "the C interface used by the platform (OS)". That's a
> dumb one (effective, though, and any monkey gets it). There's more
> (or, rather, very) complex stuff like COM of MS. There's also "VM as
> integration technology" (Java, .NET). Finally, there's also "one
> compiler version integration" of C++. There's all this choice since
> forever.
>
> We would gain little with putting binary compatibility into C or C++.
>

I disagree.  If you're in control of all the code you use, one compiler 
is fine.  If you're getting code from everywhichwhere, like so many 
projects do today, it's a real problem.  Even with open source, having 
to compile everything from scratch and cope with the quirks and 
incompatibilities of several compilers is a real handicap.

[toc] | [prev] | [next] | [standalone]

#416

On Sep 13, 1:22 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
> On 9/13/2011 3:24 AM, Goran wrote:
>
>
>
>
>
>
>
>
>
> > On Sep 12, 6:24 pm, Jonathan de Boyne Pollard<J.deBoynePollard-
> > newsgro...@NTLWorld.COM>  wrote:
> >>> This "problem" is called "name mangling" [...]
>
> >> No it isn't.  It's many programmers' simplistic statement of the
> >> problem, but name mangling is merely a symptom of the actual problem,
> >> which is a lack of binary compatibility across compilers, which
> >> stretches to a lot more things than just symbol names.  M. Zakharevich
> >> hit the nail squarely on the head:  DirectToSOM C++ solves this.  It's a
> >> pity that (a) the class library wasn't compiled to SOM by the IBM
> >> compiler, and (b) GCC isn't capable of DirectToSOM C++.
>
> > Binary compatibility? Meh. C and C++ as __languages__ do not have
> > that.
>
> > I personally am not a fan of binary compatibility and I believe people
> > are overrating this. If code from different toolchains or languages
> > needs to speak to each other, there's integration technologies. One of
> > them is called "the C interface used by the platform (OS)". That's a
> > dumb one (effective, though, and any monkey gets it). There's more
> > (or, rather, very) complex stuff like COM of MS. There's also "VM as
> > integration technology" (Java, .NET). Finally, there's also "one
> > compiler version integration" of C++. There's all this choice since
> > forever.
>
> > We would gain little with putting binary compatibility into C or C++.
>
> I disagree.  If you're in control of all the code you use, one compiler
> is fine.  If you're getting code from everywhichwhere, like so many
> projects do today, it's a real problem.  Even with open source, having
> to compile everything from scratch and cope with the quirks and
> incompatibilities of several compilers is a real handicap.

Fair point.

(Continuing from my first post, really)

If you're not in control of all the code, OTOH, there's a bigger
chance you'll have code in other languages, than code that runs well
only when compiled with a single compiler. In which case, again,
integration tech > binary compatibility between implementations.

There's another thing: even if we did have binary compatibility on a C
level, we'd still have to deal with versioning issues. No amount of
binary compatibility can help you when, I dunno, std::string changes
underlying implementation (which it just as well may, and did, in more
than one C++ toolchain). And versioning is one of the things that your
friendly integration tech allows for (well, should).

Goran.

[toc] | [prev] | [next] | [standalone]

#410

On 09/09/2011 01:32 AM, James Moe wrote:
> Hello,
>   Is it to be expected that different C++ compilers produce libraries
> with completely different public function names?
> 
  Thanks, everyone. I was hoping otherwise but I am not surprised at the
lack of standard symbol naming.

-- 
James Moe
jmm-list at sohnen-moe dot com

[toc] | [prev] | [next] | [standalone]

#411

On Sat, 10 Sep 2011 19:15:17 UTC, James Moe wrote:
> On 09/09/2011 01:32 AM, James Moe wrote:

> >   Is it to be expected that different C++ compilers produce libraries
> > with completely different public function names?
> > 
>   Thanks, everyone. I was hoping otherwise but I am not surprised at the
> lack of standard symbol naming.

Shouldn't you be able to resolve this with an IMPORTS statement in your
.def file?  E.g.

IMPORTS
__ZN11xercesc_2_316XMLPlatformUtils9TerminateEv=xerces.Terminate__16XMLPlatformUtilsFv

I haven't tried this but if you only import a few symbols, it might
be worth the effort to experiment.  Correctly matching multiple versions
of an overloaded method could be a challenge, though.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

[toc] | [prev] | [next] | [standalone]

#418

On 09/10/2011 08:08 PM, Rich Walsh wrote:
> On Sat, 10 Sep 2011 19:15:17 UTC, James Moe wrote:
>> On 09/09/2011 01:32 AM, James Moe wrote:
>
>>>    Is it to be expected that different C++ compilers produce libraries
>>> with completely different public function names?
>>>
>>    Thanks, everyone. I was hoping otherwise but I am not surprised at the
>> lack of standard symbol naming.
>
> Shouldn't you be able to resolve this with an IMPORTS statement in your
> .def file?  E.g.
>
> IMPORTS
> __ZN11xercesc_2_316XMLPlatformUtils9TerminateEv=xerces.Terminate__16XMLPlatformUtilsFv
>
> I haven't tried this but if you only import a few symbols, it might
> be worth the effort to experiment.  Correctly matching multiple versions
> of an overloaded method could be a challenge, though.

That's a possible but dangerous approach.  You'd have to know for sure 
that the calling convention is the same.

-- 
Reverse the parts of the e-mail address to reply by mail.

[toc] | [prev] | [next] | [standalone]

#419

"Marty" <net@comcast.martyamodeo> schrieb im Newsbeitrag 
news:j4tb5u$q8q$1@dont-email.me...
> On 09/10/2011 08:08 PM, Rich Walsh wrote:
>> On Sat, 10 Sep 2011 19:15:17 UTC, James Moe wrote:
>>> On 09/09/2011 01:32 AM, James Moe wrote:
>>
>>>>    Is it to be expected that different C++ compilers produce libraries
>>>> with completely different public function names?
>>>>
>>>    Thanks, everyone. I was hoping otherwise but I am not surprised at 
>>> the
>>> lack of standard symbol naming.
>>
>> Shouldn't you be able to resolve this with an IMPORTS statement in your
>> .def file?  E.g.
>>
>> IMPORTS
>> __ZN11xercesc_2_316XMLPlatformUtils9TerminateEv=xerces.Terminate__16XMLPlatformUtilsFv
>>
>> I haven't tried this but if you only import a few symbols, it might
>> be worth the effort to experiment.  Correctly matching multiple versions
>> of an overloaded method could be a challenge, though.
>
> That's a possible but dangerous approach.  You'd have to know for sure 
> that the calling convention is the same.

Not only that. I know little about C++ plusplus but maybe there is also 
something to consider
for virtual and overloaded functions etc.

Lars

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.os2.programmer.misc

csiph-web