| Summary: | sys-devel/crossdev-0.9.17-r2 does not install msp430 gcc | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Martin Gramatke <xmit> |
| Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | akos, aurelien.francillon, sven.koehler |
| Priority: | High | ||
| Version: | 2006.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 208065 | ||
| Attachments: |
mspgcc-3.2.3.ebuild
files/msp430-binutilsroot-fix.sh |
||
|
Description
Martin Gramatke
2006-12-27 07:58:32 UTC
*** Bug 159215 has been marked as a duplicate of this bug. *** that's because mainline gcc/libc does not support msp430 get those fixed and crossdev will support it out of the box no problem Is there any sort of time frame for when msp430 will become mainline? Who handles making in mainline? no idea ... you'll have to ask the msp430 guys ... as for who those guys are, again i have no idea i'd start at http://mspgcc.sf.net *** Bug 207161 has been marked as a duplicate of this bug. *** Aurelien Francillon's crossdev script builds the msp430 toolchain properly, as also documented on the TinyOS gentoo-wiki page here: http://gentoo-wiki.com/TinyOS#Step_3:_Install_native_compilers his results might be merged into the main crossdev script, so that it works out of the box... it isnt that easy ... crossdev itself does quite literally nothing the important changes are in gcc itself and i'm not about to go searching through random external overlays to fold back in changes for a processor that no one cares enough about to get integrated themselves Created attachment 142125 [details] mspgcc-3.2.3.ebuild This is the ebuild for msp430 in my tinyos overlay, the really ugly part is : bash "${FILESDIR}/msp430-binutilsroot-fix.sh" It creates links in /usr/msp430/bin such that gcc finds it's libs and binutils tools. This breaks with when built with sandbox as it creates the links in root dir... Some parts if it are related to bug 147155 (i.e. ldscripts path not found by the compiler ). Eventually some stolen patches from sys-devel/gcc-3.2.3-r4.ebuild are applied then the mspgccsf.net patch is eventually applied. It's therefore not candidate for inclusion in portage as such but I welcome suggestions for improvement :) Aurelien Created attachment 142128 [details]
files/msp430-binutilsroot-fix.sh
This file is invoked by the ebuild in a desesperate attempt to
make the compiler able to build something ...
Possible ways to do this cleanly are :
- implement the functionality in binutils-config
- do this in mspgcc ebuild itself (with proper ${D} )
- ?
hints appreciated ...
patches used by mspgcc-3.2.3.ebuild which are copied over from regular portage tree to mspgcc/files/3.2.3 : /usr/portage/sys-devel/gcc/files/3.2.1/gcc31-loop-load-final-value.patch /usr/portage/sys-devel/gcc/files/3.2.1/gcc32-strip-dotdot.patch /usr/portage/sys-devel/gcc/files/3.2.1/gcc32-athlon-alignment.patch /usr/portage/sys-devel/gcc/files/3.2.3/gcc32-c++-classfn-member-template.patch /usr/portage/sys-devel/gcc/files/3.2.3/gcc32-mklibgcc-serialize-crtfiles.patch if it goes to portage tree it should also probably need : gcc323-gentoo-branding.patch ? eventually the ebuild applies gcc323-msp430.patch (which i won't attach because it's > 500KB ) it can be found here : https://naurel.org/svn/tinyos-2-overlay/dev-embedded/mspgcc/files/3.2.3/gcc323-msp430.patch note that the mspgcc.fs.net don't provide the patch nor source tarball only windows binary and cvs access ... *** Bug 208065 has been marked as a duplicate of this bug. *** |
