OpenCores

OpenCores

cvs: ecos-2.0 & gcc-3.2.3

no use

no use

1/1

no use

no use

cvs: ecos-2.0 & gcc-3.2.3 by Unknown on Feb 16, 2004			Not available!
hi! over the weekend all the old compilers, ecos and linux directories were moved to or1k/obsolete directory (just to be on the safe side). i've imported the new compiler. it's basicaly the old OC gcc-3.2.3 with Scott patch. the ATS was also updated and there seam to be no problem with building uclinux. if someone has time it would be nice that 'register aligment' of 64 bit values would be removed. details in: <A HREF="http://www.opencores.org/forums.cgi/openrisc/2004/02/000300">http://www.opencores.org/forums.cgi/openrisc/2004/02/000300</A> also imported was or1k/ecos-2.0. Heiko, Scott, could you please check that your trees are in sync with OC and if there are some changes not in the OC cvs you are very wellcome to check them in. i think we should be pretty much all synced now with unified toolchain. best regards, p. hi! over the weekend all the old compilers, ecos and linux directories were moved to or1k/obsolete directory (just to be on the safe side). i've imported the new compiler. it's basicaly the old OC gcc-3.2.3 with Scott patch. the ATS was also updated and there seam to be no problem with building uclinux. if someone has time it would be nice that 'register aligment' of 64 bit values would be removed. details in: http://www.opencores.org/forums.cgi/openrisc/2004/02/000300 also imported was or1k/ecos-2.0. Heiko, Scott, could you please check that your trees are in sync with OC and if there are some changes not in the OC cvs you are very wellcome to check them in. i think we should be pretty much all synced now with unified toolchain. best regards, p.

cvs: ecos-2.0 & gcc-3.2.3 by Unknown on Feb 16, 2004			Not available!
[q] also imported was or1k/ecos-2.0. Heiko, Scott, could you please check that your trees are in sync with OC and if there are some changes not in the OC cvs you are very wellcome to check them in.[/q] Scott, are you going to sync your trees with the now-current opencores CVS soon? If so, I'd like to wait for that before syncing my own toolchain. BTW, do you want me to post proposed patches before commiting them? Not sure about the etiquette here :) Heiko also imported was or1k/ecos-2.0. Heiko, Scott, could you please check that your trees are in sync with OC and if there are some changes not in the OC cvs you are very wellcome to check them in. Scott, are you going to sync your trees with the now-current opencores CVS soon? If so, I'd like to wait for that before syncing my own toolchain. BTW, do you want me to post proposed patches before commiting them? Not sure about the etiquette here :) Heiko

cvs: ecos-2.0 & gcc-3.2.3 by Unknown on Feb 16, 2004			Not available!
* Heiko Panther (<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>) wrote: [q] [q]>also imported was or1k/ecos-2.0. Heiko, Scott, could you please check that >your trees are in sync with OC and if there are some changes not in the OC >cvs you are very wellcome to check them in.[/q] Scott, are you going to sync your trees with the now-current opencores CVS soon? If so, I'd like to wait for that before syncing my own toolchain. BTW, do you want me to post proposed patches before commiting them? Not sure about the etiquette here :)[/q] well no guidelins so far, but i was thinking about it. let's say that trivial stuff should just go to the cvs but for the 'interesting' patches it would be nice if they get posted beforehand. (but i think we should leave it up to developer to decide). if you do decide to post a patch please use the unified diff format as it's more readable. bottom line i'm always happy to see patches in unified diff, since i can quickly browse through them and get a feel for the change. actually it may be beneficial even to post a patch and commit it at the same time. best regards, p. * Heiko Panther (heiko.panther@web.de) wrote: >also imported was or1k/ecos-2.0. Heiko, Scott, could you please check that >your trees are in sync with OC and if there are some changes not in the OC >cvs you are very wellcome to check them in. Scott, are you going to sync your trees with the now-current opencores CVS soon? If so, I'd like to wait for that before syncing my own toolchain. BTW, do you want me to post proposed patches before commiting them? Not sure about the etiquette here :) well no guidelins so far, but i was thinking about it. let's say that trivial stuff should just go to the cvs but for the 'interesting' patches it would be nice if they get posted beforehand. (but i think we should leave it up to developer to decide). if you do decide to post a patch please use the unified diff format as it's more readable. bottom line i'm always happy to see patches in unified diff, since i can quickly browse through them and get a feel for the change. actually it may be beneficial even to post a patch and commit it at the same time. best regards, p.

