On Fri, Mar 14, 2008 at 08:56:40PM +0530, [email protected] wrote:
> Hi,
>
> I am getting some compile time error:
>
> make[2]: Entering directory `/usr/src/redhat/BUILD/ext3grep-0.0.1/src'
> g++ -Iempty.pch.h -DHAVE_CONFIG_H -I. -I.. -g -O2 -include pch.h \
> -c -o pch.h.gch/68b329da9893e34099c7d8ad5cb9c940 ./pch-source.h
> /usr/include/linux/ext3_fs.h: In function 'unsigned int ext3_rec_len_from_disk (__le16)':
> /usr/include/linux/ext3_fs.h:615: error: 'le16_to_cpu' was not declared in this scope
This seem a bug in linux/ext3_fs.h. I was able to reproduce this on
debian sid, meaning kernel (headers) 2.6.24.
linux/ext3_fs.h defines functions in user space (with __KERNEL__
UNdefined) that use le16_to_cpu et al, but those are not defined
without __KERNEL__ being defined. Moreover, the header that defined
them is no longer available in userspace.
This means that we'd need an ugly work around: you'll have to
define all those macro's yourself before including linux/ext3_fs.h.
The best thing to do is to add a test to configure.ac for this,
and when needed define the macro's in sys.h.
linux/ext3_fs.h is now also using/calling a macro called BUG(), wtf?
Is there a kernel hacker on the list who can tell me what to do?
Is is not allowed to include <linux/ext3_fs.h> (and <linux/jbd.h>)
in a user application? How is one supposed to use these header files?
I can write workarounds without problems, but that might break every
other kernel version if things like this are being done.
I'm also getting:
/usr/include/linux/jbd.h:63: error: 'get_order' was not declared in this scope
/usr/include/linux/jbd.h:63: error: '__get_free_pages' was not declared in this scope
/usr/include/linux/jbd.h:68: error: 'free_pages' was not declared in this scope
--
Carlo Wood <[email protected]>
On Fri, Mar 14, 2008 at 06:00:04PM +0100, Carlo Wood wrote:
> This seem a bug in linux/ext3_fs.h. I was able to reproduce this on
> debian sid, meaning kernel (headers) 2.6.24.
No, the problem is that the tool you're compiling is using kernel
headers which it shouldn't use at all. Please use the headers from
e2fslibs-dev in /usr/include/esxt2fs/ instead. And yes, they provide
ext3 defintions despite the ext2 name.
The only kernel todo here is to remove ext3*.h from the list of exported
headers ASAP.
On Fri, Mar 14, 2008 at 02:14:55PM -0400, Christoph Hellwig wrote:
> On Fri, Mar 14, 2008 at 06:00:04PM +0100, Carlo Wood wrote:
> > This seem a bug in linux/ext3_fs.h. I was able to reproduce this on
> > debian sid, meaning kernel (headers) 2.6.24.
>
> No, the problem is that the tool you're compiling is using kernel
> headers which it shouldn't use at all. Please use the headers from
> e2fslibs-dev in /usr/include/esxt2fs/ instead. And yes, they provide
> ext3 defintions despite the ext2 name.
Furthermore, applications are well advised to use libext2fs instead of
trying to roll their own access routines. Libext2fs has been in
development for over ten years, and as such as all sorts of nice
features, including regression test suites, byte swapping so the code
will work on big-endian systems, portability to non-Linux systems, etc.
Using libext2fs also means that it's much more likely the application
will require less work to support ext4 in the future. If there's
something that ext3grep needs where some existing libext2fs function
provides almost, but not quite, the needed functionality, talk to me;
right now there's quite a bit of development going on with e2fsprogs,
and it's likely I can add the needed support in the next version of
the library.
Regards,
- Ted