2.5.3-pre1 compile error

DISCUSSION John Weber 12 participants 22 messages Jan 16, 2002 – Jan 17, 2002

Share & tools

John Weber

author

2002-01-16 00:05 UTC #0 lore raw

gcc -D__KERNEL__ -I/usr/src/linux-2.5.2/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o read_write.o read_write.c
In file included from read_write.c:10:
/usr/src/linux-2.5.2/include/linux/file.h:25: parse error before atomic_t' /usr/src/linux-2.5.2/include/linux/file.h:25: warning: no semicolon at end of struct or union /usr/src/linux-2.5.2/include/linux/file.h:36: parse error before }'
/usr/src/linux-2.5.2/include/linux/file.h: In function `fcheck_files':
/usr/src/linux-2.5.2/include/linux/file.h:50: dereferencing pointer to incomplete type /usr/src/linux-2.5.2/include/linux/file.h:51: dereferencing pointer to incomplete type
In file included from read_write.c:13:
/usr/src/linux-2.5.2/include/linux/dnotify.h: At top level:
/usr/src/linux-2.5.2/include/linux/dnotify.h:18: warning: `struct inode' declared inside parameter list /usr/src/linux-2.5.2/include/linux/dnotify.h:18: warning: its scope is only this definition or declaration, which is probably not what you want. /usr/src/linux-2.5.2/include/linux/dnotify.h:21: warning: struct inode' declared inside parameter list /usr/src/linux-2.5.2/include/linux/dnotify.h: In function inode_dir_notify':
/usr/src/linux-2.5.2/include/linux/dnotify.h:23: dereferencing pointer to incomplete type /usr/src/linux-2.5.2/include/linux/dnotify.h:24: warning: passing arg 1 of __inode_dir_notify' from incompatible pointer type read_write.c: In function sys_read':
read_write.c:167: warning: passing arg 1 of `inode_dir_notify' from incompatible pointer type
read_write.c: In function `sys_write':
read_write.c:194: warning: passing arg 1 of `inode_dir_notify' from incompatible pointer type
read_write.c: In function `do_readv_writev':
read_write.c:299: warning: passing arg 1 of `inode_dir_notify' from incompatible pointer type
read_write.c: In function `sys_pread':
read_write.c:371: warning: passing arg 1 of `inode_dir_notify' from incompatible pointer type
read_write.c: In function `sys_pwrite':
read_write.c:403: warning: passing arg 1 of `inode_dir_notify' from incompatible pointer type
make[2]: *** [read_write.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.5.2/fs'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux-2.5.2/fs'
make: *** [_dir_fs] Error 2

Benjamin LaHaise

2002-01-16 00:21 UTC #1 lore raw

Quoted 4 lines · John Weber

incompatible pointer type
read_write.c: In function `sys_pwrite':
read_write.c:403: warning: passing arg 1 of `inode_dir_notify' from incompatible pointer type

Hmm, this should fix that.

-ben

:r ~/patches/v2.5.3-pre1-file_fix.diff

include/linux/file.h +3 -0

diff -urN v2.5.3-pre1/include/linux/file.h v2.5.3-pre1-fix/include/linux/file.h
@@ -5,6 +5,9 @@
 #ifndef __LINUX_FILE_H
 #define __LINUX_FILE_H
 
+#ifndef __ASM__ATOMIC_H
+#include <asm/atomic.h>
+#endif
 #ifndef _LINUX_POSIX_TYPES_H	/* __FD_CLR */
 #include <linux/posix_types.h>
 #endif

Linus Torvalds

2002-01-16 00:30 UTC #2 lore raw

Quoted 2 lines · Benjamin LaHaise

Hmm, this should fix that.

probably will, BUT..

include/linux/file.h line 10

Quoted 3 lines

include/linux/file.h +3 -0

+#ifndef __ASM__ATOMIC_H
+#include <asm/atomic.h>
+#endif

Please do not assume knowdledge of what the different header files use to define their re-entrancy.

Just do

	#include <asm/atomic.h>

and be done with it.

Linus

Davide Libenzi

2002-01-16 00:40 UTC #3 lore raw

Quoted 14 lines · Linus Torvalds

Quoted 2 lines · Benjamin LaHaise
Hmm, this should fix that.
probably will, BUT..
include/linux/file.h line 10
Quoted 3 lines
include/linux/file.h +3 -0
+#ifndef __ASM__ATOMIC_H
+#include <asm/atomic.h>
+#endif
Please do not assume knowdledge of what the different header files use to define their re-entrancy.

Quoted 5 lines

Just do
	#include <asm/atomic.h>
and be done with it.

I needed two fixes :

#include <asm/atomic.h> in include/linux/file.h

#include <linux/fs.h> in include/linux/dnotify.h

after that it builds for me ... but it crashes at boot time

- Davide

Linus Torvalds

2002-01-16 00:44 UTC #4 lore raw

Quoted 2 lines · Davide Libenzi

after that it builds for me ... but it crashes at boot time

Where?

The main big thing in 2.5.3-pre1 is the IDE driver update, the rest looks fairly simple. I've tested the new IDE driver on my system (the famous "Works For Me" test), and it's been tested quite a lot in earlier incarnations on other platforms, but there might easily be some BIO or low-level IDE chipset interactions.

If it's not in the IDE driver, I'm at a loss.

Linus

David S. Miller

2002-01-16 00:56 UTC #5 lore raw

From: Linus Torvalds <[email protected]>
Date: Tue, 15 Jan 2002 16:43:58 -0800 (PST)

If it's not in the IDE driver, I'm at a loss.

That "#if 1" buisness in the new ide-dma.c code looks really suspicious...

Andre Hedrick

2002-01-16 01:37 UTC #6 lore raw

Well if you look at it closely, that function.

"ide_raw_build_sglist()"

is not called except from the user-space diagnostics ioctl

You that is getting called with from a BIO request, there will be major request completion problems.

That is there to allow a future "Alex Viro" suggestion be considered.

Quoted 7 lines · David S. Miller

From: Linus Torvalds <[email protected]>
Date: Tue, 15 Jan 2002 16:43:58 -0800 (PST)
If it's not in the IDE driver, I'm at a loss.
That "#if 1" buisness in the new ide-dma.c code looks really suspicious...

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Davide Libenzi

2002-01-16 01:11 UTC #7 lore raw

In reply to Linus Torvalds

Quoted 7 lines · Linus Torvalds

Quoted 2 lines · Davide Libenzi
after that it builds for me ... but it crashes at boot time
Where?

Quoted 7 lines

The main big thing in 2.5.3-pre1 is the IDE driver update, the rest looks fairly simple. I've tested the new IDE driver on my system (the famous "Works For Me" test), and it's been tested quite a lot in earlier incarnations on other platforms, but there might easily be some BIO or low-level IDE chipset interactions.
If it's not in the IDE driver, I'm at a loss.

Doh !

Trace; c0113988 <schedule+118/2b0>
Trace; c01075cd <sys_clone+1d/30>
Trace; c0105020 <init+0/140>
Trace; c0105000 <_stext+0/0>
Trace; c010720d <kernel_thread+1d/30>
Trace; c0105011 <rest_init+11/20>

Let me try something ...

- Davide

Davide Libenzi

2002-01-16 01:17 UTC #8 lore raw

Quoted 10 lines · Davide Libenzi

Doh !
Trace; c0113988 <schedule+118/2b0>
Trace; c01075cd <sys_clone+1d/30>
Trace; c0105020 <init+0/140>
Trace; c0105000 <_stext+0/0>
Trace; c010720d <kernel_thread+1d/30>
Trace; c0105011 <rest_init+11/20>
Let me try something ...

Ehmmm, let's do like if nothing happened :-)

- Davide

David Weinehall

2002-01-16 00:38 UTC #9 lore raw

In reply to Benjamin LaHaise

Quoted 14 lines · Linus Torvalds

Quoted 2 lines · Benjamin LaHaise
Hmm, this should fix that.
probably will, BUT..
include/linux/file.h line 10
Quoted 3 lines
include/linux/file.h +3 -0
+#ifndef __ASM__ATOMIC_H
+#include <asm/atomic.h>
+#endif
Please do not assume knowdledge of what the different header files use to define their re-entrancy.

Quoted 5 lines

Just do
	#include <asm/atomic.h>
and be done with it.

The lines below say:

#ifndef _LINUX_POSIX_TYPES_H /* __FD_CLR */
#include <linux/posix_types.h>
#endif

Maybe fix this while at it?!

/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\

//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Linus Torvalds

2002-01-16 00:42 UTC #10 lore raw

Quoted 5 lines · David Weinehall

Quoted 5 lines
Just do
	#include <asm/atomic.h>

Quoted 7 lines

Quoted 1 line
and be done with it.
The lines below say:
#ifndef _LINUX_POSIX_TYPES_H /* __FD_CLR */
#include <linux/posix_types.h>
#endif

At least that doesn't depend on all architectures having the same exclusion-defines, but yeah, it's ugly too.

If this actally makes any noticeable difference to compilation speed I could live with it. Does it?

Linus

Dave Jones

2002-01-16 00:56 UTC #11 lore raw

In reply to David Weinehall

Quoted 5 lines · Linus Torvalds

Quoted 3 lines
#ifndef _LINUX_POSIX_TYPES_H /* __FD_CLR */
#include <linux/posix_types.h>
#endif
If this actally makes any noticeable difference to compilation speed I could live with it. Does it?

I'm sure I read somewhere that gcc is clever enough to know when it hits a #include, it checks for a symbol equal to a mangled version of the filename before including it. (Ie, doing this transparently).

Then again, I may have imagined it all.

Signature · 2 lines

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

[email protected]

2002-01-16 02:10 UTC #12 lore raw

In reply to David Weinehall

In article <[email protected]> you write:

Quoted 7 lines · Linus Torvalds

Quoted 5 lines
Quoted 3 lines
#ifndef _LINUX_POSIX_TYPES_H /* __FD_CLR */
#include <linux/posix_types.h>
#endif
If this actally makes any noticeable difference to compilation speed I could live with it. Does it?

Quoted 6 lines

I'm sure I read somewhere that gcc is clever enough to know when it hits a #include, it checks for a symbol equal to a mangled version of the filename before including it. (Ie, doing this transparently).
Then again, I may have imagined it all.

I'm pretty sure you did, since it's perfectly legal (and occasionally useful, if gruesome) to do

#define THE_STRUCT struct1
#include "struct_def.h"
#undef THE_STRUCT
#define THE_STRUCT struct2
#include "struct_def.h"

and have both #includes work. You may be thinking of #import, which is deprecated except for objective-c, IIRC.

In answer to Linus' question...yes, in a large system redundent include guards can make a real difference, particularly for headers which get included by other headers regularly. OTOH, my last experience using them was on an underpowered Solaris box, which (a) didn't have enough memory for all the developers compiling on it and
(b) was running an old Solaris, so its read caching was pretty lame anyway. It makes rather a lot of difference if the preprocessor has to read <linux/posix_types.h> from the disk 20 times or if it can get it from the file cache 20 times.

Signature · 2 lines

Dave Meyer
[email protected]

Peter Osterlund

2002-01-16 18:33 UTC #13 lore raw

In reply to David Weinehall

Quoted 7 lines · Dave Jones

Quoted 5 lines · Linus Torvalds
Quoted 3 lines
#ifndef _LINUX_POSIX_TYPES_H /* __FD_CLR */
#include <linux/posix_types.h>
#endif
If this actally makes any noticeable difference to compilation speed I could live with it. Does it?

Quoted 6 lines

I'm sure I read somewhere that gcc is clever enough to know when it hits a #include, it checks for a symbol equal to a mangled version of the filename before including it. (Ie, doing this transparently).
Then again, I may have imagined it all.

Not exactly, but there is an optimization in cpp that makes it possible to do the cleanup Linus wants without sacrificing performance. From the cpp info pages:

The GNU C preprocessor is programmed to notice when a header file uses this particular construct and handle it efficiently. If a header file is contained entirely in a #ifndef' conditional, modulo whitespace and comments, then it remembers that fact. If a subsequent #include' specifies the same file, and the macro in the `#ifndef' is already defined, then the directive is skipped without processing the specified file at all.

