Hi! Ludovic Courtès writes: >[...] > It’s the same story as . >[...] > So this is again #include_next not picking the right due to > search path ordering issues and/or duplicate entries. > > Thoughts anyone? > > I think we need a proper fix but the feedback we got from GCC folks last > time didn’t give me much insight as to what we should do. AFAIR, the issue comes from using XXX_INCLUDE_PATH instead of CPATH because it includes gcc predefined paths: 1. The order matters. 2. The internal order may need duplicated paths. 3. Even providing the right duplicated paths through these variables may not be supported may not work, it's an implementation detail after all. This was changed because we wanted to avoid warnings on installed libraries which could be raised to errors with -Werror. I personally don't like that approach, as the included headers are being compiled in that moment so I think the -Werror should apply too, but indeed I understand the reasons behind the compatibility with FHS. The problem comes to generalizing this approach: there should be inputs that must not enter the realm of these variables, mainly gcc and libc, libc:static, libstdc++, and so on. The attached WIP-patch would be a rough approach to that, but it will take some time until I recompile the world to really test it. Also this isn't the best approach as the manifests shouldn't include these neither, but I still don't find where and how to mark these inputs cleanly. WDYT? Any idea is welcome. :-) Happy hacking! Miguel