On Tue, Jan 02, 2007 at 01:49:33PM -0500, Jim Heck wrote: > Riku Voipio wrote: > >The issue here is that flex provides libfl.a, which is arch-specific. > >Therefor some packages fail to build if flex is not installed on target. > >build dependencies of flex are included in doctools devkits, so adding
> I will try this. You are saying that there is nothing specifically > special about the flex that used to be provided in scratchbox, so it is > essentially safer to build it as a crocodile package? The issue is that applications that link against libfl.a will fail if you don't have flex installed on the target. Not all flex using applications use libfl, so depending on the set of packages you want to compile it might be a issue. > >>[sbox-ppc603-croc: ~] > export SBOX_UNAME_MACHINE=ppc > >What does uname -m return on real ppc hardware? scratchbox should match > >what the real hardware returns. > On an actual PowerPC system, 'uname -m' returns 'ppc'. I just confirmed > this on an PPC 8245 target system. So scratchbox needs to use ppc as well. I don't have time atm to track where it is set up, so can you file a bug to http://bugzilla.scratchbox.org/bugzilla/ ? > It seems that the environment variable doesn't help scratchbox formulate > the correct tool name. Instead, the tool name is being found using the > set of soft links in /scratchbox/compilers/bin, which all are formed as > 'powerpc-linux-TOOL' > > Are those links in /scratchbox/compilers/bin dynamically created somehow > (and if so, what do I need to do trigger that creation), or are they > just part of the scratchbox distribution? I could create a whole set of > the needed ones with '-gnu' on my own, but didn't take that step yet. They could probably be created in sb-toolchain-extras, currently I think the list is hardcoded somewhere. IMNHO the whole toolchains wrapping needs a cleanup. > Note that all the other packages didn't have a problem building, since > they inherited the correct tool names from make via the CC environment > variable. The zlib package was different in that the Sarge version of > the package tried to formulate the toolname itself in its makefile based > on the target platform (this seems to have changed in more recent > versions). Suggestions? Not for this specific case, but in general: 1) scratchbox should look and feel like the native enviroinment. It should not be necessary to make scratchbox specific workaround for tha packages build system. Rather, scratchbox should be fixed. 2) If packages build system is *broken*, so that it can be identified without scratchbox that there is bug, the build system should be fixed. Scratchbox is not necessarily bug-to-bug compatible. _______________________________________________ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