I did an strace on cpp to verify that this optimization actually works.

Signature · 2 lines

Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340

Benjamin LaHaise

2002-01-16 00:44 UTC #14 lore raw

In reply to Benjamin LaHaise

Quoted 6 lines · Linus Torvalds

include/linux/file.h line 10
Quoted 3 lines
include/linux/file.h +3 -0
+#ifndef __ASM__ATOMIC_H
+#include <asm/atomic.h>
+#endif
Please do not assume knowdledge of what the different header files use to define their re-entrancy.

Well, I actually disagree on this. For large include files (fs.h is the worst), and complicated arrangement, this technique eliminates spurious includes and saves a lot on compile time (really!). If your concern is that the convention is not consistent, I'll gladly patch all of them to use the same format (ie use an __ prefix and escape / to __ and . to _).

-ben

Linus Torvalds

2002-01-16 00:47 UTC #15 lore raw

Quoted 4 lines · Benjamin LaHaise

Well, I actually disagree on this. For large include files (fs.h is the worst), and complicated arrangement, this technique eliminates spurious includes and saves a lot on compile time (really!).

Numbers please.

I'd MUCH rather just clean up the include file hierarchy than have these kinds of non-local knowledge issues.

Linus

Benjamin LaHaise

2002-01-16 00:56 UTC #16 lore raw

