Date: Sat, 25 Jul 1998 01:33:40 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rkw@dataplex.net (Richard Wackerbarth) Cc: tlambert@primenet.com, current@FreeBSD.ORG Subject: Re: Does building current on 2.2.x still work? Message-ID: <199807250133.SAA21242@usr06.primenet.com> In-Reply-To: <l03110701b1de1bafebbc@[208.2.87.5]> from "Richard Wackerbarth" at Jul 24, 98 06:17:08 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Yes, installing .mk files just to bootstrap would cause much the same > >> problems as making the infamous `includes' target just to bootstrap. > > > >I think it should just use the right ones. If necessary, it should > >build the new make to get the -m option for the reinvocation of make. > > > >A "worse than 'includes'" problem is DESTDIR. It means that you can't > >keep a buildable system while attempting to resolve > > > >It does this because there is no seperation of > >"build environment" from "build target". > > Keep preaching, Terry. Perhaps you can eventually gain some converts > and they will allow the reorganization necessary to catch up with the > capabilities that we had 35 years ago. > > Needless to say, I tried and gave up. This was intended as a bug report, not a preach. As David Wolfskill pointed out, building version X on version Y is precisely analogous to cross-building version X for a non-Intel platform on a version X Intel platform. You have to encapsulate everything. The new -m option (and the option 2.2.x added to the linker or whatever to strip symbols) are both very dissatisfying, compared to using the seperate tools and not overloading tool functionality and smearing part of "strip" functionality into other toold to make the .mk files look pretty. This becomes more obvious when you go to build version Y for a non-Intel platform on a version X Intel platform. Unlike the native compilation case, where you can build a subset of the tree needed to build the full tree, chroot down to avoid -m and other "let's embed knowledge of the relative path everywhere" hacks, you *can't* chroott an Intel machine into a non-Intel tree subset and then expect to be able to run the tools. It doesn't work. This is even more annoying when you have to deal with system calls that SIG 12 you because they don't exist and some fool had the bright idea to "enhance" the POSIX specification, instead of doing the proper error return, and setting errno to ENOSYS so that the library can compensate for the gratuitous extension. The default behaviour now requires programs to not only do that, but to ignore SIGSYS (name one program that does this). The library can't easily compensate because it would have to diddle signals around each and every new system call, until some future time when there are nothing but diddled calls littering the library. 8-(. OK, not a preach, but a rant... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807250133.SAA21242>