cvs: ecos-2.0 & gcc-3.2.3 by Unknown on Feb 23, 2004			Not available!
Hi! [q] i've imported the new compiler. it's basicaly the old OC gcc-3.2.3 with Scott patch. the ATS was also updated and there seam to be no problem with building uclinux.[/q] I'm trying to sync my toolchain with the new compiler in cvs, but I have some problems. I thought Scott's patch addresses the -r gcc bug, right? When I build gcc-3.2.3 the first time (like the ats script) and then compile the userland apps from cvs -r is still needed (otherwise uclinux complains about wrong exec format). After rebuilding gcc then the linker can't find ctr0 anymore when using -r. Without the -r switch the compile goes fine, but I can't run them in uclinux (same error as before). I'm not sure if there is a problem in my setup or if this is a general problem. Has anyone the new compiler running with uclinux? alex Hi! i've imported the new compiler. it's basicaly the old OC gcc-3.2.3 with Scott patch. the ATS was also updated and there seam to be no problem with building uclinux. I'm trying to sync my toolchain with the new compiler in cvs, but I have some problems. I thought Scott's patch addresses the -r gcc bug, right? When I build gcc-3.2.3 the first time (like the ats script) and then compile the userland apps from cvs -r is still needed (otherwise uclinux complains about wrong exec format). After rebuilding gcc then the linker can't find ctr0 anymore when using -r. Without the -r switch the compile goes fine, but I can't run them in uclinux (same error as before). I'm not sure if there is a problem in my setup or if this is a general problem. Has anyone the new compiler running with uclinux? alex

cvs: ecos-2.0 & gcc-3.2.3 by Unknown on Feb 24, 2004			Not available!
[q] I thought Scott's patch addresses the -r gcc bug, right? When I build gcc-3.2.3 the first time (like the ats script) and then compile the userland apps from cvs -r is still needed (otherwise uclinux complains about wrong exec format). After rebuilding gcc then the linker can't find ctr0 anymore when using -r. Without the -r switch the compile goes fine, but I can't run them in uclinux (same error as before). [/q] I haven't built uclinux myself, but I am told that my fixes to the linker did resolve the problems using the -r flag. Try rebuilding binutils instead of or in addition to the compiler. -Scott I thought Scott's patch addresses the -r gcc bug, right? When I build gcc-3.2.3 the first time (like the ats script) and then compile the userland apps from cvs -r is still needed (otherwise uclinux complains about wrong exec format). After rebuilding gcc then the linker can't find ctr0 anymore when using -r. Without the -r switch the compile goes fine, but I can't run them in uclinux (same error as before). I haven't built uclinux myself, but I am told that my fixes to the linker did resolve the problems using the -r flag. Try rebuilding binutils instead of or in addition to the compiler. -Scott

cvs: ecos-2.0 & gcc-3.2.3 by Unknown on Feb 24, 2004			Not available!
* Scott Furman (<A HREF="mailto:sfurman@rosum.com">sfurman@rosum.com</A>) wrote: [q]> > >I thought Scott's patch addresses the -r gcc bug, right? When I build >gcc-3.2.3 the first time (like the ats script) and then compile the >userland >apps from cvs -r is still needed (otherwise uclinux complains about wrong >exec format). After rebuilding gcc then the linker can't find ctr0 anymore >when using -r. Without the -r switch the compile goes fine, but I can't run >them in uclinux (same error as before). > >[/q] I haven't built uclinux myself, but I am told that my fixes to the linker did resolve the problems using the -r flag. Try rebuilding binutils instead of or in addition to the compiler.[/q] yes i noticed the problem with crt0 too. (it seams there is a problem with paths, but it can be resolved by just linking/copying crt0 to one of the places where gcc looks (gcc -print-search-dirs) or by explicitly linking it.) also when i build uclibc and link with it some symbols that are in libc.a aren't found. but extracting them from libc.a (with ar) and linking explicitly solves the problem. regards, p. * Scott Furman (sfurman@rosum.com) wrote: > > >I thought Scott's patch addresses the -r gcc bug, right? When I build >gcc-3.2.3 the first time (like the ats script) and then compile the >userland >apps from cvs -r is still needed (otherwise uclinux complains about wrong >exec format). After rebuilding gcc then the linker can't find ctr0 anymore >when using -r. Without the -r switch the compile goes fine, but I can't run >them in uclinux (same error as before). > > I haven't built uclinux myself, but I am told that my fixes to the linker did resolve the problems using the -r flag. Try rebuilding binutils instead of or in addition to the compiler. yes i noticed the problem with crt0 too. (it seams there is a problem with paths, but it can be resolved by just linking/copying crt0 to one of the places where gcc looks (gcc -print-search-dirs) or by explicitly linking it.) also when i build uclibc and link with it some symbols that are in libc.a aren't found. but extracting them from libc.a (with ar) and linking explicitly solves the problem. regards, p.

cvs: ecos-2.0 & gcc-3.2.3 by Unknown on Feb 25, 2004			Not available!
[q] also when i build uclibc and link with it some symbols that are in libc.a aren't found. but extracting them from libc.a (with ar) and linking explicitly solves the problem. [/q] Usually that's a link order problem. But if you really have a circular dependency, you can link the same library twice. Then you don't need to fiddle around with ar. Heiko also when i build uclibc and link with it some symbols that are in libc.a aren't found. but extracting them from libc.a (with ar) and linking explicitly solves the problem. Usually that's a link order problem. But if you really have a circular dependency, you can link the same library twice. Then you don't need to fiddle around with ar. Heiko

no use

no use

1/1

no use

no use

© copyright 1999-2025 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.