It would seem that on your box st_atime etc must be macros that expand
to something with a '.' in it, judging from the compiler warnings you
get.
The machine I use for testing etc is pretty old (well the Linux on it
is). I will try with a machine loaded with FC2 and see what happens.
-- Charles
> -----Original Message-----
> From: yaffs-admin@stoneboat.aleph1.co.uk
> [mailto:yaffs-admin@stoneboat.aleph1.co.uk] On Behalf Of
> Michael Erickson
> Sent: Tuesday, 14 December 2004 9:01 a.m.
> To: Frank Rowand
> Cc: manningc2@actrix.gen.nz; yaffs@stoneboat.aleph1.co.uk
> Subject: Re: [Yaffs] Problems compiling YAFFS direct interface.
>
>
> Frank, thanks for the email. It appears that I am having the same
> problem as you.
>
> In file /direct/yaffsfs.h, I re-named the following members
> of structure
> yaffs_stat:
>
> st_atime => st_atim
> st_mtime => st_mtim
> st_ctime => st_ctim
>
> Doing so got rid of the compile error I was having. Of course it
> introduced several others which now have to be fixed :)
>
> So, the question now becomes two parts:
>
> 1) Charles, why is it that you don't get the same errors?
> 2) How should we go about fixing them in a uniform way?
>
> Anyone have any input on how to proceed?
>
> Best regards,
> --mikee
>
>
> Frank Rowand wrote:
> > Charles Manning wrote:
> >
> >> I compile with yaffs direct all the time. This is how I do all the
> >> YAFFS file systel "guts" development, using Linux.
> >> the directtest builds for me fine (with a few warnings) but the
> >> bootloader does not (missing nand_ecc.c). I shall fix
> that by moving
> >> it to yaffs_ecc.c
> >>
> >> The direct test in CVS should build fine. Please fetch
> from CVS again
> >> into a clean directory.
> >>
> >> More below
> >>
> >>
> >> On Saturday 11 December 2004 11:33, Michael Erickson wrote:
> >>
> >>> Hello all,
> >>>
> >>> Just wondering if anyone has actually ever used the direct
> >>> interface. I got the latest version out of CVS yesterday.
> When I try
> >>> and build the code I get the following error:
> >>>
> >>> [snip]
> >>> mikee 03:57 PM $ make all
> >>> ln -s ../devextras.h devextras.h
> >>> ln -s ../yaffs_ecc.c yaffs_ecc.c
> >>> ln -s ../yaffs_ecc.h yaffs_ecc.h
> >>> ln -s ../yaffs_guts.c yaffs_guts.c
> >>> ln -s ../yaffs_guts.h yaffs_guts.h
> >>> ln -s ../yaffsinterface.h yaffsinterface.h
> >>> ln -s ../yportenv.h yportenv.h
> >>> gcc -c -Wall -DCONFIG_YAFFS_DIRECT
> -DCONFIG_YAFFS_SHORT_NAMES_IN_RAM
> >>> -g dtest.c -o dtest.o In file included from dtest.c:9:
> >>> yaffsfs.h:169: warning: no semicolon at end of struct or union
> >>> yaffsfs.h:169: error: syntax error before '.' token
> >>> yaffsfs.h:170: error: syntax error before '.' token
> >>> yaffsfs.h:171: error: syntax error before '.' token
> >
> >
> > I have not tried using the direct interface, but the cause of the
> > above errors is probably the same as I reported on 11/22 (look
> > for an email with the subject "fix for mkyaffsimage compile error").
> >
> > What I wrote there is:
> >
> > When I compile mkyaffsimage on RedHat 9.0, I get errors that look
> > like the errors reported in the email thread "Compile error
> when using
> > yaffs/direct" started by Daniel Gustafsson, Fri, 8 Oct 2004
> 15:28:35.
> >
> > The problem is caused by some #define statements in
> > /usr/include/bits/stat.h:
> >
> > # define st_atime st_atim.tv_sec /* Backward
> compatibility. */
> > # define st_mtime st_mtim.tv_sec
> > # define st_ctime st_ctim.tv_sec
> >
> > The attached patch is one way to fix the problem for
> mkyaffsimage. It
> > renames the st_*time fields to st_tim.
> >
> > If this is an acceptable way to fix the problem, then I can update
> > the patch to include the in-kernel files and the files in the direct
> > directory since they reference these same fields.
> >
> >
> >>
> >>
> >> These messages don't seem to be consistent with the source.
> >>
> >>
> >>> dtest.c: In function `copy_in_a_file':
> >>> dtest.c:18: warning: implicit declaration of function `open'
> >>> dtest.c:21: warning: implicit declaration of function `read'
> >>> dtest.c:32: warning: implicit declaration of function `close'
> >>> dtest.c: In function `dumpDirFollow':
> >>> dtest.c:184: error: storage size of `s' isn't known
> >>> dtest.c:222: warning: int format, off_t arg (arg 3)
> >>> dtest.c:184: warning: unused variable `s'
> >>> dtest.c: In function `dumpDir':
> >>> dtest.c:229: error: storage size of `s' isn't known
> >>> dtest.c:267: warning: int format, off_t arg (arg 3)
> >>> dtest.c:229: warning: unused variable `s'
> >>> dtest.c: In function `long_test':
> >>> dtest.c:306: error: storage size of `ystat' isn't known
> >>> dtest.c:468: warning: int format, off_t arg (arg 2)
> >>> dtest.c:518: warning: implicit declaration of function
> >>> `yaffs_DumpDevStruct' dtest.c:306: warning: unused
> variable `ystat'
> >>> dtest.c: In function `cache_bypass_bug_test':
> >>> dtest.c:621: warning: unused variable `i'
> >>> make: *** [dtest.o] Error 1
> >>> [/snip]
> >>>
> >>> I've searched through the code quite a bit but can't seem
> to come up
> >>> with what is wrong with the structure. It seems as though
> my development
> >>> system's header files are over-riding something.
> >>>
> >>> Is YAFFS direct compile-able on a Linux box?
> >>> Can I _not_ include standard headers?
> >>>
> >>> The documentation on the direct interface says the following:
> >>>
> >>> [snip]
> >>> Compilation Configuration
> >>>
> >>> Configuration is done in four places:
> >>> * yaffscfg.c: OS specific functions
> >>> * yaffscfg.h: Preferably only change YAFFSFS_N_HANDLES, the
> >>> number of files that can be simultaneously opened.
> >>> * yportenv.h: Preferably do not change this.
> >>> * Compile options. The valid compile options for the YAFFS
> >>> direct interface are:
> >>> * CONFIG_YAFFS_DIRECT must be enabled to use the direct
> >>> interface.
> >>> * CONFIG_YAFFS_SHORT_NAMES_IN_RAM define to enable short name
> >>> caching. This is suggested in cases unless RAM is very
> >>> limited.
> >>> [/snip]
> >>>
> >>> I checked yaffscfg.c and it appeared to have reasonably
> stubbed-out
> >>> functions which should allow the system to compile.
> >>>
> >>> Everything else listed there says to not change it. So, I
> guess I'm
> >>> stuck for the moment.
> >>>
> >>> Any input would be greatly appreciated.
> >>>
> >>> Thanks,
> >>> --mike
> >
> >
> > -Frank
>
> --
> Michael Erickson
> Senior Software Engineer
> Logic Product Development
> (612) 436-5118
> mailto:mikee@logicpd.com
> http://www.logicpd.com
>
>
> _______________________________________________
> yaffs mailing list
> yaffs@stoneboat.aleph1.co.uk
> http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
(text/plain)