In reply to Benjamin LaHaise

Quoted 4 lines · Linus Torvalds

Numbers please.
I'd MUCH rather just clean up the include file hierarchy than have these kinds of non-local knowledge issues.

The last time I did it for fs.h et al (this meant pulling the fs.h and sched.h codependancy apart), it got 2.4 compiles back down to 2.2 compile times (3m -> 2m45s maybe 2m30s iirc) -- about a 10% drop in compile time. It's even more noticeable when you're doing a fully blown modular kernel build as distributions do.

-ben

Signature · 1 line

Fish.

David Weinehall

2002-01-16 01:19 UTC #17 lore raw

In reply to Benjamin LaHaise

Quoted 11 lines · Benjamin LaHaise

Quoted 4 lines · Linus Torvalds
Numbers please.
I'd MUCH rather just clean up the include file hierarchy than have these kinds of non-local knowledge issues.
The last time I did it for fs.h et al (this meant pulling the fs.h and sched.h codependancy apart), it got 2.4 compiles back down to 2.2 compile times (3m -> 2m45s maybe 2m30s iirc) -- about a 10% drop in compile time. It's even more noticeable when you're doing a fully blown modular kernel build as distributions do.

The difference between 3 minutes and 2.45 isn't really a lot imho. What is interesting if difference scales; that is, if you compile on a 486 or so, does the 10% drop still hold, or are we still talking about a difference of 15 seconds. If the latter, I'd go for the cleanup, but if the former is true, maybe, just maybe, the ugly version might be the solution.

