Re: Wrapping C++ with C

From: Paul Pluzhnikov (ppluzhnikov-nsp_at_charter.net)
Date: 09/12/04

  • Next message: zoom: "Wait for "signal" from another application and/or thread"
    Date: 12 Sep 2004 08:31:24 -0700
    
    

    Roger Leigh <${roger}@invalid.whinlatter.uklinux.net.invalid> writes:

    > For several reasons, I'd like to make use of C++ features such as
    > templated functions and STL lists and maps in a C shared library.
    > However, from the outside I'd like it to appear as a regular C library
    > with a C API and not requiring a C++ compiler for linking. Is this
    > possible?

    Yes. But there are many gotcha's.

    > I believe all I need to do is write the code as C++ code with the C
    > wrapper functions declared as extern "C". Is this correct?

    That's all you have to do IFF your std::list and std::map are
    implemented entirely as templates, and do not introduce dependency
    on C++ runtime libraries for your compiler. This appears to be the
    case for g++ 2.95 and 3.4.2; but it is not the case for Sun Workshop,
    nor for HP aCC.

    If there are external C++ dependencies, you'll have to carefully
    arrange for them to disappear by linking the missing C++ symbols
    from the compiler runtime into your library *statically* [1] (so that
    your clients could be "plain C" programs), and then hiding these
    symbols (because your client may be using a different version of
    the same compiler, and you would not want to have your "imported"
    symbols clash with his imported symbols).

    [1] This assumes that you have an archive version of said runtime
    library.

    A further complication is that the archive version of the compiler
    runtime is often not compiled as position-independent, and thus is
    not suitable for inclusion into a shared library.

    > Are there any portability or linking issues to be aware of?

    You bet.

    Cheers,

    -- 
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.
    

  • Next message: zoom: "Wait for "signal" from another application and/or thread"

    Relevant Pages

    • Re: 10.0-CUR r226986 && ports (general)
      ... configure:3232: checking for gcc ... Configured with: FreeBSD/amd64 system compiler ... configure:5483: checking how to associate runtime and link libraries ... configure: failed program was: ...
      (freebsd-current)
    • Open Dylan 2011.1 released
      ... It is a pleasure for us to finally announce a release of Open Dylan. ... their code for the compiler and runtime libraries under the MIT ... The C back-end currently does not support multi-threaded programs. ...
      (comp.lang.dylan)
    • SUCCESS: DBD::Oracle 1.15 on HP-UX 11.11
      ... to link 32bit executables to 64bit libraries. ... * The format of compiled objects is specified by compiler options. ... while ora9 delivers only 2.0/64. ... a bit inconsistent considering the ora8 setup, ...
      (perl.dbi.users)
    • Re: port seahorse wont upgrade properly
      ... gnome-applets everytime I do a portupgrade gnome-applets: ... checking for C compiler default output file name... ... checking if cc static flag -static works... ... checking whether the cc linker supports shared libraries... ...
      (freebsd-questions)
    • Re: GNAT and GNU build system
      ... :>: Building some non-autoconfized projects with custom compiler flags ... :> If an Ada library isn't very system-specific, ... Some Ada libraries ... in addition to GNU. ...
      (comp.lang.ada)