Re: More world breakage
only. In -stable, and in -current before the end of December the following tools: ls, rm, chflags, find, xinstall and mtree used a common set of routines to manipulate file flags. [snip] tool. At the beginnig of January, because of the proliferation of utilities using these functions, I moved them to libutil in -current. [snip] modes (setmode/getmode). This was what I did last week, renaming flags_to_string to getflags, and string_to_flags to setflags. I [also moved to libc -- snip] It may be argued that we should back out _both_ commits and resurrect bin/ls/stat_flags.c. Would this gain us anything? Yes and no. The commits had a reason. Backing them out completely would only result in a second series of equivalent commits. It seems that install(1) is the only problem child. We can revert install(1) to have it's own set of functions and leave the rest as is. After installworld has been completed, install(1) can be changed back to use the libc versions. Comments? marcel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
Whichever system they run on. This can be the host machine even for
cross-compiling, if the target root is remote mounted. The main problem
with this in -current is that some install rules put ${DESTDIR} in the
installed files. perl is the main offender.
Which install rules? I'd like to fix this. (I know libraries are a
big mess).
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On Sun, 30 Jan 2000, Mark Murray wrote:
Whichever system they run on. This can be the host machine even for
cross-compiling, if the target root is remote mounted. The main problem
with this in -current is that some install rules put ${DESTDIR} in the
installed files. perl is the main offender.
Which install rules? I'd like to fix this. (I know libraries are a
big mess).
Ones in perl's internal makefiles. I hardly know what they are, but
their are 1384 lines of messages in my buildworld output despite my
use of `make -s' to turn off verbose output. Headers are converted
and packing lists are built...
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On Fri, Jan 28, 2000 at 08:30:55PM -0500, John Baldwin wrote: I don't think we should change yet another thing before a release. The problem shouldn't have been created this close to a release in the first place. We have to stop somewhere, and I think we should stop "fixing" right here, right now unless there's a *really* good reason not to (IMO of course). You're right. I guess the proper solution is to just back these changes out until after 4.0 when you can finish fixing up install side of 'world'. I just got ahead of myself a little. I've been thinking about this - being the one who made the original commit! This problem is the product of _two_ recent changes in -current only. In -stable, and in -current before the end of December the following tools: ls, rm, chflags, find, xinstall and mtree used a common set of routines to manipulate file flags. These were borrowed from bin/ls/stat_flags.c and statically compiled into each tool. At the beginnig of January, because of the proliferation of utilities using these functions, I moved them to libutil in -current. There were however various objections to this change, on the basis that libutil isn't a utility library as its name suggest, but has a much more narrow definition relating to login related code. It was proposed by Bruce to move these to libc and to change their name to be in keeping with similar routines for manipulating file modes (setmode/getmode). This was what I did last week, renaming flags_to_string to getflags, and string_to_flags to setflags. I missed the clash of name space in a couple of unrelated tools, like mount_nfs, I agree that I should have been more careful here - sorry. There is now a problem for some people with the build chain due to xinstall being dependant upon a function that has changed its name for its file flags support. There is also a secondary question of whether getflags/setflags are good names for these functions (based as there were on getmode/setmode). Thinking out loud: If we back out the name change (string_to_flags-setflags) we'll bump into the buildchain problem again for people who've now got a new xinstall dependant upon setflags. Moving the functions back into libutil, from libc, is the wrong thing to do, IMHO, because the problem here isn't one of which library placement, it's one of function names. Libutil is the wrong place for these functions, which is why I wanted them in libc for the 4.0 release. It may be argued that we should back out _both_ commits and resurrect bin/ls/stat_flags.c. Would this gain us anything? I'm quite happy to DTRT(tm); I'm unsure that backing this change out _is_ the right thing however. Can we discuss it some more first please? Joe -- Josef KarthauserFreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On Fri, Jan 28, 2000 at 08:30:55PM -0500, John Baldwin wrote: I don't think we should change yet another thing before a release. The problem shouldn't have been created this close to a release in the first place. We have to stop somewhere, and I think we should stop "fixing" right here, right now unless there's a *really* good reason not to (IMO of course). You're right. I guess the proper solution is to just back these changes out until after 4.0 when you can finish fixing up install side of 'world'. I just got ahead of myself a little. I've been thinking about this - being the one who made the original commit! This problem is the product of _two_ recent changes in -current only. In -stable, and in -current before the end of December the following tools: ls, rm, chflags, find, xinstall and mtree used a common set of routines to manipulate file flags. These were borrowed from bin/ls/stat_flags.c and statically compiled into each tool. At the beginnig of January, because of the proliferation of utilities using these functions, I moved them to libutil in -current. There were however various objections to this change, on the basis that libutil isn't a utility library as its name suggest, but has a much more narrow definition relating to login related code. It was proposed by Bruce to move these to libc and to change their name to be in keeping with similar routines for manipulating file modes (setmode/getmode). This was what I did last week, renaming flags_to_string to getflags, and string_to_flags to setflags. I missed the clash of name space in a couple of unrelated tools, like mount_nfs, I agree that I should have been more careful here - sorry. There is now a problem for some people with the build chain due to xinstall being dependant upon a function that has changed its name for its file flags support. There is also a secondary question of whether getflags/setflags are good names for these functions (based as there were on getmode/setmode). Thinking out loud: If we back out the name change (string_to_flags-setflags) we'll bump into the buildchain problem again for people who've now got a new xinstall dependant upon setflags. Moving the functions back into libutil, from libc, is the wrong thing to do, IMHO, because the problem here isn't one of which library placement, it's one of function names. Libutil is the wrong place for these functions, which is why I wanted them in libc for the 4.0 release. It may be argued that we should back out _both_ commits and resurrect bin/ls/stat_flags.c. Would this gain us anything? I'm quite happy to DTRT(tm); I'm unsure that backing this change out _is_ the right thing however. Can we discuss it some more first please? I think that getflags()/setflags() should stay where they are, but I can't comment on the namespace pollution issue. If/When the functions are renamed, they'll probably break make world again (because the new libc and old install will be there for a while), but to be honest, this *is* current. I think the issue to focus on is the function names. Joe -- Josef Karthauser FreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On Sun, 30 Jan 2000, Brian Somers wrote: I'm quite happy to DTRT(tm); I'm unsure that backing this change out _is_ the right thing however. Can we discuss it some more first please? I think that getflags()/setflags() should stay where they are, but I can't comment on the namespace pollution issue. If/When the functions are renamed, they'll probably break make world again (because the new libc and old install will be there for a while), but to be honest, this *is* current. I think the issue to focus on is the function names. I agree that folks should read current, and be able to do fixes. Do the fix, though, in a way that *doesn't* require yet another fix later on, and post the extraordinary steps clearly here, in a "HEADS-UP" mail that folks will definitely see, and maybe stick something in UPDATING too? At least, give everyone a fair chance, don't embed the fix as the end of a 1,000 words of context email, at the end of a long thread. That wouldn't be fair. Not for extraordinary breakage. Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On 30-Jan-00 Josef Karthauser wrote: On Fri, Jan 28, 2000 at 08:30:55PM -0500, John Baldwin wrote: I don't think we should change yet another thing before a release. The problem shouldn't have been created this close to a release in the first place. We have to stop somewhere, and I think we should stop "fixing" right here, right now unless there's a *really* good reason not to (IMO of course). You're right. I guess the proper solution is to just back these changes out until after 4.0 when you can finish fixing up install side of 'world'. I just got ahead of myself a little. I've been thinking about this - being the one who made the original commit! :) There is now a problem for some people with the build chain due to xinstall being dependant upon a function that has changed its name for its file flags support. There is also a secondary question of whether getflags/setflags are good names for these functions (based as there were on getmode/setmode). I have no opinion on the function names used except that strflags() would be bad, IMO. Thinking out loud: If we back out the name change (string_to_flags-setflags) we'll bump into the buildchain problem again for people who've now got a new xinstall dependant upon setflags. My main concern is people going from 3.x to 4.0. Since the xinstall binary on 3.x doesn't call a string_to_flags() function from libc but has it statically compiled in, the upgrade path should work fine for them. I'll test that tonight. If that path works fine, then the problem only exists for the people using fairly recent -current who have an xinstall binary that tries to use string_to_flags() from libc. Given, then, that they are all -current users, their being able to work around this is not too much to ask. I didn't originally realize that 3.x xinstall binaries didn't try to call the string_to_flags() function from libc. With that in mind, the upgrade path is only going to be broken for a few people who should be reading -current and thus know how to work around the problem, so I repeal my request for the changes to be backed out. My apologies. Moving the functions back into libutil, from libc, is the wrong thing to do, IMHO, because the problem here isn't one of which library placement, it's one of function names. Libutil is the wrong place for these functions, which is why I wanted them in libc for the 4.0 release. Agreed. It may be argued that we should back out _both_ commits and resurrect bin/ls/stat_flags.c. Would this gain us anything? No. I'm quite happy to DTRT(tm); I'm unsure that backing this change out _is_ the right thing however. Can we discuss it some more first please? Joe -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On Sun, Jan 30, 2000 at 04:51:44PM -0500, John Baldwin wrote: [cut] With that in mind, the upgrade path is only going to be broken for a few people who should be reading -current and thus know how to work around the problem, so I repeal my request for the changes to be backed out. My apologies. Great :) So, has anyone any strong ideas on both the "correct" function names to use and what the correct API should be for the functions. Joe -- Josef KarthauserFreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: More world breakage
On 29-Jan-00 Bruce Evans wrote: On Fri, 28 Jan 2000, John Baldwin wrote: ... Solution: We need statically built install tools just like we have build tools. I think we should use the newer versions (i.e. static versions of the ones we just built under /usr/obj during buildworld that are linked against the new libraries), rather than doing some fancy footwork to Using the newer version would be even more broken, since they may be for another arch, or may just use new syscalls that don't exist in the host kernel. Hmm, ok. I think my terminology may have been poor. I meant that the new sources should have been used to build the tools, but using the existing machine headers/libraries to build the static binaries. One question though, what architecture *should* the install-tools be? Normally, one would run installworld on the target machine and not necessarily the host machine. For example, if I was cross-building an axp world on my x86 machine, then I would want to run 'make buildworld' on the x86, but would want to run 'make installworld' on the axp. Thus, the build tools in that case need to be x86 binaries, but the install tools need to be axp binaries. Of course, in that case you can't use the build machine's header files or libraries to build the install tools. Thus, you could use the headers/binaries in the source tree, except that you might then end up linking against a newer libc that needs a newer kernel to run. The other choice is to build the install tools during installworld using the target machine's headers/libraries, but then installworld would no longer be a read-only operation. :( make the existing binaries work. We already do this with the build tools. By using the newer binaries we only have to maintain one interface in our Makefiles to the install tools: whatever their current interface is in /usr/src. The build-tools are carefully built so that work in the host environment. Essentially the same thing needs to be done for installation tools. Agreed. Bruce -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
In the cross-build case, I would guess that the 'make installworld' could be run on either machine. It would depend upon which way the mounts are done. Is the host machine mounted on the target machine or the other way around. Some people strongly believe it should be one way or the other. Optimally, both cases should be handled correctly. Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: Hmm, ok. I think my terminology may have been poor. I meant that the new sources should have been used to build the tools, but using the existing machine headers/libraries to build the static binaries. One question though, what architecture *should* the install-tools be? Normally, one would run installworld on the target machine and not necessarily the host machine. For example, if I was cross-building an axp world on my x86 machine, then I would want to run 'make buildworld' on the x86, but would want to run 'make installworld' on the axp. Thus, the build tools in that case need to be x86 binaries, but the install tools need to be axp binaries. Of course, in that case you can't use the build machine's header files or libraries to build the install tools. Thus, you could use the headers/binaries in the source tree, except that you might then end up linking against a newer libc that needs a newer kernel to run. The other choice is to build the install tools during installworld using the target machine's headers/libraries, but then installworld would no longer be a read-only operation. :( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
-On [2128 19:30], John Baldwin ([EMAIL PROTECTED]) wrote: === bin/rcp install -c -s -o root -g wheel -m 4555 -fschg rcp /bin /usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" *** Error code 1 Stop in /usr/src/bin/rcp. *** Error code 1 This is indicative of a larger problem with installworld. The short version is that we need install tools just like we have build tools now. In the meantime, should you encounter a broken make world with this use the following WORKAROUND: cd /usr/src/usr.bin/xinstall make make install and resume the make world. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] bART Internet Services / BSD: Technical excellence at its best VIA NET.WORKS Netherlands Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: More world breakage
On 28-Jan-00 Jeroen Ruigrok van der Werven wrote: === bin/pwd install -c -s -o root -g wheel -m 555 pwd /bin install -c -o root -g wheel -m 444 pwd.1.gz /usr/share/man/man1 === bin/rcp install -c -s -o root -g wheel -m 4555 -fschg rcp /bin /usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" *** Error code 1 Stop in /usr/src/bin/rcp. *** Error code 1 This is the second or third make world to bomb on me with the same error. I ensured sources and such were clean. I think David O`Brien saw the same breakage. This is indicative of a larger problem with installworld. The short version is that we need install tools just like we have build tools now. The long version is this: Problem: It would seem from Asmodai's breakage that installworld assumes that it is ok to use the existing binaries on the system in /bin /usr/bin, etc. to install the new ones. However, if you have a rare case like this where the old and new libs/progs are incompatible, then there is a window between the installation of the different parts where you can get screwed. For example, here the new libc gets installed, which doesn't have the 'strings_to_flags' call. The old install program (not yet replaced) tries to call the 'string_to_flags' function which was present in the old libc but which isn't around anymore. Boom! Solution: We need statically built install tools just like we have build tools. I think we should use the newer versions (i.e. static versions of the ones we just built under /usr/obj during buildworld that are linked against the new libraries), rather than doing some fancy footwork to make the existing binaries work. We already do this with the build tools. By using the newer binaries we only have to maintain one interface in our Makefiles to the install tools: whatever their current interface is in /usr/src. Comments, suggestions? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On 28-Jan-00 Jeroen Ruigrok van der Werven wrote: === bin/pwd install -c -s -o root -g wheel -m 555 pwd /bin install -c -o root -g wheel -m 444 pwd.1.gz /usr/share/man/man1 === bin/rcp install -c -s -o root -g wheel -m 4555 -fschg rcp /bin /usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" *** Error code 1 Stop in /usr/src/bin/rcp. *** Error code 1 [snip] This is indicative of a larger problem with installworld. The short version is that we need install tools just like we have build tools now. The long version is this: [snip] It would seem from Asmodai's breakage that installworld assumes that it is ok to use the existing binaries on the system in /bin /usr/bin, etc. [snip] We need statically built install tools just like we have build tools. [snip] Comments, suggestions? [snip] I already have patches (somewhere :-) that solve this problem. I choose not to apply these before the release. I will fix installworld after the release. For now, you can use the buildkernel and installkernel targets (after a buildworld) to solve the (possibly complex) dependencies between kernel, modules and world. FYI, marcel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On 28-Jan-00 Marcel Moolenaar wrote: On 28-Jan-00 Jeroen Ruigrok van der Werven wrote: === bin/pwd install -c -s -o root -g wheel -m 555 pwd /bin install -c -o root -g wheel -m 444 pwd.1.gz /usr/share/man/man1 === bin/rcp install -c -s -o root -g wheel -m 4555 -fschg rcp /bin /usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" *** Error code 1 Stop in /usr/src/bin/rcp. *** Error code 1 [snip] This is indicative of a larger problem with installworld. The short version is that we need install tools just like we have build tools now. The long version is this: [snip] It would seem from Asmodai's breakage that installworld assumes that it is ok to use the existing binaries on the system in /bin /usr/bin, etc. [snip] We need statically built install tools just like we have build tools. [snip] Comments, suggestions? [snip] I already have patches (somewhere :-) that solve this problem. I choose not to apply these before the release. I will fix installworld after the release. For now, you can use the buildkernel and installkernel targets (after a buildworld) to solve the (possibly complex) dependencies between kernel, modules and world. This isn't related to the kernel though, it is a dependency within the world between libraries and binaries. Do you have those patches somewhere where I can look at them. I want to start testing them, because it _may_ (I'm only saying "may" right now) be better to fix this before 4.0 so that we don't have 4 million using cvsup to upgrade to 4.0 (despite all the warnings about 4.0 being only for early adopters) and then running into this and flooding -questions. I'd like to prevent a FAQ rather than create one, if you know what I mean. FYI, marcel -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
Marcel Moolenaar wrote: I already have patches (somewhere :-) that solve this problem. I choose not to apply these before the release. I will fix installworld after the release. For now, you can use the buildkernel and installkernel targets (after a buildworld) to solve the (possibly complex) dependencies between kernel, modules and world. The buildkernel target seems to be broke. The following sequence was followed (starting at 0900 PST ): %cvsup supfile.current %cd /usr/src %make -j 4 buildworld %setenv KERNEL SGK %make buildkernel -- Steve cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/net/if_ethersubr.c /usr/src/sys/net/if_ethersubr.c: In function `ether_output': /usr/src/sys/net/if_ethersubr.c:215: `ETHER_HDR_LEN' undeclared (first use in this function) /usr/src/sys/net/if_ethersubr.c:215: (Each undeclared identifier is reported only once [20 more warnings/errors deleted]. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
sgk wrote: Marcel Moolenaar wrote: I already have patches (somewhere :-) that solve this problem. I choose not to apply these before the release. I will fix installworld after the release. For now, you can use the buildkernel and installkernel targets (after a buildworld) to solve the (possibly complex) dependencies between kernel, modules and world. The buildkernel target seems to be broke. The following sequence was followed (starting at 0900 PST ): %cvsup supfile.current %cd /usr/src %make -j 4 buildworld %setenv KERNEL SGK %make buildkernel AARGH! Please, ignore. I some how removed "options INET" from my configuration files. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
I already have patches (somewhere :-) that solve this problem. I choose not to apply these before the release. I will fix installworld after the release. For now, you can use the buildkernel and installkernel targets (after a buildworld) to solve the (possibly complex) dependencies between kernel, modules and world. This isn't related to the kernel though, it is a dependency within the world between libraries and binaries. It's also related to the kernel, where installworld is installing and subsequently running binaries that won't work with the current kernel. The same applies to installing shared binaries and running them without the proper libraries. Do you have those patches somewhere where I can look at them. I want to start testing them, because it _may_ (I'm only saying "may" right now) be better to fix this before 4.0 so that we don't have 4 million using cvsup to upgrade to 4.0 (despite all the warnings about 4.0 being only for early adopters) and then running into this and flooding -questions. I'd like to prevent a FAQ rather than create one, if you know what I mean. I don't think we should change yet another thing before a release. The problem shouldn't have been created this close to a release in the first place. We have to stop somewhere, and I think we should stop "fixing" right here, right now unless there's a *really* good reason not to (IMO of course). BTW: I've posted the patches before on -committers IIRC... marcel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On 28-Jan-00 Marcel Moolenaar wrote: It's also related to the kernel, where installworld is installing and subsequently running binaries that won't work with the current kernel. The same applies to installing shared binaries and running them without the proper libraries. Ok, I'll buy that. :) Do you have those patches somewhere where I can look at them. I want to start testing them, because it _may_ (I'm only saying "may" right now) be better to fix this before 4.0 so that we don't have 4 million users using cvsup to upgrade to 4.0 (despite all the warnings about 4.0 being only for early adopters) and then running into this and flooding -questions. I'd like to prevent a FAQ rather than create one, if you know what I mean. I don't think we should change yet another thing before a release. The problem shouldn't have been created this close to a release in the first place. We have to stop somewhere, and I think we should stop "fixing" right here, right now unless there's a *really* good reason not to (IMO of course). You're right. I guess the proper solution is to just back these changes out until after 4.0 when you can finish fixing up install side of 'world'. I just got ahead of myself a little. BTW: I've posted the patches before on -committers IIRC... Probably, another case of too much energy and not quite enough careful thought on my part. marcel -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: More world breakage
On Fri, 28 Jan 2000, John Baldwin wrote: ... Solution: We need statically built install tools just like we have build tools. I think we should use the newer versions (i.e. static versions of the ones we just built under /usr/obj during buildworld that are linked against the new libraries), rather than doing some fancy footwork to Using the newer version would be even more broken, since they may be for another arch, or may just use new syscalls that don't exist in the host kernel. make the existing binaries work. We already do this with the build tools. By using the newer binaries we only have to maintain one interface in our Makefiles to the install tools: whatever their current interface is in /usr/src. The build-tools are carefully built so that work in the host environment. Essentially the same thing needs to be done for installation tools. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
