On Thursday 12 May 2005 09:29, Sean Dague wrote: > After too much fighting, I just took us back to square 1. In future, we > need to put these changes in 1 at a time, get people testing them on each > platform (and distro), and confirm things are working before moving on. > Throwing lots of code in there which breaks all over the place (or has > hardcoded i486 architecture for ALL ARCHES) really doesn't do any good.
Wow! So you weren't being quite honest when you encouraged me to commit my diffs? I'll resubmit them via the ML and send all proposed changes there from now on. Just to make sure I have this right, though: It's ok when someone who wants their favorite filesystem or tool added to SI does a totally undisciplined job of building from source, linking against objects from both the source tree and the build host distro, ignoring interdependencies between their source and other sources, and in the process breaks the build on all x86 distros other than the latest unstable with every devel package in the world installed and running a 2.6 kernel, just so long as it doesn't make the ppc build hiccup. Sheesh! My bad ;-). Seriously, though... I just reviewed the patches I committed, and I'm pretty sure I didn't touch a thing related to ppc64, except to move /lib64 *after* the libraries we build from source in the mklibs invocation. If that doesn't work, then it means that the source build for the tool in question is not correctly building some part of its binaries or libraries for the architecture, and it probably never was right. You just never saw it because the libraries weren't actually coming from the source build. As for hard-coding i486... I admit that the openssh and openssl build patches I submitted have the letters '86' in them. I'm pretty sure that's the only place they appear. They're there because without them you get pentium instruction set binaries with a 486 kernel. I didn't know we'd EOL'ed support for architectures < i586. Feel free to parametrize the build to eliminate those for your architecture. The only other thing I can think of that might be architecture specific is the --enable-elf-shlibs in e2fsprogs.rul. Again, feel free to parametrize that as well. If zlib doesn't build on ppc64, it probably just needs to be upgraded to a newer source tarball. I chose the tarball which matched debian stable for the first cut. Ditto that for popt. ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Sisuite-devel mailing list Sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