I'd prefer all includes that can be to be non-conditional, though.

/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\

//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Robert Love

2002-01-16 01:23 UTC #18 lore raw

In reply to Benjamin LaHaise

include/linux/file.h line 10

Quoted 3 lines · Benjamin LaHaise

include/linux/file.h +3 -0

+#ifndef __ASM__ATOMIC_H
+#include <asm/atomic.h>
+#endif

gcc -D__KERNEL__ -I/home/rml/src/linux/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -c -o brlock.o brlock.c
brlock.c:21: initializer element is not constant brlock.c:21: (near initialization for `__brlock_array[0][0]') ... for all the [x][y] elements ...
brlock.c:21: initializer element is not constant brlock.c:21: (near initialization for `__brlock_array[31]')

I get this compile error under 2.5.3-pre1, too. System is SMP. 2.5.2 worked fine. I don't see a thing in the patch that would cause this ...

Robert Love

Christopher Turcksin

2002-01-17 22:16 UTC #19 lore raw

In reply to Benjamin LaHaise

Quoted 5 lines · Linus Torvalds

Quoted 3 lines
Well, I actually disagree on this. For large include files (fs.h is the worst), and complicated arrangement, this technique eliminates spurious includes and saves a lot on compile time (really!).
Numbers please.

The GNU C preprocessor remembers if an include file was completely inside an #ifndef/#endif conditional (modulo whitespace and comments) and will skip the #include for the same file if the macro in #ifndef is already defined. I suspect putting guards around the include will not save any more time.

bfn,
Christopher Turcksin <[email protected]>

IBM Global Services