|
Description
Aurélien Francillon
2006-12-01 08:04:33 UTC
Hi, After discussion with sandro in bug #78908 i open a new tracker bug for tinyos-2.x support here is the rationale : Tinyos-2.x is a big update, most of the code have been rewritten. It comes now in a rpm binary packaged version, no more tar.gz source packages are provided on tinyos website. The versions are tagged in the cvs. I have written a script to fetch and package the source from the cvs. I would be in favor to creating a tinyos-tools-1.2.3.ebuild in order to install all the utilities without splitting it in 15 packages or so ... I don't think a such fine grained packaging makes a lot of sense, it's lot of work and i don't see any obvious benefit ? Moreover it's now cleanly packaged with autotools ... splitting it will be a pain ... while it's just a brunch of small tools ... tinyos-tools are backward compatible with tools from tinyos-1.x For the source code, it might makes sense to keep a form of splitting : tos-2.0.0.ebuild tos-apps-2.0.0.ebuild [1] tos-make-2.0.0.ebuild [1] tos-sdk-c-2.0.0.ebuild tos-sdk-java-2.0.0.ebuild tos-sdk-python-2.0.0.ebuild [1] -> i don't think it makes a lot of sense to split tos/ make/ and apps/ either ... they could come both as tos-2.0.0.ebuild I have written a eselect module in order to switch the environment between tos-1.x to tos-2.x if you are interested you can fetch my working overlay from here : svn checkout https://naurel.org/svn/tinyos-2-overlay/ it works for me but not finished... mainly i will: - split dev-tinyos/tos into 4 packages (does it really makes sense ? ): tos tos-sdk-c tos-sdk-java <- java jar is built, but not in a 'gentooish' way tos-sdk-python - eselect-tinyos needs to handle more stuff in the environment random comments: - tinyos now packages all the classes in a jar file : ${TOSDIR}/support/sdk/java/tinyos.jar various scripts/apps may expect to find it here ... - still a dependency on ibm-jdk but no more dependency on javacomm tinyos provides it's own java comm library for the jvm, maybe a move to emancipate from ibm-java ? - most of the dependencty are missing for now... I will post the individual ebuilds in their own bugs when this will be in a more mature state. But it's a starting point for discussion and testing .... Cheers Aurélien I think taht if you know tinyos and you work on it, apps are quite not usefull, just a waste of space. If the work for splitting them is too high against the benefit, then we can have just an ebuild for for them. There's some work to do for slotting the ebuilds. Maybe an eselect module can be used for switching from tinyos-1.x to tinyos-2.x and vice versa. hi , (In reply to comment #1) > I think taht if you know tinyos and you work on it, apps are quite not usefull, > just a waste of space. this makes sense. However it's still good to have a brunch of apps "known to work" even just as a test for the install ... and still good to have the choice! > If the work for splitting them is too high against the > benefit, then we can have just an ebuild for for them. It's not that much work ... > There's some work to do for slotting the ebuilds. Maybe an eselect module can > be used for switching from tinyos-1.x to tinyos-2.x and vice versa. It's at https://naurel.org/svn/tinyos-2-overlay/dev-tinyos/eselect-tinyos/ but not complete yet, basic functionality only ... what about an "official" tinyos 1.x/2.X overlay in http://overlays.gentoo.org/ ? cheers Aurelien (In reply to comment #2) > It's at https://naurel.org/svn/tinyos-2-overlay/dev-tinyos/eselect-tinyos/ > but not complete yet, basic functionality only ... > > what about an "official" tinyos 1.x/2.X overlay in http://overlays.gentoo.org/ > ? Some of the ebuilds will be hosted on java overlay. It seems that only you and me actually uses tinyos on gentoo and there are no other people working over dev-tinyos tree. A project just for us seems to be not so useful. I hope to finish tinyos-1 this month and tinyos-2 for the end of january. Sorry for my slowness. (In reply to comment #4) > (In reply to comment #2) > > It's at https://naurel.org/svn/tinyos-2-overlay/dev-tinyos/eselect-tinyos/ > > but not complete yet, basic functionality only ... > > > > what about an "official" tinyos 1.x/2.X overlay in http://overlays.gentoo.org/ > > ? > > Some of the ebuilds will be hosted on java overlay. It seems that only you and > me actually uses tinyos on gentoo and there are no other people working over > dev-tinyos tree. A project just for us seems to be not so useful. I hope to > finish tinyos-1 this month and tinyos-2 for the end of january. Sorry for my > slowness. > I tend to think the oposite. If we are really only two to use tinyos on gentoo then we should keep everything in an overlay, instead of keeping thousands of people rsync'ing the ebuilds of dev-tinyos. And with an overlay easily accessible, with everything needed even if those ebuilds are at variable developpement/stability status, there may be many more people using tinyos on gentoo ... (In reply to comment #5) > I tend to think the oposite. If we are really only two to use tinyos on gentoo > then we should keep everything in an overlay, instead of keeping thousands of > people rsync'ing the ebuilds of dev-tinyos. > > And with an overlay easily accessible, with everything needed even if those > ebuilds are at variable developpement/stability status, there may be many more > people using tinyos on gentoo ... Maybe you're right. I'll try to have an overlay set up as soon as I can. I wished to finish tinyos porting on gentoo last month, but as you can see, I haven't done. My free time is every day a bit less than the previous and I'm really near to the limit that would cause me to resign from developer status. If the other gentoo devel accept to keep me in active status I'll try to keep this project active. (In reply to comment #5) > > And with an overlay easily accessible, with everything needed even if those > ebuilds are at variable developpement/stability status, there may be many more > people using tinyos on gentoo ... > At least one person! ;) I have some sensor stuff which I've to programme, however as a Gentoo fan I don't want to install other distros just to have more support for TinyOS (i.e. Ubuntu). It'd be very nice to have tos-2.0 on Portage. (In reply to comment #7) > (In reply to comment #5) > > > > And with an overlay easily accessible, with everything needed even if those > > ebuilds are at variable developpement/stability status, there may be many more > > people using tinyos on gentoo ... > > > > At least one person! ;) I have some sensor stuff which I've to programme, > however as a Gentoo fan I don't want to install other distros just to have more > support for TinyOS (i.e. Ubuntu). It'd be very nice to have tos-2.0 on Portage. hi Oskar, Well, it seems that support of tinyos in gentoo will continue, and tos 2 will eventually go into portage tree. For the time now you can use my overlay, it's still experimental (i.e. mostly works for me;) ) but feedback is very welcome;) Right now the most missing part is the lack of msp toolchain support (for telos like motes). just tried this out - and got a circular dependency:
# emerge -vp tinyos
These are the packages that would be merged, in order:
Calculating dependencies... done!
[nomerge ] dev-tinyos/tinyos-2.0.1 USE="java python"
[nomerge ] dev-tinyos/tos-sdk-python-2.0.1
[ebuild N ] dev-tinyos/tinyos-tools-1.2.3
[ebuild N ] dev-tinyos/nesc-1.2.8a USE="-doc"
[ebuild N ] dev-tinyos/tos-2.0.1 USE="-doc"
!!! Error: circular dependencies:
('ebuild', '/', 'dev-tinyos/tinyos-tools-1.2.3', 'merge') depends on
('ebuild', '/', 'dev-tinyos/tos-2.0.1', 'merge') (hard)
('ebuild', '/', 'dev-tinyos/nesc-1.2.8a', 'merge') (medium)
('ebuild', '/', 'dev-tinyos/tos-2.0.1', 'merge') depends on
('ebuild', '/', 'dev-tinyos/tinyos-tools-1.2.3', 'merge') (hard)
('ebuild', '/', 'dev-tinyos/nesc-1.2.8a', 'merge') depends on
('ebuild', '/', 'dev-tinyos/tos-2.0.1', 'merge') (hard)
!!! Note that circular dependencies can often be avoided by temporarily
!!! disabling USE flags that trigger optional dependencies.
will try to look into it more
Created attachment 120781 [details]
diff against the overlay svn revision 45, to remove the circular dependencies
some more issues: - the tinyos-tools-1.2.3.tar.gz checksum is wrong: the one that the ebuild will download from http://naurel.org/stuff/tinyos-tools-1.2.3.tar.gz has the fulling md5sum: # md5sum tinyos-tools-1.2.3.tar.gz 71f3f40e139df5a5451c293374ca942d tinyos-tools-1.2.3.tar.gz while the one in the distfiles directory in the svn: # md5sum distfiles/tinyos-tools-1.2.3.tar.gz 9c3868b3a4c524cb2fe51f15f875f4b7 distfiles/tinyos-tools-1.2.3.tar.gz and for some reason the ebuild insists in this latter checksum (even ebuild .. digest won't update it) even though seeming circularities have been removed, there's still a circularity between tinyos-tools-1.2.3 and nesc: # emerge -vp nesc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-tinyos/tinyos-tools-1.2.3 0 kB [1] [ebuild N ] dev-tinyos/eselect-tinyos-0.1 0 kB [1] [ebuild N ] dev-tinyos/tos-2.0.1 USE="-doc" 0 kB [1] [ebuild N ] dev-tinyos/nesc-1.2.8a USE="-doc" 0 kB Total: 4 packages (4 new), Size of downloads: 0 kB Portage overlays: [1] /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay # emerge -vp tinyos-tools These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-tinyos/tinyos-tools-1.2.3 0 kB [1] [ebuild N ] dev-tinyos/eselect-tinyos-0.1 0 kB [1] [ebuild N ] dev-tinyos/tos-2.0.1 USE="-doc" 0 kB [1] [ebuild N ] dev-tinyos/nesc-1.2.8a USE="-doc" 0 kB Total: 4 packages (4 new), Size of downloads: 0 kB Portage overlays: [1] /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay and, tinyos-tools-1.2.3 doesn't compile without having nesc installed: # emerge tinyos-tools Calculating dependencies... done! >>> Emerging (1 of 4) dev-tinyos/tinyos-tools-1.2.3 to / * tinyos-tools-1.2.3.tar.gz MD5 ;-) ... [ ok ] * tinyos-tools-1.2.3.tar.gz RMD160 ;-) ... [ ok ] * tinyos-tools-1.2.3.tar.gz SHA1 ;-) ... [ ok ] * tinyos-tools-1.2.3.tar.gz SHA256 ;-) ... [ ok ] * tinyos-tools-1.2.3.tar.gz size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking tinyos-tools-1.2.3.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking tinyos-tools-1.2.3.tar.gz to /var/tmp/portage/dev-tinyos/tinyos-tools-1.2.3/work ... checking for nescc... no configure: error: I can't find nescc the tos-2.0.1. ebuils has a patching issue: * Failed Patch: atm128hardware.h-warning-signal.h.patch ! * ( /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay/dev-tinyos/tos/files/atm128hardware.h-warning-signal.h.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/dev-tinyos/tos-2.0.1/temp/atm128hardware.h-warning-signal.h.patch-13906.out Created attachment 120785 [details, diff]
diff against the overlay svn revision 45, to remove the circular dependencies
see the attached diff against the overlay svn, that actually makes tinyos-2.0.1 emerge: # emerge -vp tinyos These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-tinyos/eselect-tinyos-0.1 0 kB [1] [ebuild N ] dev-tinyos/tos-2.0.1 USE="-doc" 0 kB [1] [ebuild N ] dev-tinyos/nesc-1.2.8a USE="-doc" 0 kB [ebuild N ] dev-tinyos/tinyos-tools-1.2.3 0 kB [1] [ebuild N ] dev-tinyos/tos-sdk-c-2.0.1 USE="-doc" 0 kB [1] [ebuild N ] dev-tinyos/tos-sdk-java-2.0.1 USE="-doc" 0 kB [1] [ebuild N ] dev-tinyos/tos-sdk-python-2.0.1 0 kB [1] [ebuild N ] dev-tinyos/tinyos-2.0.1 USE="java python" 0 kB [1] see the problem with the checksum for tinyos-tools-1.2.3.tar.gz above another problem is that the environment is not set up automatically. eselect-tinyos installs the eselect stuff, but tinyos 2.0.1 is not 'eselected' automatically - and thus emerge will bail out for the first package that needs the tinyos environment variables set (like nesc, etc.) (In reply to comment #15) > see the attached diff against the overlay svn, that actually makes tinyos-2.0.1 thanks for the nice report, i fixed many issues > > see the problem with the checksum for tinyos-tools-1.2.3.tar.gz above well that was actually really 2 different versions ... added a tinyos-tools-1.2.3-r1 ebuild > another problem is that the environment is not set up automatically. > eselect-tinyos installs the eselect stuff, but tinyos 2.0.1 is not 'eselected' > automatically - and thus emerge will bail out for the first package that needs > the tinyos environment variables set (like nesc, etc.) should have fixed this one long time ago ... should behave better now, the user may still needs to source /etc/profile.env ... but at least it's warned ... thanks Aurélien I started to collect the steps to make TinyOS work on a Gennto Box here: http://gentoo-wiki.com/TinyOS all comments & extensions welcome. As you can see there, I'm using a different portage overlay for the msp430 toolchain, as I couldn't set it up with crossdev. Naturally descriptions on how to set it up with crossdev are welcome - maybe that section could have these two as alternatives for the time being... one question: when emergint tinyos-tools, I see the following: + cd platforms/mica/uisp + ./bootstrap -> does this mean that only mica-based stuff is compiled in there? I'm trying to use an msp430-based Mote... (In reply to comment #17) > I started to collect the steps to make TinyOS work on a Gennto Box here: > > http://gentoo-wiki.com/TinyOS > > all comments & extensions welcome. nice ... > > As you can see there, I'm using a different portage overlay for the msp430 > toolchain, as I couldn't set it up with crossdev. Naturally descriptions on how > to set it up with crossdev are welcome - maybe that section could have these > two as alternatives for the time being... well the point is that there is no need for another ebuild for binutils, gentoo already supports all waht's needed ( $ and all...) . The overlay page is in german (so i don't get everything) but it seems that the toolchain installs to /usr/local -> this will never get accepted into mainstream gentoo ... can you try the crossdev in my overlay ? and report exact bugs ? thanks (In reply to comment #18) > one question: > > when emergint tinyos-tools, I see the following: > > + cd platforms/mica/uisp > + ./bootstrap it just needs to run bootstrap for uisp too ... > -> does this mean that only mica-based stuff is compiled in there? I'm trying > to use an msp430-based Mote... no, both are supported usip is used only for atmega based motes msp430 motes (telos etc ) uses bsl (In reply to comment #19) > well the point is that there is no need for another ebuild for binutils, gentoo > already supports all waht's needed ( $ and all...) . I'm not sure if I get it - the msp430-binutils package installs tools like msp430-ld, etc. this is not installed by the 'normal' binutils ebuild (it doesn't compile binutils with the --target=msp430 flag) > The overlay page is in german (so i don't get everything) but it seems that the > toolchain installs to /usr/local -> this will never get accepted into > mainstream gentoo ... you just need to download the overlay tarball, and make it work. I've sent Matthias my latest version, that does everything correctly. Things are installed under /usr as usual. > can you try the crossdev in my overlay ? and report exact bugs ? > thanks I tried, and it didn't work out. this is what I got at the end: /var/tmp/cross/msp430/portage/cross-msp430/mspgcc-3.2.3/work/gcc-3.2.3/gcc/config/msp430/libgcc.S:555: Error: no such instruction: `bis r15,r2' make[2]: *** [libgcc/./_cmpdi2.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [libgcc/./_cmpsf2.o] Error 1 make[2]: *** [libgcc/./__stop_progExec__.o] Error 1 make[2]: Leaving directory `/var/tmp/cross/msp430/portage/cross-msp430/mspgcc-3.2.3/work/build/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/var/tmp/cross/msp430/portage/cross-msp430/mspgcc-3.2.3/work/build/gcc' make: *** [all-gcc] Error 2 !!! ERROR: cross-msp430/mspgcc-3.2.3 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 5436: Called src_compile ebuild.sh, line 1304: Called toolchain_src_compile toolchain.eclass, line 26: Called gcc_src_compile toolchain.eclass, line 1551: Called gcc_do_make toolchain.eclass, line 1425: Called die :( Created attachment 120866 [details]
msp430 ebuilds, that provide msp430-gcc, libc and binutils
(In reply to comment #20) > (In reply to comment #19) > > well the point is that there is no need for another ebuild for binutils, gentoo > > already supports all waht's needed ( $ and all...) . > > I'm not sure if I get it - the msp430-binutils package installs tools like > msp430-ld, etc. this is not installed by the 'normal' binutils ebuild (it > doesn't compile binutils with the --target=msp430 flag) > > > The overlay page is in german (so i don't get everything) but it seems that the > > toolchain installs to /usr/local -> this will never get accepted into > > mainstream gentoo ... > > you just need to download the overlay tarball, and make it work. I've sent > Matthias my latest version, that does everything correctly. Things are > installed under /usr as usual. > > > can you try the crossdev in my overlay ? and report exact bugs ? > > thanks > > I tried, and it didn't work out. this is what I got at the end: > did you run the script distfiles/msp430-binutilsroot-fix.sh ? (In reply to comment #22) > did you run the script distfiles/msp430-binutilsroot-fix.sh ? yes, this is after the second run. what I did was: - ran crossdev -t msp430, and waited until it failed - ran the distfiles/msp430-binutilsroot-fix.sh script - ran crossdev -t msp430 again and I posted what I got at the end... (In reply to comment #23) > (In reply to comment #22) > > did you run the script distfiles/msp430-binutilsroot-fix.sh ? > > yes, this is after the second run. what I did was: > > - ran crossdev -t msp430, and waited until it failed > - ran the distfiles/msp430-binutilsroot-fix.sh script > - ran crossdev -t msp430 again it works fine here ... are you building on x86 or amd64 ? can you post result from gcc-config -l binutils-config -l and your $PATH do you have Matthias Transier compiler/ binutils in your path ? if so can you try with a clean PATH ? > and I posted what I got at the end... can you attach the full build log ? thanks in advance (In reply to comment #24) > it works fine here ... > are you building on x86 or amd64 ? amd64 (x86_64), actually on an Intel Core 2 Duo > can you post result from > gcc-config -l # gcc-config -l [1] x86_64-pc-linux-gnu-3.4.6 [2] x86_64-pc-linux-gnu-3.4.6-hardened [3] x86_64-pc-linux-gnu-3.4.6-hardenednopie [4] x86_64-pc-linux-gnu-3.4.6-hardenednopiessp [5] x86_64-pc-linux-gnu-3.4.6-hardenednossp [6] x86_64-pc-linux-gnu-4.1.1 * > binutils-config -l # binutils-config -l [1] msp430-2.16.1 * [2] x86_64-pc-linux-gnu-2.16.1 * (the first star is of different color here) > and your $PATH # echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/qt/3/bin:/opt/vmware/server/console/bin > do you have Matthias Transier compiler/ binutils in your path ? not when I'm trying out the crossdev stuff - I always unmerge the other packages heforehand > can you attach the full build log ? sure. here's the output of the first run, which ends with the task of running the msp430-binutilsroot-fix.sh script: # crossdev -t msp430 -------------------------------------------------------------------------------- * Host Portage ARCH: amd64 * Target Portage ARCH: amd64 * Target System: msp430 * Stage: 4 (C/C++ compiler) * binutils: binutils-2.16.1-r3 * gcc: mspgcc-3.2.3-r5 * libc: msp430-libc-[latest] * PORTDIR_OVERLAY: /usr/local/portage * PORT_LOGDIR: /var/log/portage * PKGDIR: /usr/portage/packages/cross/msp430 * PORTAGE_TMPDIR: /var/tmp/cross/msp430 _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - * Using dev-embedded/mspgcc from /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay instead of /usr/portage * Using dev-embedded/msp430-libc from /usr/local/portage instead of /usr/portage * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ... [ ok ] * Log: /var/log/portage/cross-msp430-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /var/log/portage/cross-msp430-mspgcc-stage1.log * Emerging cross-mspgcc-stage1 ... * mspgcc failed :( * If you file a bug, please attach the following logfiles: * /var/log/portage/cross-msp430-info.log * /var/log/portage/cross-msp430-mspgcc-stage1.log where /var/log/portage/cross-msp430-mspgcc-stage1.log says: * this ebuild is a bit broken ... * you need to fix some symlinks please use msp430-binutilsroot-fix.sh, and restart emrge so I run it, and then try again: # crossdev -t msp430 -------------------------------------------------------------------------------- * Host Portage ARCH: amd64 * Target Portage ARCH: amd64 * Target System: msp430 * Stage: 4 (C/C++ compiler) * binutils: binutils-2.16.1-r3 * gcc: mspgcc-3.2.3-r5 * libc: msp430-libc-[latest] * PORTDIR_OVERLAY: /usr/local/portage * PORT_LOGDIR: /var/log/portage * PKGDIR: /usr/portage/packages/cross/msp430 * PORTAGE_TMPDIR: /var/tmp/cross/msp430 _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - * Using dev-embedded/mspgcc from /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay instead of /usr/portage * Using dev-embedded/msp430-libc from /usr/local/portage instead of /usr/portage * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ... [ ok ] * Log: /var/log/portage/cross-msp430-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /var/log/portage/cross-msp430-mspgcc-stage1.log * Emerging cross-mspgcc-stage1 ... * mspgcc failed :( * If you file a bug, please attach the following logfiles: * /var/log/portage/cross-msp430-info.log * /var/log/portage/cross-msp430-mspgcc-stage1.log please find the log files attached... Created attachment 121113 [details]
output of running crossdev -t msp430
Created attachment 121115 [details]
output of running crossdev -t msp430
I see that in the previous attempt, it was taking msp430-libc from Matthias' portage tree. removing that the crossdev build still fails:
# crossdev -t msp430
--------------------------------------------------------------------------------
* Host Portage ARCH: amd64
* Target Portage ARCH: amd64
* Target System: msp430
* Stage: 4 (C/C++ compiler)
* binutils: binutils-2.16.1-r3
* gcc: mspgcc-3.2.3-r5
* libc: msp430-libc-[latest]
* PORTDIR_OVERLAY: /usr/local/portage
* PORT_LOGDIR: /var/log/portage
* PKGDIR: /usr/portage/packages/cross/msp430
* PORTAGE_TMPDIR: /var/tmp/cross/msp430
_ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ -
* Using dev-embedded/mspgcc from /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay instead of /usr/portage
* Using dev-embedded/msp430-libc from /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay instead of /usr/portage
* Forcing the latest versions of {binutils,gcc}-config/gnuconfig ... [ ok ]
* Log: /var/log/portage/cross-msp430-binutils.log
* Emerging cross-binutils ... [ ok ]
* Log: /var/log/portage/cross-msp430-mspgcc-stage1.log
* Emerging cross-mspgcc-stage1 ...
* mspgcc failed :(
* If you file a bug, please attach the following logfiles:
* /var/log/portage/cross-msp430-info.log
* /var/log/portage/cross-msp430-mspgcc-stage1.log
please find the log files updated among the attachments...
Created attachment 121117 [details]
output of running crossdev -t msp430
Created attachment 121118 [details]
output of running crossdev -t msp430
thanks for the details, From the error log it seems that gcc tries to compile msp430 assembler with "x86_64-as" and not msp430-as, maybe my fixing script fails because you are using a multilib profile can you check that the link /usr/msp430/bin/as resolves to the actual as for msp430 ? (i have links : /usr/msp430/bin/as -> /usr/bin/msp430-as -> /usr/libexec/gcc/msp430/as -> /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as ) you can find the actual binary location with : qlist cross-msp430/binutils | grep as on my non-multilib host it's : /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as thanks Aurélien (In reply to comment #31) > thanks for the details, > From the error log it seems that gcc tries to compile msp430 assembler with > "x86_64-as" and not msp430-as, maybe my fixing script fails because you are > using a multilib profile oh, am I? :) > can you check that the link > /usr/msp430/bin/as resolves to the actual as for msp430 ? > (i have links : > /usr/msp430/bin/as > -> /usr/bin/msp430-as > -> /usr/libexec/gcc/msp430/as > -> /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as > ) I don't seem to have this file: # ls -l /usr/msp430/bin/as ls: cannot access /usr/msp430/bin/as: No such file or directory > you can find the actual binary location with : > qlist cross-msp430/binutils | grep as > on my non-multilib host it's : > /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as oh, it's there for me as well: # qlist cross-msp430/binutils | grep as /usr/lib/binutils/msp430/2.16.1/include/dis-asm.h /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as /usr/share/binutils-data/msp430/2.16.1/man/man1/msp430-as.1.bz2 /usr/share/binutils-data/msp430/2.16.1/info/as.info strange, that it's not there.. should I emerge msp430-binutils before running crossdev? but I only have this package under Matthias' portage tree... (In reply to comment #32) > (In reply to comment #31) ... > > because you are using a multilib profile > oh, am I? :) no ;) I have been confused by crossdev's logs ... > I don't seem to have this file: > > # ls -l /usr/msp430/bin/as > ls: cannot access /usr/msp430/bin/as: No such file or directory so the problem is really here my script fails somehow ... can you update the overlay and try to merge again mspgcc,it should lauch the script itself the only thing is that you should not have sandbox in your features ... try with FEATURES="-sandbox" emerge -av cross-msp430/mspgcc or just launch the script which is now in dev-embedded/mspgcc/files/msp430-binutilsroot-fix.sh and if you can attach the log or find why the link is not made in /usr/msp430/bin/as ... do you have a link in /usr/bin/msp430-as to this (even with a few hops ... ) /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as > > you can find the actual binary location with : > > qlist cross-msp430/binutils | grep as > > on my non-multilib host it's : > > /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as > > oh, it's there for me as well: > > # qlist cross-msp430/binutils | grep as > /usr/lib/binutils/msp430/2.16.1/include/dis-asm.h > /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as > /usr/share/binutils-data/msp430/2.16.1/man/man1/msp430-as.1.bz2 > /usr/share/binutils-data/msp430/2.16.1/info/as.info > > strange, that it's not there.. no, you have the proper as : /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as it's as expected and latter gcc knows how to use it from there but gcc 3.2.3 don't, and that's the purpose of my little msp430-binutilsroot-fix.sh script... > should I emerge msp430-binutils before running > crossdev? but I only have this package under Matthias' portage tree... no, actually crossdev does some kind of magic, it creates a cross-msp430 category in your overlay, and adds a link cross-msp430/binutils -> sys-devel/binutils, this is the actual ebuild for cross binutils (then is does the same for gcc and others ...) and crossdev merges those ... the eclass recognizes it as a cross build and builds it for the proper target ... that's why creating an ebuild such as dev-embedded/msp430-binutils is pointless; it's actually already there (and the specific stuff is handled in the eclass ...) updated and executed the script. strange enough - it seems to create the symlink, but at the end of the day it's not there: # dev-embedded/mspgcc/files/msp430-binutilsroot-fix.sh cleaning up ls -las //usr/msp430 total 1 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 . 1 drwxr-xr-x 18 root root 520 Jun 4 11:33 .. 0 drwxr-xr-x 2 root root 48 Jun 4 15:49 bin 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 lib ls -las //usr/msp430/bin total 0 0 drwxr-xr-x 2 root root 48 Jun 4 15:49 . 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 .. ls -las //usr/msp430/lib total 0 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 . 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 .. 0 drwxr-xr-x 2 root root 48 Jun 4 15:49 msp1 0 drwxr-xr-x 2 root root 48 Jun 4 15:49 msp2 creating binutlis links ls -las //usr/msp430 total 1 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 . 1 drwxr-xr-x 18 root root 520 Jun 4 11:33 .. 0 drwxr-xr-x 2 root root 368 Jun 4 15:49 bin 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 lib ls -las //usr/msp430/bin total 0 0 drwxr-xr-x 2 root root 368 Jun 4 15:49 . 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 .. 0 lrwxrwxrwx 1 root root 25 Jun 4 15:49 addr2line -> /usr/bin/msp430-addr2line 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 ar -> /usr/bin/msp430-ar 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 as -> /usr/bin/msp430-as 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 c++filt -> /usr/bin/msp430-c++filt 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 ld -> /usr/bin/msp430-ld 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 nm -> /usr/bin/msp430-nm 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 objcopy -> /usr/bin/msp430-objcopy 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 objdump -> /usr/bin/msp430-objdump 0 lrwxrwxrwx 1 root root 22 Jun 4 15:49 ranlib -> /usr/bin/msp430-ranlib 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 readelf -> /usr/bin/msp430-readelf 0 lrwxrwxrwx 1 root root 20 Jun 4 15:49 size -> /usr/bin/msp430-size 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 strings -> /usr/bin/msp430-strings 0 lrwxrwxrwx 1 root root 21 Jun 4 15:49 strip -> /usr/bin/msp430-strip ls -las //usr/msp430/lib total 0 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 . 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 .. 0 drwxr-xr-x 2 root root 48 Jun 4 15:49 msp1 0 drwxr-xr-x 2 root root 48 Jun 4 15:49 msp2 creating msp430 libc links to /usr/msp430/lib for target msp430 binutils version 2.16.1 Done ls -las //usr/msp430 total 1 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 . 1 drwxr-xr-x 18 root root 520 Jun 4 11:33 .. 0 drwxr-xr-x 2 root root 368 Jun 4 15:49 bin 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 lib ls -las //usr/msp430/bin total 0 0 drwxr-xr-x 2 root root 368 Jun 4 15:49 . 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 .. 0 lrwxrwxrwx 1 root root 25 Jun 4 15:49 addr2line -> /usr/bin/msp430-addr2line 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 ar -> /usr/bin/msp430-ar 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 as -> /usr/bin/msp430-as 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 c++filt -> /usr/bin/msp430-c++filt 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 ld -> /usr/bin/msp430-ld 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 nm -> /usr/bin/msp430-nm 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 objcopy -> /usr/bin/msp430-objcopy 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 objdump -> /usr/bin/msp430-objdump 0 lrwxrwxrwx 1 root root 22 Jun 4 15:49 ranlib -> /usr/bin/msp430-ranlib 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 readelf -> /usr/bin/msp430-readelf 0 lrwxrwxrwx 1 root root 20 Jun 4 15:49 size -> /usr/bin/msp430-size 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 strings -> /usr/bin/msp430-strings 0 lrwxrwxrwx 1 root root 21 Jun 4 15:49 strip -> /usr/bin/msp430-strip ls -las //usr/msp430/lib total 0 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 . 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 .. 0 drwxr-xr-x 2 root root 80 Jun 4 15:49 msp1 0 drwxr-xr-x 2 root root 80 Jun 4 15:49 msp2 ls -las //usr/msp430 total 1 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 . 1 drwxr-xr-x 18 root root 520 Jun 4 11:33 .. 0 drwxr-xr-x 2 root root 368 Jun 4 15:49 bin 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 lib ls -las //usr/msp430/bin total 0 0 drwxr-xr-x 2 root root 368 Jun 4 15:49 . 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 .. 0 lrwxrwxrwx 1 root root 25 Jun 4 15:49 addr2line -> /usr/bin/msp430-addr2line 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 ar -> /usr/bin/msp430-ar 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 as -> /usr/bin/msp430-as 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 c++filt -> /usr/bin/msp430-c++filt 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 ld -> /usr/bin/msp430-ld 0 lrwxrwxrwx 1 root root 18 Jun 4 15:49 nm -> /usr/bin/msp430-nm 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 objcopy -> /usr/bin/msp430-objcopy 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 objdump -> /usr/bin/msp430-objdump 0 lrwxrwxrwx 1 root root 22 Jun 4 15:49 ranlib -> /usr/bin/msp430-ranlib 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 readelf -> /usr/bin/msp430-readelf 0 lrwxrwxrwx 1 root root 20 Jun 4 15:49 size -> /usr/bin/msp430-size 0 lrwxrwxrwx 1 root root 23 Jun 4 15:49 strings -> /usr/bin/msp430-strings 0 lrwxrwxrwx 1 root root 21 Jun 4 15:49 strip -> /usr/bin/msp430-strip ls -las //usr/msp430/lib total 0 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 . 0 drwxr-xr-x 4 root root 96 Jun 4 15:44 .. 0 drwxr-xr-x 2 root root 80 Jun 4 15:49 msp1 0 drwxr-xr-x 2 root root 80 Jun 4 15:49 msp2 ldscripts links created : 0 lrwxrwxrwx 1 root root 42 Jun 4 15:49 //usr/msp430/lib/msp2/ldscripts -> //usr/lib/binutils/msp430/2.16.1/ldscripts 0 lrwxrwxrwx 1 root root 42 Jun 4 15:49 //usr/msp430/lib/msp1/ldscripts -> //usr/lib/binutils/msp430/2.16.1/ldscripts # ls -l /usr/msp430/bin/aslrwxrwxrwx 1 root root 18 Jun 4 15:49 /usr/msp430/bin/as -> /usr/bin/msp430-as # ls -l /usr/bin/msp430-as ls: cannot access /usr/bin/msp430-as: No such file or directory
> # ls -l /usr/bin/msp430-as
> ls: cannot access /usr/bin/msp430-as: No such file or directory
this one should be setup by binutils-config ...
can you force binutils config to make links again with :
binutils-config msp430-2.16.1
and look if the link /usr/bin/msp430-as is there ?
(In reply to comment #35) > > # ls -l /usr/bin/msp430-as > > ls: cannot access /usr/bin/msp430-as: No such file or directory > this one should be setup by binutils-config ... > can you force binutils config to make links again with : > binutils-config msp430-2.16.1 > and look if the link /usr/bin/msp430-as is there ? > this in itself doesn't seem to work: # binutils-config msp430-2.16.1 * Switching to msp430-2.16.1 ... /usr/bin/binutils-config: line 118: cd: ///usr/lib/binutils/msp430/2.16.1: No such file or directory but, executing crossdev -t msp430 will create whatever's needed: $ ls -l /usr/bin/msp430-as lrwxrwxrwx 1 root root 26 2007-06-04 21:17 /usr/bin/msp430-as -> /usr/libexec/gcc/msp430/as $ ls -l /usr/libexec/gcc/msp430/as lrwxrwxrwx 1 root root 54 2007-06-04 21:17 /usr/libexec/gcc/msp430/as -> /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as $ ls -l /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as-rwxr-xr-x 1 root root 218320 2007-06-01 14:01 /usr/x86_64-pc-linux-gnu/msp430/binutils-bin/2.16.1/as but, unfortunately it still fails: # FEATURES="-sandbox" crossdev -t msp430 -------------------------------------------------------------------------------- * Host Portage ARCH: amd64 * Target Portage ARCH: amd64 * Target System: msp430 * Stage: 4 (C/C++ compiler) * binutils: binutils-2.16.1-r3 * gcc: mspgcc-3.2.3-r5 * libc: msp430-libc-[latest] * PORTDIR_OVERLAY: /usr/local/portage * PORT_LOGDIR: /var/log/portage * PKGDIR: /usr/portage/packages/cross/msp430 * PORTAGE_TMPDIR: /var/tmp/cross/msp430 _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - * Using dev-embedded/mspgcc from /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay instead of /usr/portage * Using dev-embedded/msp430-libc from /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay instead of /usr/portage * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ... [ ok ] * Log: /var/log/portage/cross-msp430-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /var/log/portage/cross-msp430-mspgcc-stage1.log * Emerging cross-mspgcc-stage1 ... * mspgcc failed :( * If you file a bug, please attach the following logfiles: * /var/log/portage/cross-msp430-info.log * /var/log/portage/cross-msp430-mspgcc-stage1.log (without the FEATURES="-sandbox" env variable, it complained about this varaible) see the log files attached, but the main error is: Assembler messages: Selected target format 'elf32-msp430' unknown: Invalid bfd target which is what I get if I simply invoke msp430-as: # msp430-as Assembler messages: Selected target format 'elf32-msp430' unknown: Invalid bfd target Created attachment 121187 [details]
/var/log/portage/cross-msp430-info.log
Created attachment 121188 [details]
/var/log/portage/cross-msp430-mspgcc-stage1.log
ok, so crossdev -t msp430 seems to work now... some stuff still to do: - make tos-sdk-c compile the C-based programs, versus just installing the source files - solve the TOSComm issue somehow I seem to have solved the serial communication bug, by using a javacomm-based implementation, found in tinyos 1.x, this file in fact: tinyos-1.x/tools/java/net/tinyos/packet/SerialByteSource.java I wonder if we should update the tos-sdk-java ebuild so that it would use this implementation instead, and make the package depend on the IBM JDK with the javacomm USE flag - which will make sure that it indeed works fine. what do you think? (In reply to comment #39) ... > - make tos-sdk-c compile the C-based programs, versus just installing the > source files they are actually build but not really installed, you can find them together with the sources ... i fixed it now... > - solve the TOSComm issue somehow > I seem to have solved the serial communication bug, by using a javacomm-based > implementation, found in tinyos 1.x, this file in fact: > tinyos-1.x/tools/java/net/tinyos/packet/SerialByteSource.java > > I wonder if we should update the tos-sdk-java ebuild so that it would use this > implementation instead, and make the package depend on the IBM JDK with the > javacomm USE flag - which will make sure that it indeed works fine. > > what do you think? i think it's perfect for a useflag ... give me a patch and i will update the ebuilds ... (In reply to comment #41) > they are actually build but not really installed, you can find them together > with the sources ... > i fixed it now... I tried emerge tos-sdk-c, but it fails with a checksum error: >>> Downloading 'http://www.naurel.org/stuff/tinyos-2.0.1_p20070606.tar.gz' --08:40:21-- http://www.naurel.org/stuff/tinyos-2.0.1_p20070606.tar.gz => `/usr/portage/distfiles/tinyos-2.0.1_p20070606.tar.gz' Resolving www.naurel.org... 82.233.121.138 Connecting to www.naurel.org|82.233.121.138|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 9,043,616 (8.6M) [application/x-gzip] 100%[====================================>] 9,043,616 96.93K/s ETA 00:00 08:41:53 (95.61 KB/s) - `/usr/portage/distfiles/tinyos-2.0.1_p20070606.tar.gz' saved [9043616/9043616] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ !! ] !!! Digest verification failed: !!! /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay/dev-tinyos/tos-sdk-c/ChangeLog !!! Reason: Filesize does not match recorded size !!! Got: 460 !!! Expected: 297 I see that you have updated the tarball to compile libtoscomm.so & co with the -m32 flag - please undo this change, as it will force 32-bit compilation on 64 bit systems as well - and installing 32 bit JNI shared objects unto 64 JDKs breaks them... Created attachment 121389 [details, diff]
honour the javacomm flag, and use JavaComm if specified
this patch adds the javacomm USE flag to dev-tinyos/tinyos-tools and to dev-tinyos/tos-jdk-java, and uses JavaComm instead of TOSComm when this use flag is specified.
see the file to put into dev-tinyos/tos-jdk-java/files in a separate attachment
Created attachment 121391 [details]
the JavaComm implementation, put into dev-tinyos/tos-jdk-java/files
the file to put into dev-tinyos/tos-jdk-java/files for the javacomm patch to work
(In reply to comment #42) > !!! Digest verification failed: > !!! > /home/maroy/src/tyrell/src/corpora/tmote/src/tinyos-2-overlay/dev-tinyos/tos-sdk-c/ChangeLog > !!! Reason: Filesize does not match recorded size > !!! Got: 460 > !!! Expected: 297 fixed sorry ... (In reply to comment #43) > I see that you have updated the tarball to compile libtoscomm.so & co with the > -m32 flag - that's a side effect i updated it to have deluge ... i have just seen this change ... > please undo this change, as it will force 32-bit compilation on 64 > bit systems as well - and installing 32 bit JNI shared objects unto 64 JDKs > breaks them... I will fix it, but in the mean time, you can just avoid keywording version "p20070606", you can link from your keywords dir to the (just created) file various/packages.keywords-stable, that will prevent to install the cvs snapshots (assuming you are not in a full ~amd64 setup ) cheers, Aurélien (In reply to comment #44) > Created an attachment (id=121389) [edit] > honour the javacomm flag, and use JavaComm if specified > > this patch adds the javacomm USE flag to dev-tinyos/tinyos-tools ... thanks applied but libgetenv still needs to be installed it has nothing to do with libtoscomm ... (In reply to comment #45) > Created an attachment (id=121391) [edit] > the JavaComm implementation, put into dev-tinyos/tos-jdk-java/files > the file to put into dev-tinyos/tos-jdk-java/files for the javacomm patch to applied thanks ... btw can you mark obsolete your old patches and logs (if you consider them solved ), i don't have rights thanks Aurélien (In reply to comment #47) > btw can you mark obsolete your old patches and logs (if you consider them > solved ), i don't have rights sure, did so... sanchan has been retired. I can not merge tos, tinyos-tools and tinyos. I get the same error for all the available ebuilds:
* ERROR: dev-tinyos/tos-2.1.0 failed.
* Call stack:
* ebuild.sh, line 1879: Called _source_ebuild
* ebuild.sh, line 1818: Called source '/usr/local/tinyos-2-overlay/dev-tinyos/tos/tos-2.1.0.ebuild'
* tos-2.1.0.ebuild, line 4: Called inherit 'eutils' 'python'
* ebuild.sh, line 1218: Called die
* The specific snippet of code:
* [ ! -e "$location" ] && die "${1}.eclass could not be found by inherit()"
* The die message:
* eutils.eclass could not be found by inherit()
*
* If you need support, post the topmost build error, and the call stack if relevant.
*
*
... done!
!!! All ebuilds that could satisfy "dev-tinyos/tos" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-tinyos/tos-2.1.0 (masked by: corruption)
- dev-tinyos/tos-2.0.2 (masked by: corruption)
- dev-tinyos/tos-2.0.1_p20070611 (masked by: corruption)
- dev-tinyos/tos-2.0.1_p20070607 (masked by: corruption)
- dev-tinyos/tos-2.0.1_p20070606 (masked by: corruption)
- dev-tinyos/tos-2.0.1 (masked by: corruption)
- dev-tinyos/tos-2.0.0-r3 (masked by: corruption)
- dev-tinyos/tos-2.0.0_beta2 (masked by: corruption)
- dev-tinyos/tos-1.1.15-r1 (masked by: corruption)
Hi, I'm sorry the overlay is currently unmaintained, it would need a few fixed to be usable on recent gentoo ... But if you propose patches i would be glad to integrate them! Aurélien (In reply to comment #51) > Hi, > I'm sorry the overlay is currently unmaintained, it would need a few fixed to > be usable on recent gentoo ... > But if you propose patches i would be glad to integrate them! > Aurélien > Okay, at least i will try it. I don't wanna work all time in virtual machine. The ebuild-files are empty (except for some variables). At first i would need access to the source code and a short build introduction. (In reply to comment #51) > Hi, > I'm sorry the overlay is currently unmaintained, it would need a few fixed to > be usable on recent gentoo ... > But if you propose patches i would be glad to integrate them! > Aurélien > Obviously i made it. All i did was deleting the eclass-dir from portage and adding the SRC_URI for tinyos. Now i got Blink working ;-) I used the tinyos-2.1.0.ebuild. tinyos was removed from tree. closing. |
