3

A commit in the C implementation of the Nokogumbo gem is causing the build to fail on Gentoo Linux, however, the modification is minor and shouldn't cause any trouble. Unfortunately, I know next to zilch about C.

Here's the commit:

https://github.com/rubys/nokogumbo/commit/8b4446847dea5c614759684ebcae4c580c47f4ad

It simply replaces the <> with "":

-#include <gumbo.h>
-#include <error.h>
-#include <parser.h>
+#include "gumbo.h"
+#include "error.h"
+#include "parser.h"

According to the GCC docs this shouldn't cause any trouble since it falls back to the previous behaviour:

#include "file"

This variant is used for header files of your own program. It searches for a file named file first in the directory containing the current file, then in the quote directories and then the same directories used for <file>. You can prepend directories to the list of quote directories with the -iquote option.

Unfortunately, while it compiles just fine with <>, the build fails with "":

compiling nokogumbo.c
nokogumbo.c:24:20: fatal error: parser.h: No such file or directory
#include "parser.h"

I'm wondering to what degree the way <> and "" behaves depends on the toolchain, environment and other settings.

Thanks a lot for your hints!

Ry-
  • 218,210
  • 55
  • 464
  • 476
svoop
  • 3,318
  • 1
  • 23
  • 41
  • This is non-compliant behavior. If an include with `" "` fails, the compiler must try again as if you had written `< >`. So something is terribly wrong with your gcc. – Lundin Mar 21 '18 at 07:57
  • How do you call gcc, from an IDE or through command line? In case of IDE:s, there might be some IDE hiccup where it manually creates an include path with `-I` and only passes that to gcc. "Vanilla gcc" from command line shouldn't have these issues. – Lundin Mar 21 '18 at 15:12

2 Answers2

0

Re-installing "gumbo" on the Gentoo box has fixed the problem. Apparently, a local installation mess has produced this weird behaviour.

svoop
  • 3,318
  • 1
  • 23
  • 41
-1

I checked your git repository and I noticed that you compile code with --std=c99. I think this may cause the problem, Because I found this in C99 draft:

The named source file is searched for in an implementation-defined manner .If this search is not supported, or if the search fails, the directive is reprocessed as if it read

#include <header>

So it means process is first implementation defined, and if not supported it uses #include<> mode. But this means if it defines that #include"" searches current directory, it will stop searching like #include<>.

Afshin
  • 8,839
  • 1
  • 18
  • 53
  • You are misinterpreting the standard. "or if the search fails" is very clear, the compiler must try again as if you had written `< >`. This is not unique to C99 either, it has always been like that. – Lundin Mar 21 '18 at 07:58