GraphicsMagick (which is primarily C code) supports optional linkage
with some C++ libraries. It is my opinion that if a library or program
is linked with C++ libraries (and especially if it is a static build!)
that it should be linked using the C++ linker. Likewise, if a library
or program does not depend on, or contain any C++ code, it should be
linked with the C linker.
GraphicsMagick has several major build options which includes putting
everything in its major library, or separating certain code into
loadable modules. Automake conditionals are used to support the several
major build options. When loadable modules are used, the C++ dependency
is moved to the loadable modules and away from the major library.
The method that I am using to coax Automake into linking using the C++
linker is to include a technically empty 'acpplus.cpp' file as a
component when building modules, libraries, or an executable. This
approach works, but it has a problem. The problem is that if Automake
sees that a C++ source file may be *optionally* included in a target, it
promotes the linkage for that target to C++.
In my builds I see a library of C files being linked together with the
C++ linker, even though no C++ code was actually built!
Is there a better solution or fix for this problem?
I have a continuing problem that when libtool tests which libraries are
supplied automatically by the C++ linker, it detects that the C++ linker
provides -lm, and thus it strips -lm from the library dependencies
stored in the libtool library .la file, causing static linkage of C
programs using that .la file to fail. This means that when the library
linked with libtool's C++ linker is installed, C programs will fail to
link with it by default. This issue was already reported as a bug to the
libtool project.
Mixing C and C++ files together in a project in conjunction with libtool
seems very hard!
Bob
