* [ECOS] [ecos-discuss] invalid ecos.db following cvs-update @ 2010-12-01 16:05 Bob Brusa 2010-12-01 16:10 ` Gary Thomas 0 siblings, 1 reply; 14+ messages in thread From: Bob Brusa @ 2010-12-01 16:05 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-01 16:05 [ECOS] [ecos-discuss] invalid ecos.db following cvs-update Bob Brusa @ 2010-12-01 16:10 ` Gary Thomas 2010-12-01 17:06 ` Bob Brusa 0 siblings, 1 reply; 14+ messages in thread From: Gary Thomas @ 2010-12-01 16:10 UTC (permalink / raw) To: bob.brusa; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-01 16:10 ` Gary Thomas @ 2010-12-01 17:06 ` Bob Brusa 2010-12-01 17:42 ` Sergei Gavrikov 0 siblings, 1 reply; 14+ messages in thread From: Bob Brusa @ 2010-12-01 17:06 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-01 17:06 ` Bob Brusa @ 2010-12-01 17:42 ` Sergei Gavrikov 2010-12-02 8:51 ` Bob Brusa 0 siblings, 1 reply; 14+ messages in thread From: Sergei Gavrikov @ 2010-12-01 17:42 UTC (permalink / raw) To: Bob Brusa; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-01 17:42 ` Sergei Gavrikov @ 2010-12-02 8:51 ` Bob Brusa 2010-12-02 9:36 ` [ECOS] Fwd: " Bob Brusa 2010-12-02 10:40 ` Ross Younger 0 siblings, 2 replies; 14+ messages in thread From: Bob Brusa @ 2010-12-02 8:51 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [ECOS] Fwd: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-02 8:51 ` Bob Brusa @ 2010-12-02 9:36 ` Bob Brusa 2010-12-02 10:42 ` Sergei Gavrikov 2010-12-02 10:40 ` Ross Younger 1 sibling, 1 reply; 14+ messages in thread From: Bob Brusa @ 2010-12-02 9:36 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: ecos-discuss ------- Weitergeleitete Nachricht ------- Von: "Bob Brusa" <bob.brusa@gmail.com> An: "Sergei Gavrikov" <sergei.gavrikov@gmail.com> Kopie: ecos-discuss <ecos-discuss@ecos.sourceware.org> Betreff: Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update Datum: Thu, 02 Dec 2010 08:51:53 -0000 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 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. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-02 9:36 ` [ECOS] Fwd: " Bob Brusa @ 2010-12-02 10:42 ` Sergei Gavrikov 2010-12-02 11:27 ` Bob Brusa 0 siblings, 1 reply; 14+ messages in thread From: Sergei Gavrikov @ 2010-12-02 10:42 UTC (permalink / raw) To: Bob Brusa; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-02 10:42 ` Sergei Gavrikov @ 2010-12-02 11:27 ` Bob Brusa 2010-12-02 12:36 ` Sergei Gavrikov 2010-12-02 12:39 ` Sergei Gavrikov 0 siblings, 2 replies; 14+ messages in thread From: Bob Brusa @ 2010-12-02 11:27 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-02 11:27 ` Bob Brusa @ 2010-12-02 12:36 ` Sergei Gavrikov 2010-12-02 13:28 ` Bob Brusa 2010-12-02 12:39 ` Sergei Gavrikov 1 sibling, 1 reply; 14+ messages in thread From: Sergei Gavrikov @ 2010-12-02 12:36 UTC (permalink / raw) To: Bob Brusa; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-02 12:36 ` Sergei Gavrikov @ 2010-12-02 13:28 ` Bob Brusa 2010-12-02 14:28 ` Sergei Gavrikov 0 siblings, 1 reply; 14+ messages in thread From: Bob Brusa @ 2010-12-02 13:28 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-02 13:28 ` Bob Brusa @ 2010-12-02 14:28 ` Sergei Gavrikov 0 siblings, 0 replies; 14+ messages in thread From: Sergei Gavrikov @ 2010-12-02 14:28 UTC (permalink / raw) To: Bob Brusa; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-02 11:27 ` Bob Brusa 2010-12-02 12:36 ` Sergei Gavrikov @ 2010-12-02 12:39 ` Sergei Gavrikov 1 sibling, 0 replies; 14+ messages in thread From: Sergei Gavrikov @ 2010-12-02 12:39 UTC (permalink / raw) To: Bob Brusa; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update 2010-12-02 8:51 ` Bob Brusa 2010-12-02 9:36 ` [ECOS] Fwd: " Bob Brusa @ 2010-12-02 10:40 ` Ross Younger 1 sibling, 0 replies; 14+ messages in thread From: Ross Younger @ 2010-12-02 10:40 UTC (permalink / raw) To: ecos-discuss * 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [ECOS] [ecos-discuss] invalid ecos.db following cvs-update @ 2010-12-01 16:09 Bob Brusa 0 siblings, 0 replies; 14+ messages in thread From: Bob Brusa @ 2010-12-01 16:09 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-12-02 14:28 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-12-01 16:05 [ECOS] [ecos-discuss] invalid ecos.db following cvs-update Bob Brusa 2010-12-01 16:10 ` Gary Thomas 2010-12-01 17:06 ` Bob Brusa 2010-12-01 17:42 ` Sergei Gavrikov 2010-12-02 8:51 ` Bob Brusa 2010-12-02 9:36 ` [ECOS] Fwd: " Bob Brusa 2010-12-02 10:42 ` Sergei Gavrikov 2010-12-02 11:27 ` Bob Brusa 2010-12-02 12:36 ` Sergei Gavrikov 2010-12-02 13:28 ` Bob Brusa 2010-12-02 14:28 ` Sergei Gavrikov 2010-12-02 12:39 ` Sergei Gavrikov 2010-12-02 10:40 ` Ross Younger 2010-12-01 16:09 Bob Brusa
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).