[ECOS] [ecos-discuss] invalid ecos.db following cvs-update
Bob Brusa
bob.brusa@gmail.com
Thu Dec 2 11:27:00 GMT 2010
Am 02.12.2010, 10:42 Uhr, schrieb Sergei Gavrikov
<sergei.gavrikov@gmail.com>:
> On Thu, 2 Dec 2010, Bob Brusa wrote:
>> > > > Bob Brusa wrote:
> ...
>> > > cvs -z3 -d :pserver:anoncvs@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?
Sergei
meanwhile I have found out that when I set the macro
CYGFUN_LIBC_STRING_GNU_STRNLEN to zero, the build works. So the problem is
indeed only the compilation of this file strnlen.cxx. If it is excluded -
no problem any more. Well, I can live with this, because I do not use the
strnlen-function in my programs, but something is not as it should be. I
just wunder: Does your build compile strnlen.cxx? If no, this explains why
you can not reproduce "my" error.
Then - also in response to the remark of Ross on the epk-file. I agreee
with Ross - feeding my epk-file into configtool (menu tools >
Administration then click the button Add and specify the epk-file) does
more than just append a package to ecos.db. My epk-file includes the
hardware-defining package and templates and this package and the templates
are inserted at the correct place in the ecos-structure. And old stuff
with the same name(s) is properly deleted. But I doubt that this has any
connection with "my" error during build. This strnlen-problem probably has
to do with the parameters that enforce strict ansi or handle C or C++
code. The reason for this "working hypothesis" is the observation, that
the failed compilation produces a string.h file which includes the sequence
// This is a GNU extension
#ifndef __STRICT_ANSI__
# ifdef CYGFUN_LIBC_STRING_GNU_STRNLEN
extern size_t
strnlen( const char *, size_t );
# endif
#endif
which is not present in the string.h of the successful build. Furthermore,
with the new library, my program no flags the word externC with a question
mark.
Regards Robert
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list