Re: [Openexr-devel] "Half" support in C?

[Drew Hess]

Bob Friesenhahn <address@hidden> writes:

> The typical situation is that it is easy for GCC code to link with
> OS/vendor libraries (the normal case).  It is problematic for vendor
> compilers to link with libraries build with GCC (even C libraries)
> because code built with GCC expects certain support functions
> (e.g. _eprintf) to exist.  Adding libgcc to the mix may cause other
> problems (e.g. duplicate symbols).


"May," or "has" ?  I find it hard to believe that in practice you'd
encounter code and/or a vendor compiler that has symbol conflicts with
libgcc, given how popular that compiler is.


> Due to C++ initialization and symbol dependency issues, it may be very
> difficult for code from a vendor compiler to link properly with GCC
> created C++ libraries.  It will help to link the C code using g++.
>
> The upshot is that depending on GNU C++ to satisfy the requirement is
> not satisfactory unless GNU C/C++ is used for the whole build.  Even
> then, introducing a C++ component into an otherwise C application
> requires that the C application be linked using the C++ compiler.


What I'm proposing is not that you link a C++ library into your C
code, but that you wrap the C++ library (libHalf, in this case) with a
C library, and then link that C library into your application.  If the
C++ library is statically linked into the C wrapper, I don't think
you'd need a C++-aware linker.


d

pgpyqAdFGokXI.pgp
Description: PGP signature