C library promoted to C++ linkage due to optional C++ source module

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