* internal / external include files
@ 2019-07-24 9:11 Martin Kaiser
2019-07-24 9:21 ` Greg KH
0 siblings, 1 reply; 4+ messages in thread
From: Martin Kaiser @ 2019-07-24 9:11 UTC (permalink / raw)
To: kernelnewbies
Dear all,
is it correct that the files under include/uapi/ can be included by a
user space application?
I just ran into an error where my application ended up including
include/uapi/linux/stddef.h (with a number of intermediate steps).
This fails because the kernel's stddef.h includes
include/linux/compiler_types.h and this file is internal to
the kernel.
What is the correct way to solve this? Should I fix my include path to
make sure that my application picks the stddef.h in the compiler's
sysroot rather than the kernel's stddef.h?
Or should include/uapi/linux/stddef.h guard the kernel-internal parts
using #ifdef __KERNEL__?
Thanks,
Martin
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: internal / external include files
2019-07-24 9:11 internal / external include files Martin Kaiser
@ 2019-07-24 9:21 ` Greg KH
2019-07-24 21:20 ` Martin Kaiser
0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2019-07-24 9:21 UTC (permalink / raw)
To: kernelnewbies
On Wed, Jul 24, 2019 at 11:11:00AM +0200, Martin Kaiser wrote:
> Dear all,
>
> is it correct that the files under include/uapi/ can be included by a
> user space application?
Yes.
> I just ran into an error where my application ended up including
> include/uapi/linux/stddef.h (with a number of intermediate steps).
That's odd, what did you ask to be included that caused that?
> This fails because the kernel's stddef.h includes
> include/linux/compiler_types.h and this file is internal to
> the kernel.
What kernel version did this happen for?
> What is the correct way to solve this? Should I fix my include path to
> make sure that my application picks the stddef.h in the compiler's
> sysroot rather than the kernel's stddef.h?
The system stddef.h should always be used "first".
> Or should include/uapi/linux/stddef.h guard the kernel-internal parts
> using #ifdef __KERNEL__?
There should no longer be any need for that.
thanks,
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: internal / external include files
2019-07-24 9:21 ` Greg KH
@ 2019-07-24 21:20 ` Martin Kaiser
2019-07-25 5:45 ` Re[3]: " Konstantin Andreev
0 siblings, 1 reply; 4+ messages in thread
From: Martin Kaiser @ 2019-07-24 21:20 UTC (permalink / raw)
To: kernelnewbies
Thus wrote Greg KH (greg@kroah.com):
> That's odd, what did you ask to be included that caused that?
I called gcc with -I $KERNEL_ROOT/include/uapi. This is the chain of
files that were included.
my_app.c
$GCC_SYSROOT/usr/include/netinet/in.h
$GCC_SYSROOT/usr/include/sys/socket.h
$KERNEL_ROOT/include/uapi/asm-generic/socket.h
$KERNEL_ROOT/include/uapi/linux/posix_types.h
$KERNEL_ROOT/include/uapi/linux/stddef.h
and the error is
$KERNEL_ROOT/include/uapi/linux/stddef.h:2:34: fatal error:
linux/compiler_types.h: No such file or directory
#include <linux/compiler_types.h>
> > This fails because the kernel's stddef.h includes
> > include/linux/compiler_types.h and this file is internal to
> > the kernel.
> What kernel version did this happen for?
I get the error with today's linux-next tree. 4.14 is fine.
> > What is the correct way to solve this? Should I fix my include path to
> > make sure that my application picks the stddef.h in the compiler's
> > sysroot rather than the kernel's stddef.h?
> The system stddef.h should always be used "first".
My understanding of the gcc manual is that directories specified with -I
are searched before the system directories.
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Directory-Options.html#Directory-Options
So it seems that -I /my/kernel/include/uapi is not a good idea since the
kernel's include files take precedence then.
Best regards,
Martin
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re[3]: internal / external include files
2019-07-24 21:20 ` Martin Kaiser
@ 2019-07-25 5:45 ` Konstantin Andreev
0 siblings, 0 replies; 4+ messages in thread
From: Konstantin Andreev @ 2019-07-25 5:45 UTC (permalink / raw)
To: kernelnewbies
Hi, Martin.
The [$KERNEL_ROOT/include/uapi/linux/stddef.h] you are talking about is just a few lines:
| #include <linux/compiler_types.h>
|
| #ifndef __always_inline
| #define __always_inline inline
| #endif
it turns into
| #ifndef __always_inline
| #define __always_inline inline
| #endif
after [make headers_install] installs it into [/usr/include/linux/stddef.h].
Userspace applications shall not use kernel tree directly.
Regards, Konstantin.
Martin Kaiser, 25 jul 2010 00:20 msk:
>
> I called gcc with -I $KERNEL_ROOT/include/uapi. This is the chain of files that were included.
>
> my_app.c
> $GCC_SYSROOT/usr/include/netinet/in.h
> ...
>
> and the error is
>
> $KERNEL_ROOT/include/uapi/linux/stddef.h:2:34: fatal error: linux/compiler_types.h: No such file or directory #include <linux/compiler_types.h>
>
> Best regards, Martin
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-07-25 5:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-24 9:11 internal / external include files Martin Kaiser
2019-07-24 9:21 ` Greg KH
2019-07-24 21:20 ` Martin Kaiser
2019-07-25 5:45 ` Re[3]: " Konstantin Andreev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).