From: Nik M. <gu...@ni...> - 2005-01-19 05:35:23
|
has anyone successfully done this? Is there a howto on gettting an app shoehorned into the gumstix-buildroot toolchain? cross compiling is new to me, and while there are generic HowTo's for crosscompiling stuff for arm, the gumstix-buildroot looks to be unique. I've given up on getting the mono platform runniing on a gumstix, but Python is my next choide for a RAD on the gumstix. I need more than shell scripts, but certainly less than c++ for my particular apps. Regards, nik martin |
From: Diez B. R. <de...@we...> - 2005-01-19 15:15:16
|
Am Wednesday, 19. January 2005 00:35 schrieb Nik Martin: > has anyone successfully done this? Is there a howto on gettting an app > shoehorned into the gumstix-buildroot toolchain? cross compiling is new > to me, and while there are generic HowTo's for crosscompiling stuff for > arm, the gumstix-buildroot looks to be unique. > > I've given up on getting the mono platform runniing on a gumstix, but > Python is my next choide for a RAD on the gumstix. I need more than > shell scripts, but certainly less than c++ for my particular apps. I did succed. I had to recompile the uclib with large file support and some static error variable available and specified the endianess of the platform using CONFIG_SITE. I used a prefix for installation that lateron I linked from the mmc. I don't have a actual howto, but it certainly is doable and is great fun to have python running on the gtx. Regards, Diez B. Roggisch |
From: Craig H. <cr...@hu...> - 2005-01-19 17:43:09
|
On Jan 19, 2005, at 7:16 AM, Diez B. Roggisch wrote: > Am Wednesday, 19. January 2005 00:35 schrieb Nik Martin: >> has anyone successfully done this? Is there a howto on gettting an app >> shoehorned into the gumstix-buildroot toolchain? cross compiling is >> new >> to me, and while there are generic HowTo's for crosscompiling stuff >> for >> arm, the gumstix-buildroot looks to be unique. >> >> I've given up on getting the mono platform runniing on a gumstix, but >> Python is my next choide for a RAD on the gumstix. I need more than >> shell scripts, but certainly less than c++ for my particular apps. > > I did succed. I had to recompile the uclib with large file support and > some > static error variable available and specified the endianess of the > platform > using CONFIG_SITE. I used a prefix for installation that lateron I > linked > from the mmc. > > I don't have a actual howto, but it certainly is doable and is great > fun to > have python running on the gtx. Interesting. Now that I know it's possible, I'll have another go at wedging it into the buildroot. It's certainly something that a number of people have asked about. C |
From: Diez B. R. <de...@we...> - 2005-01-20 09:57:00
|
> Interesting. Now that I know it's possible, I'll have another go at > wedging it into the buildroot. It's certainly something that a number > of people have asked about. If it fits because of its size - I doubt that. Thats a reason why I'd like to have some sort of mounted mmc for / - or at least important parts of the fs like /usr. So far I didn't try, but does mmc support include support for several partitions? That would make it easy to have one partition for temporary or otherwise non-system files, and one as root fs. Didz |
From: Craig H. <cr...@hu...> - 2005-01-20 16:15:25
|
On Jan 20, 2005, at 1:57 AM, Diez B. Roggisch wrote: >> Interesting. Now that I know it's possible, I'll have another go at >> wedging it into the buildroot. It's certainly something that a number >> of people have asked about. > > If it fits because of its size - I doubt that. Thats a reason why I'd > like to > have some sort of mounted mmc for / - or at least important parts of > the fs > like /usr. So far I didn't try, but does mmc support include support > for > several partitions? That would make it easy to have one partition for > temporary or otherwise non-system files, and one as root fs. Yes, you should be able to have multiple partitions on an MMC/SD card, using whatever filesystem you like. I don't know how Windows would treat a multi-partition MMC/SD card if you were to stick it in a windows box, but linux should deal just fine. Note that you don't need to use something like JFFS2 on an MMC/SD card, because the card will tend to do its own wear-levelling internally, I believe. C |
From: Darren G. <ts...@ya...> - 2005-01-20 20:26:40
|
I'm trying to do this.. I repartitioned the mmc card so that the first partition is vfat and the second is ext2. Linux laptop sees and mounts both fine. uboot sees the fat partition fine. I recompiled the gumstix kernel with ext2. How do I mount the second partition of the mmc on the gumstix? What under /dev corresponds to the second partition of the mmc card? On Jan 20, 2005, at 8:15 AM, Craig Hughes wrote: > Yes, you should be able to have multiple partitions on an MMC/SD card, > using whatever filesystem you like. I don't know how Windows would > treat a multi-partition MMC/SD card if you were to stick it in a > windows box, but linux should deal just fine. Note that you don't > need to use something like JFFS2 on an MMC/SD card, because the card > will tend to do its own wear-levelling internally, I believe. > > C > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-01-20 20:41:01
|
You'll need to create a new device node under /dev/mmc/mmc0/ called part2 using: mknod /dev/mmc/mmc0/part2 b 254 2 Then add that to your /etc/fstab and you should be all set. C On Jan 20, 2005, at 12:25 PM, Darren Gibbs wrote: > I'm trying to do this.. I repartitioned the mmc card so that the first > partition is vfat and the second is ext2. Linux laptop sees and > mounts both fine. uboot sees the fat partition fine. I recompiled > the gumstix kernel with ext2. How do I mount the second partition of > the mmc on the gumstix? What under /dev corresponds to the second > partition of the mmc card? > > On Jan 20, 2005, at 8:15 AM, Craig Hughes wrote: >> Yes, you should be able to have multiple partitions on an MMC/SD >> card, using whatever filesystem you like. I don't know how Windows >> would treat a multi-partition MMC/SD card if you were to stick it in >> a windows box, but linux should deal just fine. Note that you don't >> need to use something like JFFS2 on an MMC/SD card, because the card >> will tend to do its own wear-levelling internally, I believe. |
From: Todd V. <tod...@sr...> - 2005-01-20 23:06:15
Attachments:
python-cross-compile.patch
python.mk
|
I've had python running on my gumstix for awhile now. What makes building python difficult is that the python interpreter is used in the build process itself. The trick is to actually build two interpreters. One for the host machine and which is used during the build. The other is the actual interpreter that runs on the target platform. The other place you need to watch out for is during the install stage. The standard makefile uses the target python interpreter to byte-compile the library modules and any that do not compile are thrown out. When cross-compiling, especially to a different architecture, the target interpreter obviously cannot run and the result is no library modules. Here's the best resource on the details of cross-compiling python: http://www.ailis.de/~k/docs/crosscompiling/python.php I've used it to cross-compile python on a number of different systems, primarily all running uClibc/busybox. I'm attaching the patch and a buildroot makefile that I use for my gumstix build. You'll probably want to modify the the python.mk file to suit your system. In the install stage, I remove a number of modules that I do not need to help conservce space. The resulting size is ~16M. That is obviously too large to burn into the onboard flash, so what I do is install it into /opt/python, tar up that directory and copy it over to the MMC card. I have a fairly large and complicated python-based data acuistion system running on the stix and things have been working quite well so far! Todd |
From: Craig H. <cr...@hu...> - 2005-01-20 23:19:42
|
Todd, any problems with me committing this to the gumstix buildroot in subversion? Thanks, C On Jan 20, 2005, at 2:44 PM, Todd Valentic wrote: > I've had python running on my gumstix for awhile now. What makes > building python difficult is that the python interpreter is used in > the build process itself. The trick is to actually build two > interpreters. One for the host machine and which is used during the > build. The other is the actual interpreter that runs on the target > platform. > > The other place you need to watch out for is during the install stage. > The standard makefile uses the target python interpreter to > byte-compile the library modules and any that do not compile are > thrown out. When cross-compiling, especially to a different > architecture, the target interpreter obviously cannot run and the > result is no library modules. > > Here's the best resource on the details of cross-compiling python: > > http://www.ailis.de/~k/docs/crosscompiling/python.php > > > I've used it to cross-compile python on a number of different systems, > primarily all running uClibc/busybox. I'm attaching the patch and a > buildroot makefile that I use for my gumstix build. > > You'll probably want to modify the the python.mk file to suit your > system. In the install stage, I remove a number of modules that I do > not need to help conservce space. The resulting size is ~16M. That is > obviously too large to burn into the onboard flash, so what I do is > install it into /opt/python, tar up that directory and copy it over to > the MMC card. > > I have a fairly large and complicated python-based data acuistion > system running on the stix and things have been working quite well so > far! > > Todd > > --- Python-2.3.4/Makefile.pre.in.orig 2003-11-18 14:54:00.000000000 > -0500 > +++ Python-2.3.4/Makefile.pre.in 2004-07-29 21:44:47.075924464 -0400 > @@ -159,6 +159,7 @@ > > PYTHON= python$(EXE) > BUILDPYTHON= python$(BUILDEXE) > +HOSTPYTHON= ./$(BUILDPYTHON) > > # === Definitions added by makesetup === > > @@ -186,6 +187,8 @@ > # Parser > PGEN= Parser/pgen$(EXE) > > +HOSTPGEN= $(PGEN) > + > POBJS= \ > Parser/acceler.o \ > Parser/grammar1.o \ > @@ -314,8 +317,8 @@ > # Build the shared modules > sharedmods: $(BUILDPYTHON) > case $$MAKEFLAGS in \ > - *-s*) $(RUNSHARED) CC='$(CC)' LDSHARED='$(BLDSHARED)' OPT='$(OPT)' > ./$(BUILDPYTHON) -E $(srcdir)/setup.py -q build;; \ > - *) $(RUNSHARED) CC='$(CC)' LDSHARED='$(BLDSHARED)' OPT='$(OPT)' > ./$(BUILDPYTHON) -E $(srcdir)/setup.py build;; \ > + *-s*) $(RUNSHARED) CC='$(CC)' LDSHARED='$(BLDSHARED)' OPT='$(OPT)' > $(HOSTPYTHON) -E $(srcdir)/setup.py -q build;; \ > + *) $(RUNSHARED) CC='$(CC)' LDSHARED='$(BLDSHARED)' OPT='$(OPT)' > $(HOSTPYTHON) -E $(srcdir)/setup.py build;; \ > esac > > # buildno should really depend on something like LIBRARY_SRC > @@ -432,7 +435,7 @@ > > > $(GRAMMAR_H) $(GRAMMAR_C): $(PGEN) $(GRAMMAR_INPUT) > - -$(PGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C) > + -$(HOSTPGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C) > > $(PGEN): $(PGENOBJS) > $(CC) $(OPT) $(LDFLAGS) $(PGENOBJS) $(LIBS) -o $(PGEN) > @@ -705,19 +708,19 @@ > done > $(INSTALL_DATA) $(srcdir)/LICENSE $(DESTDIR)$(LIBDEST)/LICENSE.txt > PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ > - ./$(BUILDPYTHON) -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \ > + $(HOSTPYTHON) -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \ > -d $(LIBDEST) -f \ > -x 'badsyntax|site-packages' $(DESTDIR)$(LIBDEST) > PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ > - ./$(BUILDPYTHON) -Wi -tt -O $(DESTDIR)$(LIBDEST)/compileall.py \ > + $(HOSTPYTHON) -Wi -tt -O $(DESTDIR)$(LIBDEST)/compileall.py \ > -d $(LIBDEST) -f \ > -x 'badsyntax|site-packages' $(DESTDIR)$(LIBDEST) > PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ > - ./$(BUILDPYTHON) -Wi -t $(DESTDIR)$(LIBDEST)/compileall.py \ > + $(HOSTPYTHON) -Wi -t $(DESTDIR)$(LIBDEST)/compileall.py \ > -d $(LIBDEST)/site-packages -f \ > -x badsyntax $(DESTDIR)$(LIBDEST)/site-packages > PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ > - ./$(BUILDPYTHON) -Wi -t -O $(DESTDIR)$(LIBDEST)/compileall.py \ > + $(HOSTPYTHON) -Wi -t -O $(DESTDIR)$(LIBDEST)/compileall.py \ > -d $(LIBDEST)/site-packages -f \ > -x badsyntax $(DESTDIR)$(LIBDEST)/site-packages > > @@ -812,7 +815,8 @@ > # Install the dynamically loadable modules > # This goes into $(exec_prefix) > sharedinstall: > - $(RUNSHARED) ./$(BUILDPYTHON) -E $(srcdir)/setup.py install \ > + CC='$(CC)' LDSHARED='$(BLDSHARED)' OPT='$(OPT)' > CROSS_COMPILE='$(CROSS_COMPILE)' \ > + $(HOSTPYTHON) -E $(srcdir)/setup.py install \ > --prefix=$(prefix) \ > --install-scripts=$(BINDIR) \ > --install-platlib=$(DESTSHARED) \ > --- Python-2.3.4/setup.py.orig 2004-07-29 21:32:12.993562408 -0400 > +++ Python-2.3.4/setup.py 2004-07-29 21:47:12.174866072 -0400 > @@ -213,6 +213,7 @@ > try: > imp.load_dynamic(ext.name, ext_filename) > except ImportError, why: > + if os.environ.get('CROSS_COMPILE') != "yes": > self.announce('*** WARNING: renaming "%s" since importing > it' > ' failed: %s' % (ext.name, why), level=3) > assert not self.inplace > @@ -233,6 +234,9 @@ > os.remove(filename) > except AttributeError: > self.announce('unable to remove files (ignored)') > + else: > + self.announce('WARNING: "%s" failed importing, but we > leave it because we are cross-compiling' % > + ext.name) > except: > exc_type, why, tb = sys.exc_info() > self.announce('*** WARNING: importing extension "%s" ' > ############################################################# > # > # python > # > ############################################################# > PYTHON_VERSION=2.3.4 > PYTHON_SOURCE:=Python-$(PYTHON_VERSION).tgz > PYTHON_SITE:=http://python.org/ftp/python/$(PYTHON_VERSION) > PYTHON_DIR:=$(BUILD_DIR)/Python-$(PYTHON_VERSION) > PYTHON_CAT:=zcat > PYTHON_BINARY:=python > PYTHON_TARGET_DIR:=/opt/python > PYTHON_TARGET_LIB:=$(PYTHON_TARGET_DIR)/lib/python2.3 > PYTHON_TARGET_BINARY:=$(PYTHON_TARGET_DIR)/bin/python > > > $(DL_DIR)/$(PYTHON_SOURCE): > $(WGET) -P $(DL_DIR) $(PYTHON_SITE)/$(PYTHON_SOURCE) > > python-source: $(DL_DIR)/$(PYTHON_SOURCE) > > $(PYTHON_DIR)/.unpacked: $(DL_DIR)/$(PYTHON_SOURCE) > $(PYTHON_CAT) $(DL_DIR)/$(PYTHON_SOURCE) | tar -C $(BUILD_DIR) -xf - > touch $(PYTHON_DIR)/.unpacked > > $(PYTHON_DIR)/.patched: $(PYTHON_DIR)/.unpacked > $(SOURCE_DIR)/patch-kernel.sh $(PYTHON_DIR) $(SOURCE_DIR) > python-*.patch > touch $(PYTHON_DIR)/.patched > > $(PYTHON_DIR)/.hostpython: $(PYTHON_DIR)/.patched > (cd $(PYTHON_DIR); rm -rf config.cache; \ > OPT="-O1" \ > ./configure \ > --with-cxx=no \ > $(DISABLE_NLS); \ > $(MAKE) $(JLEVEL) python Parser/pgen; \ > mv python hostpython; \ > mv Parser/pgen Parser/hostpgen; \ > $(MAKE) $(JLEVEL) distclean \ > ); > touch $(PYTHON_DIR)/.hostpython > > $(PYTHON_DIR)/.configured: $(PYTHON_DIR)/.hostpython > (cd $(PYTHON_DIR); rm -rf config.cache; \ > $(TARGET_CONFIGURE_OPTS) \ > OPT="$(TARGET_OPTIMIZATION)" \ > ./configure \ > --target=$(GNU_TARGET_NAME) \ > --host=$(GNU_TARGET_NAME) \ > --build=$(GNU_HOST_NAME) \ > --with-cxx=no \ > --prefix=$(PYTHON_TARGET_DIR) \ > --sysconfdir=/etc \ > $(DISABLE_NLS) \ > ); > touch $(PYTHON_DIR)/.configured > > $(PYTHON_DIR)/$(PYTHON_BINARY): $(PYTHON_DIR)/.configured > $(MAKE) $(JLEVEL) CC=$(TARGET_CC) -C $(PYTHON_DIR) \ > HOSTPYTHON=./hostpython HOSTPGEN=./Parser/hostpgen > > $(TARGET_DIR)/$(PYTHON_TARGET_BINARY): $(PYTHON_DIR)/$(PYTHON_BINARY) > LD_LIBRARY_PATH=$(STAGING_DIR)/lib > $(MAKE) $(JLEVEL) CC=$(TARGET_CC) -C $(PYTHON_DIR) install \ > DESTDIR=$(TARGET_DIR) CROSS_COMPILE=yes \ > HOSTPYTHON=./hostpython HOSTPGEN=./Parser/hostpgen > rm $(TARGET_DIR)/$(PYTHON_TARGET_DIR)/bin/idle > rm $(TARGET_DIR)/$(PYTHON_TARGET_DIR)/bin/pydoc > rm -rf $(TARGET_DIR)/$(PYTHON_TARGET_DIR)/share/locale \ > $(TARGET_DIR)/$(PYTHON_TARGET_DIR)/info \ > $(TARGET_DIR)/$(PYTHON_TARGET_DIR)/man \ > $(TARGET_DIR)/$(PYTHON_TARGET_DIR)/share/doc > rm -rf \ > $(TARGET_DIR)/$(PYTHON_TARGET_LIB)/*.py? \ > $(TARGET_DIR)/$(PYTHON_TARGET_LIB)/distutils/*.py? \ > $(TARGET_DIR)/$(PYTHON_TARGET_LIB)/curses/*.py? \ > $(TARGET_DIR)/$(PYTHON_TARGET_LIB)/test \ > $(TARGET_DIR)/$(PYTHON_TARGET_LIB)/config \ > $(TARGET_DIR)/$(PYTHON_TARGET_LIB)/lib-tk \ > $(TARGET_DIR)/$(PYTHON_TARGET_LIB)/lib-old \ > $(TARGET_DIR)/$(PYTHON_TARGET_LIB)/idlelib > > python: uclibc $(TARGET_DIR)/$(PYTHON_TARGET_BINARY) > > python-clean: > -$(MAKE) $(JLEVEL) -C $(PYTHON_DIR) distclean > rm $(PYTHON_DIR)/.configured > > python-dirclean: > rm -rf $(PYTHON_DIR) |
From: Todd V. <tod...@sr...> - 2005-01-20 23:41:54
|
Craig Hughes wrote: > any problems with me committing this to the gumstix buildroot in > subversion? > Not at all! Todd |
From: Craig H. <cr...@hu...> - 2005-01-20 23:49:43
|
On Jan 20, 2005, at 3:22 PM, Todd Valentic wrote: > Craig Hughes wrote: >> any problems with me committing this to the gumstix buildroot in >> subversion? > > Not at all! Ok, well it compiled fine for me (adds about 5MB to a root_fs_arm) so I just committed it on the trunk. I left the rm's in for the bits you're removing; happy to entertain suggestions from people about what a good default set of libs might be for the buildroot. C |
From: Todd V. <tod...@sr...> - 2005-01-21 10:54:17
|
> Ok, well it compiled fine for me (adds about 5MB to a root_fs_arm) so I > just committed it on the trunk. I left the rm's in for the bits you're > removing; happy to entertain suggestions from people about what a good > default set of libs might be for the buildroot. Craig, Thanks for adding it in - nice to have on less thing to worry about. Here's a couple of more notes: 1 - The build is for Python version 2.3.4. It should be fairly easy to make work with 2.4 for those that are interested. 2 - If you do not have the readline library installed, the command line editing and history recall in the interactive interpreter won't work as you minight expect them to. Todd |
From: Nik M. <gu...@ni...> - 2005-01-22 03:47:57
|
Craig Hughes wrote: > On Jan 20, 2005, at 3:22 PM, Todd Valentic wrote: > >> Craig Hughes wrote: >> >>> any problems with me committing this to the gumstix buildroot in >>> subversion? >> >> >> Not at all! > > > Ok, well it compiled fine for me (adds about 5MB to a root_fs_arm) so I > just committed it on the trunk. I left the rm's in for the bits you're > removing; happy to entertain suggestions from people about what a good > default set of libs might be for the buildroot. > > C > > That's awesome! I'm ebaying a leica camera just to buy a few of these, now that I know it'll run python. |
From: Craig H. <cr...@hu...> - 2005-01-19 16:33:15
|
I've tried python a couple times, and searched extensively on the web for pointers. Python unfortunately doesn't like cross-compiling itself. It like to build small apps that it then runs, feeding the output into the continuing build process. Perl does this too, but the perl build system has included a system where for the "excute this" step, it first scp's the binary to the target platform to run it there, runs it under ssh, and then continues the host compile. This just about works for Perl, but Python doesn't come close to supporting this. The only effective way to compile Python for gumstix would be to do what I did to get PHP compiled for the 'stix, which is to do a canadian cross of gcc, so that gcc will run natively on the 'stix, then mount a regular non-cross compiling gcc development environment on the gumstix using NFS or from a large MMC card (NFS probably faster) and build Python natively on the gumstix. You'll obviously need to also install all the dependencies the Python build process has on the 'stix or in the mounted filesystem. This was by far easier to do with etherstix for me, since I just booted over the network and mounted my rootfs over NFS, including all the stuff I wanted. I turned on a bunch of TARGETS in the buildroot top-level makefile, then just NFS exported build_arm/root as my NFS mountpoint. C On Jan 18, 2005, at 3:35 PM, Nik Martin wrote: > has anyone successfully done this? Is there a howto on gettting an app > shoehorned into the gumstix-buildroot toolchain? cross compiling is > new to me, and while there are generic HowTo's for crosscompiling > stuff for arm, the gumstix-buildroot looks to be unique. > > I've given up on getting the mono platform runniing on a gumstix, but > Python is my next choide for a RAD on the gumstix. I need more than > shell scripts, but certainly less than c++ for my particular apps. > > Regards, > > nik martin > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Tim A. <gu...@ut...> - 2005-01-19 17:11:46
|
On 18 Jan 2005, at 23:35, Nik Martin wrote: > has anyone successfully done this? Is there a howto on gettting an app > shoehorned into the gumstix-buildroot toolchain? cross compiling is > new to me, and while there are generic HowTo's for crosscompiling > stuff for arm, the gumstix-buildroot looks to be unique. > > I've given up on getting the mono platform runniing on a gumstix, but > Python is my next choide for a RAD on the gumstix. I need more than > shell scripts, but certainly less than c++ for my particular apps. Sorry, replying to myself twice here, but you may not have found the buildroot documentation on the uclibc site. Here it is: http://www.uclibc.org/cgi-bin/cvsweb/buildroot/docs/buildroot- documentation.html The stuff about making your own makefiles is at the bottom of the page. The documentation seems to be for a slightly different version than the gumstix one, but the docs should give you an idea of how it all works. Tim |
From: Tim A. <ti...@ut...> - 2005-01-19 16:45:27
|
On 18 Jan 2005, at 23:35, Nik Martin wrote: > has anyone successfully done this? Is there a howto on gettting an app > shoehorned into the gumstix-buildroot toolchain? cross compiling is > new to me, and while there are generic HowTo's for crosscompiling > stuff for arm, the gumstix-buildroot looks to be unique. > > I've given up on getting the mono platform runniing on a gumstix, but > Python is my next choide for a RAD on the gumstix. I need more than > shell scripts, but certainly less than c++ for my particular apps. Isn't there a makefile for Python in gumstix-buildroot/make? I've got one, so simply adding "TARGETS+=python" near the other "TARGETS" lines in gumstix-buildroot/Makefile should build python for you. There may be some dependancies for python which you have to add to Makefile yourself. It's the xxx.mk file in make/ which is the key. There are a few which aren't in the gumstix buildroot here: http://www.uclibc.org/cgi-bin/cvsweb/buildroot/make/Attic/ I compiled nano for my gumstix using the .mk file from there (with one small tweak - the download path was broken). Just copied the .mk file in, added the target and did the same for the ncurses library it required. The .mk scripts aren't that different to a normal Makefile, you should be able to reverse engineer one and create your own once you work through the plethora of variables. Tim |