2

vpp cross compilation while being integrated into buildroot project fails with the following error:

ERROR: unsafe header/library path used in cross-compilation: '-I/usr/include

it's appeared to have oldincludedir exporting for non-gnu toolchain enabled and so it producing this inclusion during configure process.

the problem seems to be quite common once the buildroot project added option for paranoid unsafe path checking as described here:

>> >> This error appear if one of the following paths is used during the
>> >> cross-compilation:
>> >> "/lib"
>> >> "/usr/include"
>> >> "/usr/lib"
>> >> "/usr/local/include"
>> >> "/usr/local/lib"

how to exclude oldincludedir generation inside configure or how to alter it's value instead of

oldincludedir='/usr/include'

to be configured similar to the includedir variable:

includedir='${prefix}/include'

?

Oleg Kokorin
  • 2,288
  • 2
  • 16
  • 28
  • for the quick update, the file responsible for the hardcoded path inclusion appeared to be: https://github.com/vpp-dev/vpp/blob/master/build-data/packages/vpp.mk where the unsafe path is hardcoded on the line 24 – Oleg Kokorin May 18 '17 at 09:29

1 Answers1

1

detailed explanation about paranoid unsafe path checking being found here but the link seems to be very much temporary so the copy will be posted in this answer too:

toolchain-external: instrument wrapper to warn about unsafe paths

The CodeSourcery toolchains have a very interesting feature: they warn the user when an unsafe header or library path is used, i.e a path that will lead host headers or libraries to leak into the build.

This commit adds a similar functionality into our external toolchain wrapper, so that it can be used with all external toolchains, and can also be tuned as needed. By default, the external toolchain wrapper now gives warnings such as:

  arm-linux-gcc: WARNING: unsafe header/library path used in cross-compilation: '-I /usr/foo'
  arm-linux-gcc: WARNING: unsafe header/library path used in cross-compilation: '-L /usr/bleh'

but the compilation continues successfully. One can then easily grep in his build log to search for occurences of this message.

Optionally, if BR_COMPILER_PARANOID_UNSAFE_PATH is defined in the environment to a non empty value, the external wrapper will instead error out and abort the compilation.

Oleg Kokorin
  • 2,288
  • 2
  • 16
  • 28