I don't know the specific headers involved, but the generall problem is one of dependencies. Headers are used to tell the compiler about stuff it needs to know so it can use library code that is not part of the current compilation unit. (Note my use of "library" is pretty loose here - I just mean stuff compiled outside the current compilation unit.)

When different librarys are being used you can run into naming issues where different headers use the same identifier for different purposes. Often there is trickery in the headers to avoid some of the problems caused by that and often that trickery fails if headers are not included in the right order. This is most likely the issue that you were experiencing.

Often headers for one compilation unit require other headers in order to compile. The header writer has a number of options:

  1. Include the required header
  2. Include the required header only if it hasn't been included already
  3. Assume the required header has already been included
  4. Define the stuff it needs so the other header is not required

Depending on how the other header has been written, and how stable it is, all of those options can cause trouble! Probably the worst is 3 and possibly the best option is 2 closely followed by option 1.

Writing headers can be pretty tricky stuff. Occasionally you get into a situation where two headers seem to depend on each other for example. Generally that is more likely to be a problem relating to C++ classes than to C headers and is generally related to classes that need to reference each other. Very often in that case you are seeing the result of poor design.

Many headers still use the C preprocessor macro facility to provid named types. There is no way to manage such names and collisions between them to avoid "issues". In fact compile failures are much the best outcome when macros start wreaking havoc. It is much worse to have code that looks fine, but is behaving completely differently than you expect because some stupid macro has altered the meaning of an inocuous line of code into something that any obfusicated Perl hacker would be proud of.

In the case of using other people's headers maybe cargo cult is best. :)


DWIM is Perl's answer to Gödel

In reply to Re: Why does order of #include's matter in XS file for C++ extensions under Windows? by GrandFather
in thread Why does order of #include's matter in XS file for C++ extensions under Windows? by DrWhy

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.