C++ Headers in /usr/include

  • Hi folks,

    I have some C++ headers that I've manually installed in /usr/include/
    Blah to make them fairly easy to access. Why I'm doing this is NOT
    important at the moment. However, it seems when I include these
    headers in a source file I get some interesting errors like this:

    error: template specialization with C linkage
    error: template with C linkage

    There are at least three ways I've found to solve this problem and
    make things compile OK.

    * If I move the headers out of /usr/include and update my include path
    * If I preprocess the file and comment out all the "# XX" references
    * If I put 'extern "C++"' around the class definitions in the include
    files.

    I guess I'm wondering why having the headers in /usr/include/Blah
    causes this error when moving them makes them work fine or why I have
    to protect them if they are under /usr/include. Also is extern C++
    standard or should I protect this as well?

    I'm just a little confused and curious :)

    Thanks in advance,

    --
    Trenton Schulz
    Trolltech AS
  • Trenton Schulz wrote:
    >
    > There are at least three ways I've found to solve this problem and  make
    > things compile OK.
    >
    > * If I move the headers out of /usr/include and update my include path
    > * If I preprocess the file and comment out all the "# XX" references
    > * If I put 'extern "C++"' around the class definitions in the include
    > files.
    >
    > I guess I'm wondering why having the headers in /usr/include/Blah
    > causes this error when moving them makes them work fine or why I have
    > to protect them if they are under /usr/include. Also is extern C++
    > standard or should I protect this as well?
    >
    > I'm just a little confused and curious :)
    >
    > Thanks in advance,
    >
    The most likely explanation is that at some point you modified the
    headers as described in your second or third option above, then moved
    those modified headers somewhere else. Now when you perform the first
    option (move the current headers and change the include paths) you have
    another include path that is searched first, and the compiler is finding
    the modified headers on that path.

    I know this sounds too stupid to be true, but don't dismiss it out of
    hand. Pick one of the header file names and search for it in the Finder,
    searching all of your disks. My guess is that you will find at least one
    copy in an unexpected location.

    Another (probably better) approach is to perform your first step (move
    headers and change paths), then open one of your failing sources and
    have Xcode preprocess it for you. Preprocess is available at the bottom
    of the Build menu. When it finishes, it pops up a window that contains
    the preprocessed source. You can see how the headers expanded, and it
    also seems to display the full path names to the header and source files
    that it used. Check the paths that are shown.

    Regards,
    Rush
  • On Feb 17, 2006, at 7:22 PM, Rush Manbert wrote:

    > Trenton Schulz wrote:
    >> There are at least three ways I've found to solve this problem
    >> and  make things compile OK.
    >> * If I move the headers out of /usr/include and update my include
    >> path
    >> * If I preprocess the file and comment out all the "# XX" references
    >> * If I put 'extern "C++"' around the class definitions in the
    >> include  files.
    >> I guess I'm wondering why having the headers in /usr/include/Blah
    >> causes this error when moving them makes them work fine or why I
    >> have  to protect them if they are under /usr/include. Also is
    >> extern C++  standard or should I protect this as well?
    >> I'm just a little confused and curious :)
    >> Thanks in advance,
    > The most likely explanation is that at some point you modified the
    > headers as described in your second or third option above, then
    > moved those modified headers somewhere else. Now when you perform
    > the first option (move the current headers and change the include
    > paths) you have another include path that is searched first, and
    > the compiler is finding the modified headers on that path.
    >
    > I know this sounds too stupid to be true, but don't dismiss it out
    > of hand. Pick one of the header file names and search for it in the
    > Finder, searching all of your disks. My guess is that you will find
    > at least one copy in an unexpected location.

    No, I tried this out on separate machines with "fresh" includes and
    it still happened. I also did the Finder/Spotlight search on my
    development machine and "took care of" any old headers. Same thing. /
    usr/include seems to be a key.

    >
    > Another (probably better) approach is to perform your first step
    > (move headers and change paths), then open one of your failing
    > sources and have Xcode preprocess it for you. Preprocess is
    > available at the bottom of the Build menu. When it finishes, it
    > pops up a window that contains the preprocessed source. You can see
    > how the headers expanded, and it also seems to display the full
    > path names to the header and source files that it used. Check the
    > paths that are shown.

    We've done that and there's nothing strange there. (that's why we
    were so puzzled about removing the preprocessor comments, we wanted
    to see where the error was in the preprocessed file, but the file is
    fine without the # directives to the original file). It seems that
    there is some unspoken rule for C++ headers in /usr/include, I was
    just hoping someone would speak out on it :)

    -- Trenton
  • Trenton:

    On 18/02/2006, at 5:59 AM, Trenton Schulz wrote:

    >
    > On Feb 17, 2006, at 7:22 PM, Rush Manbert wrote:
    >
    >> Trenton Schulz wrote:
    >>> There are at least three ways I've found to solve this problem
    >>> and  make things compile OK.
    >>> * If I move the headers out of /usr/include and update my include
    >>> path
    >>> * If I preprocess the file and comment out all the "# XX" references
    >>> * If I put 'extern "C++"' around the class definitions in the
    >>> include  files.
    >>> I guess I'm wondering why having the headers in /usr/include/
    >>> Blah  causes this error when moving them makes them work fine or
    >>> why I have  to protect them if they are under /usr/include. Also
    >>> is extern C++  standard or should I protect this as well?
    >>> I'm just a little confused and curious :)
    >>> Thanks in advance,
    >> The most likely explanation is that at some point you modified the
    >> headers as described in your second or third option above, then
    >> moved those modified headers somewhere else. Now when you perform
    >> the first option (move the current headers and change the include
    >> paths) you have another include path that is searched first, and
    >> the compiler is finding the modified headers on that path.
    >>
    >> I know this sounds too stupid to be true, but don't dismiss it out
    >> of hand. Pick one of the header file names and search for it in
    >> the Finder, searching all of your disks. My guess is that you will
    >> find at least one copy in an unexpected location.
    >
    > No, I tried this out on separate machines with "fresh" includes and
    > it still happened. I also did the Finder/Spotlight search on my
    > development machine and "took care of" any old headers. Same
    > thing. /usr/include seems to be a key.

    We had the same gcc "feature" hit us in macstl:

    http://www.pixelglow.com/lists/archive/macstl-dev/2005-February/
    000015.html

    I think it's a lingering bug in gcc but #pragma GCC system_header
    might help you.

    Cheers, Glen Low

    ---
    pixelglow software | simply brilliant stuff
    www.pixelglow.com
    aim: pixglen
  • On Feb 18, 2006, at 2:05 AM, Glen Low wrote:

    > Trenton:
    >
    >>
    >> No, I tried this out on separate machines with "fresh" includes
    >> and it still happened. I also did the Finder/Spotlight search on
    >> my development machine and "took care of" any old headers. Same
    >> thing. /usr/include seems to be a key.
    >
    >
    > We had the same gcc "feature" hit us in macstl:
    >
    > http://www.pixelglow.com/lists/archive/macstl-dev/2005-February/
    > 000015.html
    >
    > I think it's a lingering bug in gcc but #pragma GCC system_header
    > might help you.

    Hmm... that seems very similar. I don't really want the system header
    pragma, though, it's not a system header, nor will it ever be. I
    don't mind doing the extern "C++" for the time being, I just wanted
    some sort of idea why I must do that in the first place.

    Well, I know not where to put headers in the future :)

    -- Trenton
  • On Feb 17, 2006, at 5:05 PM, Glen Low wrote:

    > On 18/02/2006, at 5:59 AM, Trenton Schulz wrote:
    >
    >> On Feb 17, 2006, at 7:22 PM, Rush Manbert wrote:
    >>
    >>> Trenton Schulz wrote:
    >>>> There are at least three ways I've found to solve this problem and
    >>>> make things compile OK.
    >>>> * If I move the headers out of /usr/include and update my include
    >>>> path
    >>>> * If I preprocess the file and comment out all the "# XX" references
    >>>> * If I put 'extern "C++"' around the class definitions in the
    >>>> include  files.
    >>>> I guess I'm wondering why having the headers in /usr/include/Blah
    >>>> causes this error when moving them makes them work fine or why I
    >>>> have  to protect them if they are under /usr/include. Also is
    >>>> extern C++  standard or should I protect this as well?
    >>>> I'm just a little confused and curious :)
    >>>> Thanks in advance,
    >>> The most likely explanation is that at some point you modified the
    >>> headers as described in your second or third option above, then
    >>> moved those modified headers somewhere else. Now when you perform
    >>> the first option (move the current headers and change the include
    >>> paths) you have another include path that is searched first, and the
    >>> compiler is finding the modified headers on that path.
    >>>
    >>> I know this sounds too stupid to be true, but don't dismiss it out
    >>> of hand. Pick one of the header file names and search for it in the
    >>> Finder, searching all of your disks. My guess is that you will find
    >>> at least one copy in an unexpected location.
    >>
    >> No, I tried this out on separate machines with "fresh" includes and
    >> it still happened. I also did the Finder/Spotlight search on my
    >> development machine and "took care of" any old headers. Same thing.
    >> /usr/include seems to be a key.
    >
    > We had the same gcc "feature" hit us in macstl:
    >
    > http://www.pixelglow.com/lists/archive/macstl-dev/2005-February/
    > 000015.html
    >
    > I think it's a lingering bug in gcc but #pragma GCC system_header
    > might help you.

    It was originally intended as a feature, not a bug.  The problem was
    that a variety of system headers on assorted operating systems didn't
    properly 'extern "C"' their system headers, so C++ programmers had
    trouble using those headers.  The gcc folks decided to fix the problem
    by telling the compiler that everything in /usr/include was implicitly
    'extern "C"'.

    Our compiler team would like to get rid of this feature in the Mac OS X
    version of gcc, but we still have a few headers that don't quite work
    if it's turned off.  We should fix them, but it hasn't been a terribly
    high priority because this so rarely affects anyone.  Nobody other than
    Apple should be putting headers in /usr/include, after all....

    -Eric
previous month february 2006 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28          
Go to today