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 >