On Thu, 2 Dec 2010, Bob Brusa wrote: > > > > Bob Brusa wrote: ... > > > cvs -z3 -d :pserver:anon...@ecos.sourceware.org:/cvs/ecos co -P ecos > > > > > > Then, using the administration tool of configtool, i added my > > > platform and template, selected my template (and hardware) from > > > the build menu, created the tree and started the build. It stopped > > > after some time with the following sequence.... > > > > > > <cut> > > > arm-eabi-gcc -c -I/ecos-c/ecos/icb4/icb_app_3_install/include > > > -I/ecoscvs/ecos/packages/language/c/libc/string/current > > > -I/ecoscvs/ecos/packages/language/c/libc/string/current/src > > > -I/ecoscvs/ecos/packages/language/c/libc/string/current/tests -I. > > > -I/ecoscvs/ecos/packages/language/c/libc/string/current/src/ > > > -finline-limit=7000 -Wall -Wpointer-arith -Wundef -Woverloaded-virtual > > > -Wno-write-strings -mno-thumb-interwork -mcpu=arm7tdmi -g -O2 > > > -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions > > > -Wp,-MD,src/strnlen.tmp -o src/language_c_libc_string_strnlen.o > > > /ecoscvs/ecos/packages/language/c/libc/string/current/src/strnlen.cxx > > > /ecoscvs/ecos/packages/language/c/libc/string/current/src/strnlen.cxx:71: > > > error: 'size_t strnlen(const char*, size_t)' aliased to undefined symbol > > > '__strnlen' > > > make[1]: Leaving directory > > > `/ecos-c/ecos/icb4/icb_app_3_build/language/c/libc/string/current' > > > make[1]: *** [src/strnlen.o.d] Error 1 > > > make: *** [build] Error 2 > > > make: Leaving directory `/ecos-c/ecos/icb4/icb_app_3_build' > > > > > > When doing a diff, I find that the new ecos.db and the previous > > > repaired one match - except for a) nonrelevant comments, spaces > > > etc. and of coarse b) the package that I had added. So where is > > > the problem? I am still using the tools that came with ecos-3.0. > > > Is this the problem and I must update this as well? > I think there are some misunderstandings in our email exchange and > hence I probably should explain a little bit more what I did: > > a) I downloaded (using cvs) ecos into an fresh empty folder. Except > for the build-tools used (which are however not in ecos-3.0 but > elsewhere) my "current" ecos has nothing to do with the previous > "ecos-3.0". But never the less, I get the above errors during the > build process.
Robert, I could not reproduce your error above *on Linux host* when I built libc tests from latest CVS sources for my arm7tdmi target using my 1) CFLAGS variant and 2) yours too. I used arm-eabi toolchain from eCos-3.0 box too. Just to comparison, CFLAGS for my arm7tdmi CPU are default_value { CYGBLD_GLOBAL_WARNFLAGS . CYGBLD_ARCH_CFLAGS . "-mcpu=arm7tdmi -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions" } As you can see I even not expanded in-line limit. I'm sorry, but, I have no chance to test your issue using toolchain for cygwin hosts. > b) Going back to ecos-3.0 would not solve my problem, because I > understood, version 3.0 remains untouched and does not include the new > feature (of lwip) I need. > > c) the ecos-3.0 I have is ok - see a) and b). No need to grab it again > from the net. I see. > d) I conclude from your remark about editing ecos.db, that one can no > longer update ecos using cvs, if one has made any changes - e. g. > added a package. Even if one did this using configtool and feeding in > the new stuff packed in an epk-file. Correct? As epk == tar.gz you would extract pkadd.db file from the archive, rename it (e.g. to mypack.inc) and "add it" then at the end *the original ecos.db*, as source [file join $env(ECOS_REPOSITORY) mypack.inc] So, a diff will be 1 line only. That saves original formatting your eCos database file. The formatting changes itself when you use CT GUI or use ecosadmin.tcl script to add/remove eCos packages. > Thank you for your help and best regards - Robert > > PS: With respect to the above build error: I just realize, that > ecos-3.0 does not include a strnlen.cxx file. This probably indicates > some kind of a configuration problem for this file in the newer > "current" version. May be only for some types of systems? I am using > an at91sam7x512-based board (arm). From looking at strnlen.cxx I get > no clue what the problem could be. Please help. Yep, strnlen() and the companion tests were added in 2010, see language/c/libc/string/current/ChangeLog But, as I said I could not reproduce your issue on Linux host. And one more thing: what a template did you use when you try to build the tests from CVS? -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss