public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* C++ code with external C API --> static library?
@ 2004-06-11 11:54 Ingolf Steinbach
  2004-06-11 16:50 ` llewelly
  0 siblings, 1 reply; 4+ messages in thread
From: Ingolf Steinbach @ 2004-06-11 11:54 UTC (permalink / raw)
  To: gcc-help

Hi,

what are the necessary steps with gcc/g++ to solve the following
problem:
1. Target is a static library
2. The library presents a C language API
3. Internally, the library is implemented in C++ and makes
   heavy use of standard components from the stdc++ library
4. A user shall be able to use the library with gcc without
   having to know that the library is implemented in C++
   (i.e. the library must not reference unresolved C++ related
   symbols; all these symbols have to be resolved when the
   library is created).
5. Only symbols from the C language API are to be exported
   by the library. No internal symbols shall be visible.

(For step 2, I use the usual approach: #ifdef __cplusplus
extern "C" { #endif -- and the similar for the closing brace.)

Any suggestions?

Kind regards
    Ingolf
-- 

Ingolf Steinbach                       Jena-Optronik GmbH
ingolf.steinbach@jena-optronik.de       ++49 3641 200-147
PGP: 0x7B3B5661  213C 828E 0C92 16B5  05D0 4D5B A324 EC04

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: C++ code with external C API --> static library?
  2004-06-11 11:54 C++ code with external C API --> static library? Ingolf Steinbach
@ 2004-06-11 16:50 ` llewelly
  2004-06-14  7:16   ` Ingolf Steinbach
  0 siblings, 1 reply; 4+ messages in thread
From: llewelly @ 2004-06-11 16:50 UTC (permalink / raw)
  To: Ingolf Steinbach; +Cc: gcc-help

Ingolf Steinbach <Ingolf.Steinbach@jena-optronik.de> writes:

> Hi,
> 
> what are the necessary steps with gcc/g++ to solve the following
> problem:
> 1. Target is a static library
> 2. The library presents a C language API
> 3. Internally, the library is implemented in C++ and makes
>    heavy use of standard components from the stdc++ library
> 4. A user shall be able to use the library with gcc without
>    having to know that the library is implemented in C++
>    (i.e. the library must not reference unresolved C++ related
>    symbols; all these symbols have to be resolved when the
>    library is created).

For this, you'll need to link libstdc++ and libsupc++ to the library
    staticly. 

> 5. Only symbols from the C language API are to be exported
>    by the library. No internal symbols shall be visible.
[snip]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: C++ code with external C API --> static library?
  2004-06-11 16:50 ` llewelly
@ 2004-06-14  7:16   ` Ingolf Steinbach
  2004-06-14 20:05     ` llewelly
  0 siblings, 1 reply; 4+ messages in thread
From: Ingolf Steinbach @ 2004-06-14  7:16 UTC (permalink / raw)
  To: gcc-help; +Cc: llewelly

On Friday 11 June 2004 18:50, llewelly@xmission.com wrote:
> > 4. A user shall be able to use the library with gcc without
> >    having to know that the library is implemented in C++
> >    (i.e. the library must not reference unresolved C++ related
> >    symbols; all these symbols have to be resolved when the
> >    library is created).
>
> For this, you'll need to link libstdc++ and libsupc++ to the library
>     staticly.

Thank you for your comments.

Any suggestions wrt the correct invocation of g++ to achieve
this? (Note: of course, I'd prefer to only include those parts
of the stdc++ and supc++ libraries which are really needed.)

> > 5. Only symbols from the C language API are to be exported
> >    by the library. No internal symbols shall be visible.

I found some remarks on selecting the set of exported symbols
in the GNU ld info pages, but maybe I still got something
wrong (as there still are other symbols in the resulting library).
What is the correct way to do this?

Kind regards
    Ingolf
-- 

Ingolf Steinbach                       Jena-Optronik GmbH
ingolf.steinbach@jena-optronik.de       ++49 3641 200-147
PGP: 0x7B3B5661  213C 828E 0C92 16B5  05D0 4D5B A324 EC04

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: C++ code with external C API --> static library?
  2004-06-14  7:16   ` Ingolf Steinbach
@ 2004-06-14 20:05     ` llewelly
  0 siblings, 0 replies; 4+ messages in thread
From: llewelly @ 2004-06-14 20:05 UTC (permalink / raw)
  To: Ingolf Steinbach; +Cc: gcc-help

Ingolf Steinbach <Ingolf.Steinbach@jena-optronik.de> writes:

> On Friday 11 June 2004 18:50, llewelly@xmission.com wrote:
> > > 4. A user shall be able to use the library with gcc without
> > >    having to know that the library is implemented in C++
> > >    (i.e. the library must not reference unresolved C++ related
> > >    symbols; all these symbols have to be resolved when the
> > >    library is created).
> >
> > For this, you'll need to link libstdc++ and libsupc++ to the library
> >     staticly.
> 
> Thank you for your comments.
> 
> Any suggestions wrt the correct invocation of g++ to achieve
> this?

I don't remember, and I can't seem to make time to test it out. I
    think -static.

> (Note: of course, I'd prefer to only include those parts
> of the stdc++ and supc++ libraries which are really needed.)
> 
> > > 5. Only symbols from the C language API are to be exported
> > >    by the library. No internal symbols shall be visible.
> 
> I found some remarks on selecting the set of exported symbols
> in the GNU ld info pages, but maybe I still got something
> wrong (as there still are other symbols in the resulting library).
> What is the correct way to do this?

I'm sorry, I don't know.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-06-14 20:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-11 11:54 C++ code with external C API --> static library? Ingolf Steinbach
2004-06-11 16:50 ` llewelly
2004-06-14  7:16   ` Ingolf Steinbach
2004-06-14 20:05     ` llewelly

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).