GithubHelp home page GithubHelp logo

jvoisin / fortify-headers Goto Github PK

View Code? Open in Web Editor NEW
12.0 6.0 2.0 222 KB

Standalone portable header-based implementation of FORTIFY_SOURCE=3

License: BSD Zero Clause License

Makefile 6.38% C 93.62%
c fortify-source libc security

fortify-headers's People

Contributors

awilfox avatar jvoisin avatar ncopa avatar nekopsykose avatar q66 avatar sbyx avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

Forkers

nekopsykose

fortify-headers's Issues

strncpy/stpncpy overlap checks are defective

They check overlap across the whole range of the given length, but the given length is not what will actually be copied, rather it's the maximum length (if src is shorter, only length of src will be copied). This triggers false positives and traps where it shouldn't (e.g. in ICU tests).

stdio.h wrapper produces format-nonliteral warnings on gcc

For example when compiling the fgets.c example or any of tests that include stdio.h:

$ "$CC" -Wformat -Wformat-nonliteral -Iinclude -D_FORTIFY_SOURCE=1 -O1 fgets.c 
In file included from fgets.c:1:
include/stdio.h: In function 'snprintf':
include/stdio.h:253:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
 253 | return __orig_snprintf(__s, __n, __f, __builtin_va_arg_pack());
 | ^~~~~~
include/stdio.h: In function 'sprintf':
include/stdio.h:269:17: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
 269 | __r = __orig_snprintf(__s, __b, __f, __builtin_va_arg_pack());
 | ^~~
include/stdio.h:273:17: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
 273 | __r = __orig_sprintf(__s, __f, __builtin_va_arg_pack());
 | ^~~
include/stdio.h: In function 'printf':
include/stdio.h:286:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
 286 | return __orig_printf(__f, __builtin_va_arg_pack());
 | ^~~~~~
include/stdio.h: In function 'fprintf':
include/stdio.h:300:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
 300 | return __orig_fprintf(__s, __f, __builtin_va_arg_pack());
 | ^~~~~~

$ "$CC" --version
mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r20028-43d71ad93e) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This is probably a gcc bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110834), however the practical effect of this is that it’s not possible to use FORTIFY and format-nonliteral enforcement in a project at the same time, both of which are very useful from a security perspective.

