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

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

[Bob Brusa]

Hi
under windows xp with cygwin, I entered the command
cvs -z3 update -d -P
It goes through without error messages, but I end up with an ecos.db-file
that is refused by configtool.

The file starts with a sequence of >>>>>>> and also includes many cr
(ASCII '\0x0a'). The usual header (comment-section at the beginning of the
file) is missing. What went wrong and how can i fix this?
Robert
(sorry - above is a silly error: a cr is 0d, not 0a).

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Sergei Gavrikov]

On Thu, 2 Dec 2010, Bob Brusa wrote:
> 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???

I used `ecosconfig' as well (not configtool), so, places for output
are differ.

FYI: I tried CT-3.0 on Linux and all passed smoothly for my targets.

$ find -type f -name \*strnlen\*
./untitled_build/language/c/libc/string/current/src/language_c_libc_string_strnlen.o
./untitled_build/language/c/libc/string/current/src/strnlen.o.d
./untitled_build/language/c/libc/string/current/tests/strnlen.o
./untitled_build/language/c/libc/string/current/tests/strnlen.d
./untitled_install/tests/language/c/libc/string/current/tests/strnlen


% arm-eabi-nm untitled_install/lib/libtarget.a |
  grep strnlenlanguage_c_libc_string_strnlen.o:
00000000 T __strnlen
00000000 W strnlen

% arm-eabi-nm \
  ./untitled_install/tests/language/c/libc/string/current/tests/strnlen| grep strnlen
8100c85c T __strnlen
8100c85c W strnlen

Can you try *fresh* build for *another* ARM target (not yours) or even
for another architecture, for example, for 'pc' target? I was just
curious...

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

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

[Bob Brusa]

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

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

[Sergei Gavrikov]

On Thu, 2 Dec 2010, Bob Brusa wrote:
> 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.

Of course, I know that. I did mean

  cp ecos.db ecos.db.orig
  tclsh ecosadmin.tcl add my.epk
  cat pkgadd.db >> ecos.db.orig ;# But, I told about Tcl's 'source' cmd.
  cp ecos.db.orig ecos.db
  ...

Forget it, that's for geeks. I'm sorry about that "TIP" :-)

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

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

[Sergei Gavrikov]

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

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Bob Brusa]

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

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

[Sergei Gavrikov]

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?

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Ross Younger]

* Bob Brusa <bob.brusa@gmail.com> wrote:
> 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?

I don't concur. All that happens when you add an EPK is that its
contents are added to your local checkout; they appear to CVS as
locally-made changes.

It sounds in your case that you had a merge conflict from your
locally-added packages.  If you run a "cvs status" at the top level of
your now-broken checkout, I expect that you would see ecos.db listed
with "C", for Conflict, against it. At that point you have to edit the
conflicting file(s), look for the conflict tags ('<<<<<' '=====' and
'>>>>>') and resolve them one way or another - either by hand or with
an automated merge tool. (You appear to be running Windows? I suggest
kdiff3 - see http://kdiff3.sourceforge.net/ , there's a Windows download.)

I suggest you have a play with the mercurial repositories, if you
haven't already - it makes it easy to locally check in the changes
you have made to your repository (including installing EPKs) and still
relatively straightforwardly pull from upstream.


Ross


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Bob Brusa]

Am 01.12.2010, 17:42 Uhr, schrieb Sergei Gavrikov  
<sergei.gavrikov@gmail.com>:

> Bob Brusa wrote:
>
>> Gary Thomas wrote:
>>
>> > Bob Brusa wrote:
>> > > Hi
>> > > under windows xp with cygwin, I entered the command
>> > > cvs -z3 update -d -P
>> > > It goes through without error messages, but I end up with an
>> > > ecos.db-file that is refused by configtool.
>> > >
>> > > The file starts with a sequence of >>>>>>> and also includes many cr
>> > > (ASCII '\0x0a'). The usual header (comment-section at the beginning  
>> of
>> > > the file) is missing. What went wrong and how can i fix this?
>> >
>> > This indicates you had a conflict in merging the changes to that file,
>> > most likely stemming from local changes to the file.
>> >
>> > The easiest thing would be to do something like this:
>> >   % mv ecos.db ecos.db.BAD
>> >   % cvs up ecos.db
>> > Then manually compare them and figure out how to merge your changes
>> > into the master.
>> >
>> I did as you said, but got lots of differences and hence did not trust  
>> the
>> result. I decided to rename my ecos-folder and download a fresh ecos  
>> using the
>> command
>>
>> 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?
>> Robert
>
> Hi Robert,
>
> It was good to know.  If you need exactly ecos-3.0 ecos.db, then you can
> grab the original from Web:
> http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/?cvsroot=ecos
>
> scroll down and set:
>
>  Show only files with tag [ecos-v3_0-release  ] [Go]
>
> and download the wanted ecos.db.
>
> NOTE: ecos.db sources itself if you manage eCos packages (add, remove,
> packages), so, backup original ecos.db, "diff" it with new one and
> adjust addons/rejects using your $EDITOR (in 90% you need to append new
> package/target definitions at the end the original ecos.db).
>
> About build error. Perhaps, that's *v3_0* vs *current* mess. Start build
> in new fresh directory then.
>
> Sergei

Hi Sergei
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.

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.

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?

Thank you for your help and best 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

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

[Sergei Gavrikov]

Bob Brusa wrote:

> Gary Thomas wrote:
> 
> > Bob Brusa wrote:
> > > Hi
> > > under windows xp with cygwin, I entered the command
> > > cvs -z3 update -d -P
> > > It goes through without error messages, but I end up with an
> > > ecos.db-file that is refused by configtool.
> > > 
> > > The file starts with a sequence of >>>>>>> and also includes many cr
> > > (ASCII '\0x0a'). The usual header (comment-section at the beginning of
> > > the file) is missing. What went wrong and how can i fix this?
> > 
> > This indicates you had a conflict in merging the changes to that file,
> > most likely stemming from local changes to the file.
> > 
> > The easiest thing would be to do something like this:
> >   % mv ecos.db ecos.db.BAD
> >   % cvs up ecos.db
> > Then manually compare them and figure out how to merge your changes
> > into the master.
> > 
> I did as you said, but got lots of differences and hence did not trust the
> result. I decided to rename my ecos-folder and download a fresh ecos using the
> command
> 
> 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?
> Robert

Hi Robert,

It was good to know.  If you need exactly ecos-3.0 ecos.db, then you can
grab the original from Web:
http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/?cvsroot=ecos

scroll down and set:

 Show only files with tag [ecos-v3_0-release  ] [Go]

and download the wanted ecos.db.

NOTE: ecos.db sources itself if you manage eCos packages (add, remove,
packages), so, backup original ecos.db, "diff" it with new one and
adjust addons/rejects using your $EDITOR (in 90% you need to append new
package/target definitions at the end the original ecos.db).

About build error. Perhaps, that's *v3_0* vs *current* mess. Start build
in new fresh directory then.

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

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

[Bob Brusa]

Am 01.12.2010, 16:10 Uhr, schrieb Gary Thomas <gary@mlbassoc.com>:

> On 12/01/2010 09:05 AM, Bob Brusa wrote:
>> Hi
>> under windows xp with cygwin, I entered the command
>> cvs -z3 update -d -P
>> It goes through without error messages, but I end up with an
>> ecos.db-file that is refused by configtool.
>>
>> The file starts with a sequence of >>>>>>> and also includes many cr
>> (ASCII '\0x0a'). The usual header (comment-section at the beginning of
>> the file) is missing. What went wrong and how can i fix this?
>
> This indicates you had a conflict in merging the changes to that file,
> most likely stemming from local changes to the file.
>
> The easiest thing would be to do something like this:
>    % mv ecos.db ecos.db.BAD
>    % cvs up ecos.db
> Then manually compare them and figure out how to merge your changes
> into the master.
>
I did as you said, but got lots of differences and hence did not trust the  
result. I decided to rename my ecos-folder and download a fresh ecos using  
the command

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?
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

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

[Gary Thomas]

On 12/01/2010 09:05 AM, Bob Brusa wrote:
> Hi
> under windows xp with cygwin, I entered the command
> cvs -z3 update -d -P
> It goes through without error messages, but I end up with an
> ecos.db-file that is refused by configtool.
>
> The file starts with a sequence of >>>>>>> and also includes many cr
> (ASCII '\0x0a'). The usual header (comment-section at the beginning of
> the file) is missing. What went wrong and how can i fix this?

This indicates you had a conflict in merging the changes to that file,
most likely stemming from local changes to the file.

The easiest thing would be to do something like this:
   % mv ecos.db ecos.db.BAD
   % cvs up ecos.db
Then manually compare them and figure out how to merge your changes
into the master.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Bob Brusa]

Hi
under windows xp with cygwin, I entered the command
cvs -z3 update -d -P
It goes through without error messages, but I end up with an ecos.db-file  
that is refused by configtool.

The file starts with a sequence of >>>>>>> and also includes many cr  
(ASCII '\0x0a'). The usual header (comment-section at the beginning of the  
file) is missing. What went wrong and how can i fix this?
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