Re: C library promoted to C++ linkage due to optional C++ source module
Hi Bob, 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. I surely agree, in principle. But that doesn't mean I have the faintest idea what to change in Automake to make that be the case. You probably know better than me :). Can you provide (as simple as possible) test cases? I have since backed away from this approach because I saw that the clever way that Automake handles conditionals is not going to be smart enough to make language decisions based on if a file is added or removed. The compiler/linker type to use is already baked into Makefile.in and the choice used is also based on the optional source files. If a C++ file appears, the language is promoted from C to C++ (--tag=CXX) and is baked into Makefile.in. I see code like this appearing in Makefile.in: Magick___lib_libGraphicsMagick___la_LINK = $(LIBTOOL) $(AM_V_lt) \ --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=link \ $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) \ $(Magick___lib_libGraphicsMagick___la_LDFLAGS) $(LDFLAGS) -o \ $@ As such, it seems that this would be a major feature request and significant redesign, and is not a simple bug. I may be possible to replace this Makefile hunk as an override, but it may not be reliable. It does seem important to link with the C++ compiler when depending on C++ libraries, but modern Linux apparently works "fine" if you don't. I have a continuing problem that when libtool tests bug-libt...@gnu.org for that one, I think ... --best, karl. There is a bug open already in libtool for the issue with dropping -lm when mixing C and C++. It is not clear that the C++ linker provides -lm by default since it seemed to be pulled in by implicit dependencies as part of the libraries implementation. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: C library promoted to C++ linkage due to optional C++ source module
Hi Bob, 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. I surely agree, in principle. But that doesn't mean I have the faintest idea what to change in Automake to make that be the case. You probably know better than me :). Can you provide (as simple as possible) test cases? I have a continuing problem that when libtool tests bug-libt...@gnu.org for that one, I think ... --best, karl.
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
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? Bob
