On Thu, 2 Dec 2010, Bob Brusa wrote:
> Am 02.12.2010, 10:42 Uhr, schrieb Sergei Gavrikov <sergei.gavri...@gmail.com>:
>
> > 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?
>
> 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
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
