Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Saturday January 03, 2004
08:28 PM

Why I am Not A (Good) C Programmer, part 2

[ #16613 ]

with apologies to Bertrand Russell

What confuses me about a 35 year old programming language today? Include paths. Specifically, why does the order in which I specify paths to headers matter, since the header only exists in one of those paths? Why does the GCC preprocessor fail if it can't locate one header in the first path specified, without continuing to look in the other paths I so helpfully provided?

Yep, shuffling my -I declarations around on the compile line made it work. I discovered this after comparing the output from the Makefile from that of Module::Build (and you probably don't want to know what kind of evilness I do there to give different options to different XS files; but it's Perl and I know how to make that work).

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The symptoms you describe are a sign of something else being wrong.
  • If shuffling include paths makes something magically work, it sounds like the same filename exists in two paths. With your include paths misconfigured, you'll pull in the wrong one first, and find that the definitions you expect to find simply aren't defined, causing gcc to fail.

    Try locate foo.h to track down where the unfortunately named include file appears.

    • Yeah, that's what I thought at first too. However, the header's only in one place, exactly where it's supposed to be. The only thing close to a duplicate header is a .ph file, which appears to have come from h2ph -- but it's Perl, not C, and I'm reasonably confident gcc does absolutely nothing with it.