Hi Eric, Thanks for the feedback.
On 23 Aug 2010, at 21:47, Eric Blake wrote:
> On 08/22/2010 08:54 AM, Gary V. Vaughan wrote:
>> While trying to compile a C++ package, and using the gnulib socket modules
>> to paper over the differences between various vendor implementations, I
>> tripped over the following error on Solaris 2.6 and 7:
>>
>> "lib/alignof.h", line 28: Error: Template declarations cannot have extern
>> "C" linkage.
>> 1 Error(s) detected.
>>
>> Triggered by the following code in alignof.h:
>>
>> /* Determine the alignment of a structure slot (field) of a given type,
>> at compile time. Note that the result depends on the ABI.
>> Note: The result cannot be used as a value for an 'enum' constant,
>> due to bugs in HP-UX 10.20 cc and AIX 3.2.5 xlc. */
>> #if defined __cplusplus
>> template<class type> struct alignof_helper { char __slot1; type __slot2;
>> };
>> ...
>>
>> The problem is that the package C++ headers wrap inclusions of C headers in
>> `extern "C"', which seems like a reasonable thing to do.
>
> No, it does not sound reasonable to me. Well-written system headers should
> already be accommodating to C++ without needing extra help from clients.
Well, we are talking about old Solaris here: well-written solaris system
headers is an oxymoron! I imagine the upstream developers of this package
(epics-base-3.14.11) put the extern "C" in to their solaris-specific headers to
fix a problem they encountered at some point. The libraries it builds are
assembled from a selection of C and C++ objects, which is the most likely
scenario I can imagine to trigger a bug that might have needed the extern "C"
blocks to fix...
>> I'm curious who is wrong here: Is it wrong for gnulib's alignof.h to use C++
>> conditionally and assume that it is not included from inside an `extern "C"'
>> in an outer file? Is it wrong for the package to mistrust the system C
>> headers so much that they are only included to a C++ file inside an `extern
>> "C"' declaration? Or is it wrong for the C++ compiler to complain about use
>> of templates inside `extern "C"'?
>
> The compiler is right to complain about templates inside of extern "C".
Although only Solaris 2.6 and 7 (at the newest available vendor compiler
patch-level AFAICT) complain... Solaris 8, 9 and 10 work, although that may be
because gnulib sys/socket.h doesn't need alignof.h with the newer compilers,
and thus doesn't trigger the bug. I can investigate anything that is useful to
helping gnulib cope if you'd like.
> Since I'm claiming that any system header is broken if it requires an
> external 'extern "C"' block to behave correctly in C++, and since gnulib is
> designed to provide replacement headers around broken headers, it follows
> that gnulib should be able to fix the brokenness of any such system header in
> a manner transparent to your program (but we can only test for and fix such
> brokenness when it is reported).
If it is a lot of work to do that (and actually, I can't think of any straight
forward way for
alignof.h to know whether it is already inside an `extern "C"' block), please
don't do it on my account. I'm quite happy with the patching the package
headers to avoid the issue.
>> I have a workaround already (moving `#include<sys/socket.h>' outside the
>> `extern "C"'), but I'm curious about the real culprit, and maybe the gnulib
>> generated headers want to work properly when used like this?
>
> I would say that your workaround is the correct approach; none of the headers
> provided by gnulib should ever appear inside your program's extern "C"
> blocks. But we should probably document that intent better.
IMHO that's all that's necessary in this case.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