A concrete example of this is in the context of OpenWrt (openwrt/openwrt#13016), which is currently using the “1.1” version of this project from 2f30.org.

Since, from the point of view of an application, stdio.h is a system header, it’s messy to work around this in an application project directly. Until the gcc bug is fixed (which will probably take a long time), a viable workaround could be to simply suppress this warning within the affected wrapper functions in the fortify-headers stdio.h.

Make use of static analysis

  • coverity: done in d343ba0
  • clang-tidy: finds nothing.
  • codeql
    • /opt/hostedtoolcache/CodeQL/2.14.1/x64/codeql/codeql database finalize --finalize-dataset --threads=2 --ram=5907 /home/runner/work/_temp/codeql_databases/cpp
      CodeQL detected code written in C/C++ but could not process any of it. Review our troubleshooting guide at https://gh.io/troubleshooting-code-scanning/no-source-code-seen-during-build.
      Error: Encountered a fatal error while running "/opt/hostedtoolcache/CodeQL/2.14.1/x64/codeql/codeql database finalize --finalize-dataset --threads=2 --ram=5907 /home/runner/work/_temp/codeql_databases/cpp". Exit code was 32 and error was: CodeQL detected code written in C/C++ but could not process any of it. Review our troubleshooting guide at https://gh.io/troubleshooting-code-scanning/no-source-code-seen-during-build.

Check that all functions are in the proper headers

16:49 <@q66> we'll need to go through all new fortifications you added and check them against libc headers
16:49 <@q66> following musl's headers is a good idea for this because afaik musl already tries to be the strictest in terms of what it makes available and when
16:50 <@q66> so in a "looser" libc you won't get a breakage but rather you'll just lose fortify for that one func

Fix missing includes

As reported by @q66 on irc:

/usr/include/fortify/poll.h:39:2: error: use of undeclared identifier 'size_t'; did you mean 'sizeof'?
   39 |         size_t __b = __bos(__f, 0);
      |         ^
/usr/include/fortify/poll.h:39:13: error: expression is not assignable
   39 |         size_t __b = __bos(__f, 0);
      |         ~~~~~~~~~~ ^
/usr/include/fortify/poll.h:39:9: error: use of undeclared identifier '__b'
   39 |         size_t __b = __bos(__f, 0);
      |                ^
/usr/include/fortify/poll.h:41:12: error: use of undeclared identifier '__b'
   41 |         if (__n > __b / sizeof(struct pollfd))
      |                   ^
/usr/include/fortify/poll.h:54:2: error: use of undeclared identifier 'size_t'; did you mean 'sizeof'?
   54 |         size_t __b = __bos(__f, 0);
      |         ^
/usr/include/fortify/poll.h:54:13: error: expression is not assignable
   54 |         size_t __b = __bos(__f, 0);
      |         ~~~~~~~~~~ ^
/usr/include/fortify/poll.h:54:9: error: use of undeclared identifier '__b'
   54 |         size_t __b = __bos(__f, 0);
      |                ^
/usr/include/fortify/poll.h:56:12: error: use of undeclared identifier '__b'; did you mean '__n'?
   56 |         if (__n > __b / sizeof(struct pollfd))
      |                   ^
/usr/include/fortify/poll.h:51:72: note: '__n' declared here
   51 | _FORTIFY_FN(ppoll) int ppoll(struct pollfd * _FORTIFY_POS0 __f, nfds_t __n,

Fix `wctomb`

The current implementation is wrong: it's valid to pass a buffer smaller than MB_CUR_MAX to wctomb. The only thing we can do is check that the return value of wctomb is smaller than the size of the buffer.

Avoid unnecessarily calling slower functions

For example, in strcpy (ignoring the UB overlapping check):

size_t __n = strlen(__s) + 1;
/* trap if pointers are overlapping but not if dst == src.
* gcc seems to like to generate code that relies on dst == src */
if ((__d < __s && __d + __n > __s) ||
(__s < __d && __s + __n > __d))
__builtin_trap();
size_t __b = __bos(__d, 0);
if (__n > __b)
__builtin_trap();
return __orig_strcpy(__d, __s);

By the time, __orig_strcpy is called, the length has already been computed and has been established to be in bound. There's no need to pay for the nul-byte search again inside of __orig_strcpy when the faster memcpy can be called instead.

Some of the other str* functions suffer from the same issue.

Decide what we want to do for realloc(a, 0)

Until C23, if new_size is zero, the behavior is implementation defined (null pointer may be returned (in which case the old memory block may or may not be freed), or some non-null pointer may be returned that may not be used to access storage). Such usage is deprecated (via C DR 400).(since C17)

Since C23, if new_size is zero, the behavior is undefined.

The conservative thing to do is to only catch new_size=0 when compiling with C23, but I'm wondering if we should always return NULL otherwise.

Make use of `diagnose_if`

Make use of diagnose_if for things like:

  • memset called n set to 0, likely indicating that arguments got inverted.
  • realpath with path set to NULL, likely indicating that arguments got inverted.
  • umask with mode & ~0777.
  • printf format strings may only contain the %n format specifier if the format string resides in read-only memory.

And add tests for it.

Add guards to functions who need some

16:47 <@q66> e.g. fdopen needs to be behind
16:47 <@q66> #if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
16:47 <@q66>  || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) \
16:47 <@q66>  || defined(_BSD_SOURCE)
16:47 <@q66> but that's for a separate PR
16:48 <@q66> same with fmemopen etc

Resources

Documentation:

Implementations:

User-facing documentation

Tests:

Add compile-time checks

Something like:

void *memcpy(void  *d, const void *s, size_t __n) {
  if (__builtin_constant_p(__n) && __n > __bos(od)) {
    compile-time-error!
  }
}

Apparently, the trick everyone is using to make the compiler choke is this one:

#define __errordecl(name, msg) extern void name(void) __attribute__((__error__(msg)))
#define __warnattr(msg) __attribute__((__warning__(msg)))

This should be used only when warning_if isn't supported.

Make use of __chk variants

eg.

#define snprintf(str, len, ...) \
    __builtin___snprintf_chk(str, len, 0, builtin_object_size(str), __VA_ARGS__)

GCC 12 has those for memcpy, mempcpy, memmove, memset, strcpy, stpcpy, strncpy, strcat and strncat.

Fix str(r)chr hardening

I disabled it for now, but the str(r)chr hardening is currently UB and it crashes several parts of the Python test suite. I don't know if the NULL subtraction is the sole part, but it's the only I can think of right now.

Improve C++ support

As said by Dmytro Hrybenko:

consider adding a hyrum's law buster until you are ready to support c++

#ifdef __cplusplus
#error this library only supports C
#endif

Fortify `*chr`

  • memrchr: glibc trash.
  • memchr
  • rawmemchr: deprecated glibc trash.
  • strchr
  • strrchr

building llvm compiler-rt(?) fails when compiler using fortify headers

FAILED: lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/eprintf.c.o 
/builddir/llvm-bootstrap-17.0.6/build/./bin/clang --target=x86_64-chimera-linux-musl -DVISIBILITY_HIDDEN  -Wformat -Werror=format-security -ftrivial-auto-var-init=zero -fstack-clash-protection -O2 -pipe -ffile-prefix-map=/builddir/llvm-bootstrap-17.0.6=. -fPIC -O3 -DNDEBUG -m32 -fno-lto -std=c11 -fno-builtin -fvisibility=hidden -fomit-frame-pointer -DCOMPILER_RT_HAS_FLOAT16 -MD -MT lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/eprintf.c.o -MF lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/eprintf.c.o.d -o lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/eprintf.c.o -c /builddir/llvm-bootstrap-17.0.6/compiler-rt/lib/builtins/eprintf.c
In file included from /builddir/llvm-bootstrap-17.0.6/compiler-rt/lib/builtins/eprintf.c:10:
/usr/include/fortify/stdio.h:150:47: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 2 of function '__orig_vsnprintf' has type 'size_t' (aka 'unsigned long'), but parameter 2 of function '__builtin_vsnprintf' has type 'unsigned int'
  150 | __diagnose_as_builtin(__builtin_vsnprintf, 1, 2, 3, 4)
      |                                               ^
1 error generated.
[105/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/udivsi3.c.o
[106/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/udivti3.c.o
[107/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/clear_cache.c.o
[108/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/i386/fp_mode.c.o
[109/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/umodsi3.c.o
[110/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/enable_execute_stack.c.o
[111/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/emutls.c.o
FAILED: lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/emutls.c.o 
/builddir/llvm-bootstrap-17.0.6/build/./bin/clang --target=x86_64-chimera-linux-musl -DVISIBILITY_HIDDEN  -Wformat -Werror=format-security -ftrivial-auto-var-init=zero -fstack-clash-protection -O2 -pipe -ffile-prefix-map=/builddir/llvm-bootstrap-17.0.6=. -fPIC -O3 -DNDEBUG -m32 -fno-lto -std=c11 -fno-builtin -fvisibility=hidden -fomit-frame-pointer -DCOMPILER_RT_HAS_FLOAT16 -MD -MT lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/emutls.c.o -MF lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/emutls.c.o.d -o lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/emutls.c.o -c /builddir/llvm-bootstrap-17.0.6/compiler-rt/lib/builtins/emutls.c
In file included from /builddir/llvm-bootstrap-17.0.6/compiler-rt/lib/builtins/emutls.c:11:
/usr/include/fortify/string.h:45:47: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_memcpy' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_memcpy' has type 'unsigned int'
   45 | __diagnose_as_builtin(__builtin_memcpy, 1, 2, 3)
      |                                               ^
/usr/include/fortify/string.h:70:48: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_memmove' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_memmove' has type 'unsigned int'
   70 | __diagnose_as_builtin(__builtin_memmove, 1, 2, 3)
      |                                                ^
/usr/include/fortify/string.h:89:47: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_memset' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_memset' has type 'unsigned int'
   89 | __diagnose_as_builtin(__builtin_memset, 1, 2, 3)
      |                                               ^
/usr/include/fortify/string.h:107:47: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_memchr' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_memchr' has type 'unsigned int'
  107 | __diagnose_as_builtin(__builtin_memchr, 1, 2, 3)
      |                                               ^
/usr/include/fortify/string.h:262:48: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_strncat' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_strncat' has type 'unsigned int'
  262 | __diagnose_as_builtin(__builtin_strncat, 1, 2, 3)
      |                                                ^
/usr/include/fortify/string.h:285:48: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_strncpy' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_strncpy' has type 'unsigned int'
  285 | __diagnose_as_builtin(__builtin_strncpy, 1, 2, 3)
      |                                                ^
6 errors generated.

trying to reproduce normally with -fno-builtin or similar doesn't repro, so there is probably something funny in the compiler-rt build

Crossdev - Unable to create a musl mips cross-toolchain error: unsupported long double type

I've been testing using these headers on one of Gentoo build servers and found an issue where crossdev (Gentoo's cross compile toolchain tool) can no longer build musl toolchains.

This was an old bug in Gentoo which was solved a long time ago ( https://bugs.gentoo.org/498114 ) but for some reason when fortify headers is enabled it fails but disabling it makes it work again. I'm stumped as to what could be the cause but more than happy to test any suggestions while I keep looking into possible causes as I really don't know why these headers are causing the issue.

Error:

checking whether compiler's long double definition matches float.h... no
./configure: error: unsupported long double type
 ERROR: cross-mipsel-unknown-linux-musl/musl-1.2.4::local failed (configure phase):

Steps to reproduce:

  1. Install Gentoo Hardened stage3
  2. Add https://git.alpinelinux.org/aports/plain/main/gcc/0016-add-fortify-headers-paths.patch to /etc/portage/patches/sys-devel/gcc
  3. emerge -va sys-devel/gcc
  4. emerge -va sys-devel/crossdev
  5. crossdev -s4 mipsel-unknown-linux-musl

Full build log:

Calculating dependencies  
 * IMPORTANT: 16 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

... done!
Dependency resolution took 1.36 s.


>>> Verifying ebuild manifests

>>> Emerging (1 of 1) cross-mipsel-unknown-linux-musl/musl-1.2.4::local
 * musl-1.2.4.tar.gz BLAKE2B SHA512 size ;-) ...                         [ ok ]
 * getconf.c BLAKE2B SHA512 size ;-) ...                                 [ ok ]
 * musl-getent-93a08815f8598db442d8b766b463d0150ed8e2ab.c BLAKE2B SHA512 size ;-) ...            [ ok ]
 * iconv.c BLAKE2B SHA512 size ;-) ...                                   [ ok ]
>>> Unpacking source...
>>> Unpacking musl-1.2.4.tar.gz to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
>>> Unpacking getconf.c to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
unpack getconf.c: file format not recognized. Ignoring.
>>> Unpacking musl-getent-93a08815f8598db442d8b766b463d0150ed8e2ab.c to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
unpack musl-getent-93a08815f8598db442d8b766b463d0150ed8e2ab.c: file format not recognized. Ignoring.
>>> Unpacking iconv.c to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
unpack iconv.c: file format not recognized. Ignoring.
>>> Source unpacked in /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
>>> Preparing source in /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4 ...
gcc
checking for C compiler... gcc
checking whether C compiler works... yes
checking whether compiler accepts -Werror=unknown-warning-option... no
checking whether compiler accepts -Werror=unused-command-line-argument... no
checking whether compiler accepts -Werror=ignored-optimization-argument... no
checking whether linker accepts -Werror=unknown-warning-option... no
checking whether linker accepts -Werror=unused-command-line-argument... no
checking for C compiler family... gcc
checking target system type... mipsel-unknown-linux-musl
checking whether compiler accepts -std=c99... yes
checking whether compiler accepts -nostdinc... yes
checking whether compiler accepts -ffreestanding... yes
checking whether compiler accepts -fexcess-precision=standard... yes
checking whether compiler accepts -frounding-math... yes
checking whether compiler accepts -fno-strict-aliasing... yes
checking whether compiler needs attribute((may_alias)) suppression... no
checking whether compiler accepts -Wa,--noexecstack... yes
checking whether compiler accepts -fno-stack-protector... yes
checking whether compiler accepts -fno-tree-loop-distribute-patterns... yes
checking whether we should preprocess assembly to add debugging information... no
checking for optimization settings... using provided CFLAGS
checking whether compiler accepts -pipe... yes
checking whether compiler accepts -fomit-frame-pointer... yes
checking whether compiler accepts -fno-unwind-tables... yes
checking whether compiler accepts -fno-asynchronous-unwind-tables... yes
checking whether compiler accepts -ffunction-sections... yes
checking whether compiler accepts -fdata-sections... yes
checking whether compiler accepts -Wno-pointer-to-int-cast... yes
checking whether compiler accepts -Werror=implicit-function-declaration... yes
checking whether compiler accepts -Werror=implicit-int... yes
checking whether compiler accepts -Werror=pointer-sign... yes
checking whether compiler accepts -Werror=pointer-arith... yes
checking whether compiler accepts -Werror=int-conversion... yes
checking whether compiler accepts -Werror=incompatible-pointer-types... yes
checking whether compiler accepts -Werror=discarded-qualifiers... yes
checking whether compiler accepts -Werror=discarded-array-qualifiers... yes
checking whether compiler accepts -Waddress... yes
checking whether compiler accepts -Warray-bounds... yes
checking whether compiler accepts -Wchar-subscripts... yes
checking whether compiler accepts -Wduplicate-decl-specifier... yes
checking whether compiler accepts -Winit-self... yes
checking whether compiler accepts -Wreturn-type... yes
checking whether compiler accepts -Wsequence-point... yes
checking whether compiler accepts -Wstrict-aliasing... yes
checking whether compiler accepts -Wunused-function... yes
checking whether compiler accepts -Wunused-label... yes
checking whether compiler accepts -Wunused-variable... yes
checking preprocessor condition __PIC__... true
checking whether linker accepts -Wl,--sort-section,alignment... yes
checking whether linker accepts -Wl,--sort-common... yes
checking whether linker accepts -Wl,--gc-sections... yes
checking whether linker accepts -Wl,--hash-style=both... yes
checking whether linker accepts -Wl,--no-undefined... yes
checking whether linker accepts -Wl,--exclude-libs=ALL... yes
checking whether linker accepts -Wl,--dynamic-list=./dynamic.list... yes
checking whether linker accepts -lgcc... yes
checking whether linker accepts -lgcc_eh... yes
using compiler runtime libraries: -lgcc -lgcc_eh
checking preprocessor condition __mips_isa_rev >= 6... false
checking preprocessor condition _MIPSEL || __MIPSEL || __MIPSEL__... false
checking preprocessor condition __mips_soft_float... false
checking whether compiler's long double definition matches float.h... no
./configure: error: unsupported long double type
 * ERROR: cross-mipsel-unknown-linux-musl/musl-1.2.4::local failed (configure phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line 136:  Called src_configure
 *   environment, line 1735:  Called die
 * The specific snippet of code:
 *       ./configure --target=${CTARGET} --prefix="${EPREFIX}${sysroot}/usr" --syslibdir="${EPREFIX}${sysroot}/lib" --disable-gcc-wrapper || die
 * 
 * If you need support, post the output of `emerge --info '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`,
 * the complete build log and the output of `emerge -pqv '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`.
 * The complete build log is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'
 * S: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'

>>> Failed to emerge cross-mipsel-unknown-linux-musl/musl-1.2.4, Log file:

>>>  '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/build.log'
 * Messages for package cross-mipsel-unknown-linux-musl/musl-1.2.4:
 * ERROR: cross-mipsel-unknown-linux-musl/musl-1.2.4::local failed (configure phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line 136:  Called src_configure
 *   environment, line 1735:  Called die
 * The specific snippet of code:
 *       ./configure --target=${CTARGET} --prefix="${EPREFIX}${sysroot}/usr" --syslibdir="${EPREFIX}${sysroot}/lib" --disable-gcc-wrapper || die
 * 
 * If you need support, post the output of `emerge --info '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`,
 * the complete build log and the output of `emerge -pqv '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`.
 * The complete build log is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'
 * S: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'

Fix clang

In /usr/include/x86_64-linux-gnu/sys/cdefs.h, there is the following:

/* Fortify support.  */
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1)                                                                                                                            
#define __bos0(ptr) __builtin_object_size (ptr, 0)

and for some reasons, clang thinks it's a great idea to go look there, colliding with our own __bos macro:

$ ~/dev/fortify-headers make -C tests/ clean clang 
make: Entering directory '/home/jvoisin/dev/fortify-headers/tests'
In file included from test_FD_CLR_SETSIZE.c:1:
In file included from ./common.h:19:
In file included from ../include/unistd.h:26:
../include/fortify-headers.h:63:9: warning: '__bos' macro redefined [-Wmacro-redefined]
#define __bos(ptr, type) __builtin_dynamic_object_size (ptr, type)
        ^
/usr/include/x86_64-linux-gnu/sys/cdefs.h:123:9: note: previous definition is here
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1)
$

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.