Also, please ensure this boots on i386 in the next day. I don't think you fully understand the ramifications of pulling out mklibs, and while it will compile, nothing will actually run in the boel-binaries tarball.
If it boots, I stand corrected, if it doesn't, I think reverting would be a
good thing.
-Sean
On Thu, May 12, 2005 at 09:52:46AM -0400, Sean Dague wrote:
> ppc64 is horribly broken after these changes. zlib won't even build (which
> is the first package).
>
> While this cleans up certain parts of the build on x86, it pretty much
> guarantees a lot of rework to make any other arch work. Unless you are
> signing up for that, I would suggest reverting all the changes, and lets go
> at this one at a time.
>
> -Sean
>
> On Thu, May 12, 2005 at 02:24:08AM -0600, Jerry DeLapp wrote:
> > The numerous commits to cvs HEAD tonight represent the current state of my
> > efforts to get 3.5.x to build on debian stable (3.0r3).
> >
> > I deliberately avoid apt-getting packages unless I'm absolutely convinced
> > that
> > it's the only solution to building si. Sometimes, though, I'll apt-get a
> > package if I don't know w.t.f. I'm doing ;-).
> >
> > With the patches I applied to HEAD tonight, a user can get a kernel and
> > initrd boot image for 2.6.10 on 32-bit debian stable x86 *without* having
> > to
> > do any upgrades to the system (e.g. module-init-utils, *-devel).
> >
> > Here are what I know or think are bugs (that I would welcome help with)
> > related to these changes to HEAD:
> >
> > 1) You have to make more than once because the first pass through the
> > kernel
> > build mistakenly thinks it needs to use 'modprobe.old' to process the
> > module
> > list. I'm sure that something is reading information from the build host
> > instead of our source tree, but, I just haven't had the time to figure out
> > how to convince the si linux kernel build to use a module list and modprobe
> > that aren't part of the build host distro.
> >
> > 2) There are places where source code tarballs get rebuilt (e.g. openssh)
> > when it's not necessary, and there may be cases where source packages fail
> > to
> > get rebuilt when they should. (see my earlier posting in response to
> > dannf's
> > changes to lvm.rul related to 'include make.d/*.rul')
> >
> > 3) I revised the main Makefile in what I consider a fairly lame attempt to
> > deal with (2).
> >
> > 4) The addition of the variable BOEL_MKLIBS_LOCATIONS to the main Makefile
> > for
> > si does not fall under the description above in (3). I'd welcome a better
> > way to do it, but at the very least, anyone who is adding a source build to
> > the si tree should pay attention to the dependencies that other source
> > trees
> > might have and to what mklibs does when building the boel_binaries tarball.
> >
> > In particular, it seems like more and more file systems leverage off of the
> > libuuid implementation in e2fsprogs rather than implementing their own
> > version of uuid. Ditto that for -lz.
> >
> > 5) I tried to find all the inconsistencies between our source builds and
> > what
> > mklibs imports, but I might have missed something.
> >
> > 6) I think this should "build right" on a 64 bit architecture, but I
> > haven't
> > tested it. Sorry Sean! Sorry Dann! I did get rid of the need to
> > import /usr/kerberos/lib ;-).
> >
> > 7) Some of the source versions should be upgraded.
> >
> > 8) Only a masochist would use a p2/400 with only 128mb and debian stable to
> > do
> > test builds. Jeez, that's me!
> >
> > 9) I haven't tested beyond 'make'... In particular, I have no idea what
> > 'make
> > install' will do, or what any of the si_* commands will do. See (8).
> >
> > 10) I haven't updated the spec file (yet).
> >
> > 11) You have to 'touch config.inc' to get make to work at all. I'm looking
> > forward to 'config' becoming the default make rule, provided our configure
> > script is "better" than the ones most of our source tarballs ;-).
> >
> > 12) The lvm and devmapper build should be decoupled. Right now they're
> > both
> > in one rule file, and they're the only sources coupled this way. See (4).
> >
> > 13) there's an sfdisk.rul file that should be burned down, if for no other
> > reason than it triggers multiple builds of util-linux.
> >
> > 14) I only patched things that caused compilation or linkage aborts...
> > there
> > are still a bunch of "interesting" warning messages that might be
> > significant.
> >
> > 15) All of these patches have to do with making the build more internally
> > consistent, with the hope of increasing the number of platforms upon which
> > si
> > will build by decreasing external dependencies. In particular, these
> > patches
> > don't do squat about new 'real' bugs like the busybox vs tar bug posted
> > today. ( I do think these patches should make "upgrade to latest release"
> > a
> > little bit easier, if that's the bug fix).
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
>
> --
> __________________________________________________________________
>
> Sean Dague Mid-Hudson Valley
> sean at dague dot net Linux Users Group
> http://dague.net http://mhvlug.org
>
> There is no silver bullet. Plus, werewolves make better neighbors
> than zombies, and they tend to keep the vampire population down.
> __________________________________________________________________
--
__________________________________________________________________
Sean Dague Mid-Hudson Valley
sean at dague dot net Linux Users Group
http://dague.net http://mhvlug.org
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
pgpKkFHAzGYL7.pgp
Description: PGP signature
