[ECOS] [ecos-discuss] invalid ecos.db following cvs-update

Bob Brusa bob.brusa@gmail.com
Thu Dec 2 13:28:00 GMT 2010


Am 02.12.2010, 12:35 Uhr, schrieb Sergei Gavrikov  
<sergei.gavrikov@gmail.com>:

> On Thu, 2 Dec 2010, Bob Brusa wrote:
>
>> 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
>
> Good find!
>
>> 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.
>
> So, I built with cdl_option CYGFUN_LIBC_STRING_GNU_STRNLEN == 1, and
> I haven't got error (that object file in the place):
>
> % find -type f -name \*strnlen\*
> ./language/c/libc/string/current/src/language_c_libc_string_strnlen.o
> ./language/c/libc/string/current/src/strnlen.o.d
> ./language/c/libc/string/current/tests/strnlen.o
> ./language/c/libc/string/current/tests/strnlen.d
> ./install/tests/language/c/libc/string/current/tests/strnlen
>
> This 'strnlen' is weak:
>
> % arm-eabi-nm \
>   install/tests/language/c/libc/string/current/tests/strnlen|grep strnlen
> 8100ca78 T __strnlen
> 8100ca78 W strnlen
>
> The same, but, for CYGFUN_LIBC_STRING_GNU_STRNLEN == 0
>
> % arm-eabi-nm \
>   install/tests/language/c/libc/string/current/tests/strnlen|grep strnlen
> U strnlen
> ^
> | undefined
>
> % find -type f -name \*strnlen\*
> ./language/c/libc/string/current/tests/strnlen.o
> ./language/c/libc/string/current/tests/strnlen.d
> ./install/tests/language/c/libc/string/current/tests/strnlen
>
> So, I think that I would get NOTAPPLICABLE message... Moment,
>
> Yep, it would be (not tested):
>
> tests/strnlen.c:
> void cyg_user_start(void)
> #endif
> {
> #ifndef CYGFUN_LIBC_STRING_GNU_STRNLEN
>     CYG_TEST_NA("strnlen / CYGFUN_LIBC_STRING_GNU_STRNLEN disabled");
> #else
>     ...
>
> So, I get it, thank you, for your report.
>
> Sergei


Its a mystery why it produces an error on my system, but none on yours.  
The only difference I can see so far is that you are working with a linux  
system, whereas I have windows/cygwin. But one question: The above looks  
as if your build produces o- and o.d files in your ecos tree. When  
building the library with configtool on my system, the ecos tree remains  
untouched. So the problem is probably the use of configtool under  
windows/cygwin???

Because I do not understand the exact meaning of the various macros used  
in the source of strnlen.cxx, I feel that I have to live with this open  
issue - unless someone more competent solves it for me.

Clueless 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