Hi Paul, >>> No clear differentiation between programs that run in the host >>> environment >>> and programs that need to be compiled in the target environment. >>> Good exercise would be to build LEAF on a non x86 linux box and find all >>> of this crap (for example, linux/scripts/mkdep (a binary) is compiled >>> against uclibc by the target compiler, but run on the host). >>> >>> (Of course, I've mentioned this before... but it really needs to get >>> fixed >>> as our host and target environments diverge) >> >> Good luck on that one. I'd really like to see that too, but the last >> time I tried, I failed miserably. There are _many_ configure scripts out >> there that simply cannot cope with a true cross-compile - many assume >> that the build host will also be the target host. >> If you specify the appropriate options (--build and --host, if I recall >> correctly), they fail. So, even if we fix all the "crap" that's compiled >> against uclibc but runs on the build-host, it wouldn't really help much, >> unless somebody takes the time and cleans up those troublesome configure >> scripts too, and then takes the changes upstream, so the changes to the >> configure scripts wouldn't have to be re-applied with the next version. > True, but the only way to solve this is to start, one package at a time. Very true. The only problem I've found with that approach in the past is that the poor soul who starts with that is the one who ends up doing the rest as well (if he finds the time despite being flooded with support email). I'm afraid sometimes the open source model just doesn't work. It works perfectly fine when something is bugging somebody who can do the work himself, but it doesn't seem to work at all when somebody does the work becauuse he feels he should, despite not really having a need (been there, done that). Just to be clear about that - I neither have the time for doing that kind of work right now, nor do I really have a need for it (I don't need to run LEAF on platforms other than x86 right now). There doesn't seem to be a a need for paid work either - see the "Security and LEAF Bering UClibc" thread on LEAF-user for proof - so I fail to see how such an effort could work for somebody who has to work for a living, or even for somebody who works for a company that would cough up the needed bucks if there were at least _some_ return in such an investment (there apparently is nobody who needs the results of such an effort enough to do it himself, and there's also nobody willing to pay for that kind of work - granted, that discussion was about a different topic, but if people aren't willing to pay for security updates, they're most likely not going to pay for anything else either).
> Some better documentation on the build environment would help (no, I'm > not volunteering at the moment), I'm not asking for that - but something more specific would surely help (having access to the source was enough to get me started a few years ago, so I'm most likely beyond the stage where I'd automatically know the parts of documentation that need some work). In short - if you can point us to the exact parts that need documening, we'll be happy to update the docs. > perhaps what we need is a "hello world" > package that works in a completely cross-compiled environment as a > start? That could surely be done - but I'm not terribly sure that would help an awful lot. Porting "hello world" apps has never been a problem, so I'm not sure what that's supposed to prove. It's the "totally screwed up" sources that use up all the time - the sources that are complicated enough to be beyond a simple fix (like bind - if you feel brave, try creating a cross-compile setup for that...) > Sorry, I can't volunteer for this this year, my head is > exploding with other work (in fact, apologies for the delay in replying). Don't worry about the delay - again, been there, done that (I have plenty of "real" [read, work that people actually pay for] work that needs to be done right now too) - so by all means, I don't blame you, or anybody else for not having enough spare time. Heck, that's exactly why I can't invest more time in LEAF myself. Spare time is valuable to all of us - which may be why nobody ported LEAF to non-x86 platforms yet... (especially so if it doesn't serve a business need, with somebody else paying for the time spent...) Martin ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ leaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-devel
