Project

General

Profile

Actions

Bug #12430

open

Our Headers break clang

Added by Till Wegmüller over 1 year ago. Updated 10 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
lib - userland libraries
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

While compiling newest firefox I stumbled upon the following error

In file included from <built-in>:2:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil_visibility.h:26:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil/log.h:25:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil/avutil.h:296:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil/common.h:36:
/usr/clang/9.0/lib/clang/9.0.1/include/stdint.h:217:25: error: typedef redefinition with different types ('int16_t' (aka 'short') vs 'int')
typedef __int_least16_t int_fast16_t;
                        ^
/usr/include/sys/int_types.h:136:15: note: previous definition is here
typedef int                     int_fast16_t;
                                ^
In file included from <built-in>:2:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil_visibility.h:26:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil/log.h:25:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil/avutil.h:296:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil/common.h:36:
/usr/clang/9.0/lib/clang/9.0.1/include/stdint.h:218:26: error: typedef redefinition with different types ('uint16_t' (aka 'unsigned short') vs 'unsigned int')
typedef __uint_least16_t uint_fast16_t;
                         ^
/usr/include/sys/int_types.h:147:23: note: previous definition is here
typedef unsigned int            uint_fast16_t;
                                ^
In file included from <built-in>:2:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil_visibility.h:26:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil/log.h:25:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil/avutil.h:296:
In file included from /vagrant/components/web/firefox/firefox-68.6.0/media/ffvpx/libavutil/common.h:36:
/usr/clang/9.0/lib/clang/9.0.1/include/stdint.h:224:23: error: typedef redefinition with different types ('signed char' vs 'char')
typedef __INT8_TYPE__ int8_t;
                      ^
/usr/include/sys/int_types.h:75:16: note: previous definition is here
typedef char                    int8_t;
                                ^
3 errors generated.

Turns out glibc has type guards in place which are respected by clang. The following snippet from stdint.h show this in practice.

#ifdef __INT8_TYPE__
#ifndef __int8_t_defined  /* glibc sys/types.h also defines int8_t*/
typedef __INT8_TYPE__ int8_t;
#endif /* __int8_t_defined */

However our headers do not have the same defines. Thus compilation of programs that build with clang i.e. rust and Firefox which include C code which in turn includes stdint.h fails.

To solve this we will need at least these defines:
_int8_t_defined
_uint32_t_defined
__intptr_t_defined

Clang seems to also use the same safeguard to stop glibc from defining the same types if clang headers are included first. See this example from stdint.h

/* prevent glibc sys/types.h from defining conflicting types */
#ifndef __int8_t_defined
# define __int8_t_defined
#endif /* __int8_t_defined */

We will need to be compatible with this or make clang be compatible with us.

Actions #1

Updated by Till Wegmüller over 1 year ago

There seems to be a similar problem with /usr/clang/9.0/lib/clang/9.0.1/include/mm_malloc.h where clang redefines system headers in it's own way!!! No wonder Firefox's memory allocator is broken.

Actions #2

Updated by Carsten Grzemba 10 months ago

It seems it is only related to the (FF)/media/ffvpx/libavutil code. So, perhaps patch this code is also an option.

Actions #3

Updated by Joshua M. Clulow 10 months ago

I would say that anywhere there is a relatively simple pre-existing guard that a common implementation (e.g., glibc, FreeBSD libc, etc) is already using, and which Clang respects, we should probably just adopt in our headers. Things like __int8_t_defined seem pretty low-maintenance.

Actions #4

Updated by Rich Lowe 10 months ago

Is this another case where the compiler tries to "fix" our headers, like GCC's fixincludes/include-fixed? If so, do we want to go through and fix any real problems it's trying to work around, as well as perhaps introduce guards as Joshua suggested?

Actions #5

Updated by Jason King 10 months ago

Is the clang build being used defining __STDC_HOSTED__ as part of it's default set of macros? IIUC, that's used to tell clang (or gcc) that the build system has a full functional libc (which should also make clang avoid redefining those macros)?

Actions

Also available in: Atom PDF