GCC include directive bug.

[bga]

This is an interesting bug. it manifested itself when trying to compile Haiku under itself and it is 100% reproducible not only by me, but by others too. First, here is the line that triggers the bug:

gcc -c "src/libs/stdc++/sinst.cc" -O2 -Wall -Wno-trigraphs -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wpointer-arith -Wcast-align -Wsign-compare -pipe -nostdinc -Wno-multichar -D_ZETA_USING_DEPRECATED_API_=1 -D_ZETA_TS_FIND_DIR_=1 -nostdinc++ -fno-implicit-templates -Wno-sign-compare -fpic -DHAIKU -DHAIKU_DISTRO_COMPATIBILITY_DEFAULT -DINTEL -DARCH_x86 -D_BEOS_R5_COMPATIBLE_ -DHAIKU_TARGET_PLATFORM_HAIKU -DC -DEXTRACT -DINSERT -DGETLINE -Ibuild/user_config_headers -Ibuild/config_headers -Isrc/libs/stdc++ -Igenerated/objects/common/libs/stdc++ -Igenerated/objects/haiku_host/x86/common/libs/stdc++ -Igenerated/objects/haiku/x86/common/libs/stdc++ -I- -Isrc/libs/stdc++ -Isrc/system/libroot/posix/glibc/libio -Isrc/system/libroot/posix/glibc/stdlib -Isrc/system/libroot/posix/glibc/stdio-common -Isrc/system/libroot/posix/glibc/include -Isrc/system/libroot/posix/glibc/include/arch/x86 -Iheaders/cpp -Isrc/system/libroot/posix/glibc -Iheaders/posix -Iheaders/os -Iheaders/os/kernel -Iheaders/os/storage -Iheaders/os/support -Iheaders/build/gcc-2.95.3 -Iheaders/build/gcc-2.95.3 -Iheaders -Iheaders/posix -Iheaders/gnu -Iheaders/glibc -Iheaders/os -Iheaders/os/add-ons -Iheaders/os/add-ons/file_system -Iheaders/os/add-ons/graphics -Iheaders/os/add-ons/input_server -Iheaders/os/add-ons/registrar -Iheaders/os/add-ons/screen_saver -Iheaders/os/add-ons/tracker -Iheaders/os/app -Iheaders/os/device -Iheaders/os/drivers -Iheaders/os/game -Iheaders/os/interface -Iheaders/os/kernel -Iheaders/os/media -Iheaders/os/mail -Iheaders/os/midi -Iheaders/os/midi2 -Iheaders/os/net -Iheaders/os/opengl -Iheaders/os/storage -Iheaders/os/support -Iheaders/os/translation -Iheaders/private/. -Iheaders/cpp -o "generated/objects/haiku/x86/release/libs/stdc++/cstrio.o"

And here is the result:

In file included from /boot/home/extra_stuff/src/system/libroot/posix/glibc/include/bits/waitstatus.h:63,

from /boot/home/extra_stuff/src/system/libroot/posix/glibc/stdlib/stdlib.h:44, from /boot/home/extra_stuff/headers/cpp/stl_alloc.h:59, from /boot/home/extra_stuff/headers/cpp/alloc.h:21, from /boot/home/extra_stuff/headers/cpp/std/bastring.h:39, from /boot/home/extra_stuff/headers/cpp/string:6, from /boot/home/extra_stuff/src/libs/stdc++/sinst.cc:36:

/boot/home/extra_stuff/src/system/libroot/posix/glibc/include/endian.h:1: string/endian.h: Operation not allowed

When adding some debug to vnode_path_to_vnode() in vfs.cpp, we see this:

KERN: vnode_path_to_vnode: top of loop. p = 0x90c34000, p = 'headers/cpp/string/endian.h' KERN: vnode_path_to_vnode: top of loop. p = 0x90c34008, p = 'cpp/string/endian.h' KERN: vnode_path_to_vnode: top of loop. p = 0x90c3400c, p = 'string/endian.h' KERN: vnode_path_to_vnode: top of loop. p = 0x90c34013, p = 'endian.h' KERN: bfs: bfs_access:1360: Operation not allowed

The reason is "headers/cpp/string" is a file so when processing the "string" component of this directory, it fails with the "Operation not allowed" error because it tries to open the file "string" with access mode "X_OK" (vnode_path_to_vnode() treats all path components as directories).

The problem is not in vnode_path_to_vnode() as this behaviour is expected (although it seems POSIX defines that this error should be "Not a directory" and not "Operation not allowed" so what is happening is that, somehow, GCC is checking for include paths in a weird order or our include paths have a specific pattern that makes if fails. For example, it could be something like this:

1 - We have a path "a/b" and another "a/c" in our include path. 2 - Some file does #include "string/endian.h". 3 - There is a "a/c/string/endian.h" file but there is also a "/a/b/string" file. 4 - Due to the way the paths are being searched, if tries "/a/b" first and errors out as described before it can check "/a/c".

So, in summary:

1 - The erro returned should be "Not a directory". 2 - Our include paths may or may not be broken in the Haiku build system. 3 - We may or may not have a bug in GCC.

So, including axeld and ingo in this ticket.

[bga]

It turns out what I first discarded as a minor issue was the culprit. When searching for include files, GCC checks for "Not a directory" errors and if it find them, skips to the next include dir. If it finds any other error (like "Operation not allowed") it will abort as it does not know how to handle it.

I created a fix that may not be ideal but works. Assigning this bug to myself and will mark it as fixed as soon as Haiku finishes compiling inside itself. :)

[bga]

Fixed on hrev24720. Haiku is now self-hosted! :)