|
John Please understand, I agree with you 1,000%. The methods I suggest here are ugly and "not" meant to be the end solution at all. But I believe others, like myslef, have project deliver schedules to meet which far out weight solving original app/lib build methods, as nicely said as I can, whose original methods are not community standard methods to build things. The end should be the makefile method but to get there , some apps and libs present real hard challenges. Specially when trying to keep from having to outright rewrite the building process of the apps/libs in question thus forcing real logistics issues. The worst thing is to find you can not keep apps/lib up-to-date, nasty security bit fall...... Anyway, I'm working to find a process to meet approved methods and reduces logistical support as my time permits. In the meantime, this horrible work around lets schedules be meet as well. Did I say horrible ugly enough? By-the-by, I've talk to some here at work, who also recount having to follow this same tactic to get things done when trying to meet deliverables as we say, so I dont feel to bad. But it is to horribly ugly to maintain for long! Right now things have been in the what does and does not work and why. I'll try moving a little faster into the autoconf area this weekend. ...>Chris John Williams wrote: > Hi Chris, Nicolas, > > On Sat, May 16, 2009 at 8:15 PM, Chris Robson > > >> 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 > Insert movie times and more without leaving Hotmail®. See how. |