This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ecos-discuss] invalid ecos.db following cvs-update


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]