Re: [microblaze-uclinux] Problem building some softwares included in Petalinux dist.

[John Williams <john.williams@xxxxxxxxxxxxx>]

Hi Chris, Nicolas,

On Sat, May 16, 2009 at 8:15 PM, Chris Robson <clr1004@xxxxxxxxxxx> wrote:

> 1. Get the application source tree you want but some apps require match
> up to the kernel release, aka 2.6.20. A good example app needing a
> match up is IPRoute2. NOTE, this does require having a system running
> under the 2.6.20 release as well in some real nasty cases, aka IPRoute
> again, having an old laptop around has been a very useful treat for me
> on this.
> 2. Try using the example "makefile" below when building within the
> petalinux cross-compile environment. (note the small "m"akefile)

> 3. But if this fails, then, using your current source system's
> environment (not the Petatlinux cross-compile environment) issue the
> configure command. Yes, this may require some options be disabled.
> Also, pre-compile everything with the desired options prior to moving
> into the petalinux environment.
> 4. Then using your preferred editor or sed edit the generated Makefile
> contents, prefixing all gcc, ar, ranlib and ld with "mb-linux-". You
> also may have to change or add include and library references. For
> example, -I/root/petalinux/userland/include{s) or
> -L/root/petalinux/lib/libraries. Worse yet, put includes into the paths
> specifically specified by the app. (yeah the real ugly part)
> 5. Then add the romfs: etc etc etc stuff at the end of the Makefile.

No no no!  There is almost no reason to do this for modern GNU
automake/autoconf applications!

The right way to do it is to have a pristine source tree in a subdir
under the appdir in the /user heirarchy, a top level wrapper Makefile
that creaets a bulid directory, and calls the configure script in the
src directory.

> Some really ugly challenges are with apps like MySQL which build
> programs which compiles programs to build compiletime apps. Of course
> they crash because they get cross-compiled then the build process tries
> executing them to build the eventual program, nasty.

Agreed - these can be tricky.

> Example makefile:
> CONFOPTS=
>
> all: build/build
> $(MAKE) -C build
>
> build/build: makefile
> rm -rf build
> mkdir build
> (cd build; ac_cv_func_setpgrp_void=yes sh ../configure
> $(CONFIGURE_OPTS) $(CONFOPTS))
> touch build/build
>
> clean:
> rm -rf build
>
> romfs:
> $(ROMFSINST) -e CONFIG_USER_NETPERF_CLIENT build/src/netperf
> /bin/netperf
> $(ROMFSINST) -e CONFIG_USER_NETPERF_SERVER build/src/netserver
> /bin/netserver

Yes - this is the path to the right way.  Running a host-based
./configure then hacking the result is a guaranteed road to pain!

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/