Bug #339

inode.h:88: error: syntax error before "cdev_t"

Added by wa1ter over 6 years ago. Updated over 6 years ago.

Status:Closed Start date:
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:-
Target version:-

Description

This is while compiling pkgsrc libgtop2 on -current:

In file included from procmem.c:44:
/usr/include/ufs/ufs/inode.h:88: error: syntax error before "cdev_t"

Here is a snippet of inod.h up to line 88:
struct inode {
struct inode *i_next;/* Hash chain */
struct vnode *i_vnode;/* Vnode associated with this inode. */
struct vnode *i_devvp;/* Vnode for block I/O. */
uint32_t i_flag; /* flags, see below */
cdev_t i_dev; /* Device associated with the inode. */

I can't spot any syntax error there, so maybe the error message is
misleading? Any guesses?

Related todos

History

#1
Updated by wa1ter over 6 years ago

On Tue, 3 Oct 2006, walt wrote:

Here is my guess:

# grep -r ufs1_ino_t /usr/include/*
/usr/include/fs/ufs/dinode.h:typedef __uint32_t ufs1_ino_t;
/usr/include/fs/ffs/dinode.h:typedef __uint32_t ufs1_ino_t;
/usr/include/ufs/ufs/dinode.h:typedef __uint32_t ufs1_ino_t;
/usr/include/ufs/ffs/dinode.h:typedef __uint32_t ufs1_ino_t;
/usr/include/vfs/ufs/dinode.h:typedef __uint32_t ufs1_ino_t;
/usr/include/vfs/ffs/dinode.h:typedef __uint32_t ufs1_ino_t;

AFAICT, ufs1_ino_t is never defined anywhere with a typedef. Would
this be flagged at compile time as a 'syntax error'?

#2
Updated by corecode over 6 years ago

this usually means that "cdev_t" isn't known. However inode.h is being included, they also need to include the file which defines cdev_t.

yes, it would be flagged, but it is defined, about 6 times: typedef works the opposite way than #define:

typedef orig_type new_type;

#define NEW_MACRO old_stuff

cheers
simon

#3
Updated by dillon over 6 years ago

The bug is simply that _KERNEL_STRUCTURES or _KERNEL is not being
defined early enough, causing some #include files to not do the
proper typedefs that later include files need.

If you stick #define _KERNEL_STRUCTURES at the top of procmem.c,
it works.

Of course, there are other problems... MAP_ENTRY_IS_SUB_MAP does not
exist any more, for example, causing additional compilation errors
in procmem.c and procmap.c.

-Matt

#4
Updated by corecode over 6 years ago

can we close this?

Also available in: Atom PDF