It would be nice, if there was some specific location for architecture specific headers and if gcc could automatically pick them up during build. This would help to solve one of Ruby issues [1]. The same issues suffer also other packages, such as SDL or Python, which are using various workarounds to solve this issue [2]. Actually, there seems to be such location already: $ `gcc -print-prog-name=cc1` -v ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.1/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../x86_64-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-redhat-linux/4.8.1/include /usr/local/include /usr/include End of search list. The "/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../x86_64-redhat-linux/include" might be the path, but it does not look to conform to FHS. If there are doubts about the arch specific header location (since FHS does not seems to be of help here), I don't mind to reach FPC to provide some guidance (guidelines for this enhancement would be needed anyway). Thanks for considering. [1] https://bugzilla.redhat.com/show_bug.cgi?id=977941 [2] https://lists.fedoraproject.org/pipermail/devel/2013-June/184446.html
Ping ... any news about that?
Just FTR, we have currently this multilib wrapper in Ruby: http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/config.h http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/ruby.spec#n556 As it turns out, this wrapper makes issues for some builds (bug 1412274). There are also other approaches how to solve the multilib issues, such as [1], but this would be superior. The only thing which would be needed is to move the config.h into the arch specific location, which would get automatically on header search path of GCC. [1] https://fedorahosted.org/fpc/ticket/312#comment:23