[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linking C++ code?
- To: ports_(_at_)_openbsd_(_dot_)_org
- Subject: Re: Linking C++ code?
- From: naddy_(_at_)_mips_(_dot_)_inka_(_dot_)_de (Christian Weisgerber)
- Date: Wed, 9 Oct 2002 23:14:11 +0000 (UTC)
- Newsgroups: list.openbsd.ports
Jedi/Sector One <j_(_at_)_pureftpd_(_dot_)_org> wrote:
> > Must a C++ program be linked with c++(1) rather than cc(1)?
Can you expand on this?
> > What about a C program that uses a C++ library?
> The whole C part must be declared inside extern "C" statements.
That's for a C++ program using a C library. No problem there.
I'm wondering about the reverse case. There are some libraries,
such as id3lib or smpeg, that are written in C++ but also offer a
C API. So somebody writes a C program and links against this
library. Must the final linking be done with c++?
I'm not so much interested in what accidentally happens to work but
in the "officially" correct way.
There are various examples in the ports tree where people combine
C and C++ code in some way and make assumptions how things work.
Building with gcc3.2 breaks some of these assumptions.
Some notable scenarios:
- C program links against self-contained C++ library.
(Alas, the C++ code may not be as self-contained as the author
thought, e.g. the "new" and "delete" operators are apparently
provided by external code.)
- C program links against a C++ library that also uses the STL.
This is typically handled by additionally linking with libstdc++.
- A plugin (module) written in C++ that is intended to be dynamically
loaded by a C program. XMMS plugins written in C++ are such a
case. Again, -lstdc++ seems to be popular.
Explicitly linking with libstdc++ blows up because the corresponding
library for our gcc3.2 port is libestdc++. However, I'm not convinced
that it's a clean approach in the first place.
> > There are a number of ports that won't build on sparc64 with gcc3
> > because they use some mix of C and C++ code together with plain
> > cc(1) for linking.
> They are broken. They must link with c++.
Besides final linking, this also pops up in autoconf tests. (Yes,
_I_ know that autoconf can switch to C++ mode.) Patching this for
us is one thing, but if I want to convince an upstream maintainer
I need to stand on firm ground.
And what about dynamically loaded modules?
Christian "naddy" Weisgerber naddy_(_at_)_mips_(_dot_)_inka_(_dot_)_de
Visit your host, monkey.org