On Wed, 2014-10-29 at 21:24 +0100, Gyrd Thane Lange wrote: > On Wed, 29 Oct 2014 08:42:22 -0600 > Ian Lepore <i...@freebsd.org> wrote: > > > On Wed, 2014-10-29 at 14:38 +0100, Gyrd Thane Lange wrote: > > > On Wed, 29 Oct 2014 01:24:32 +0100 > > > Gyrd Thane Lange <gyrd...@thanelange.no> wrote: > > > > > > > On Tue, 28 Oct 2014 16:45:47 -0700 > > > > NGie Cooper <yaneurab...@gmail.com> wrote: > > > > > > > > > On Tue, Oct 28, 2014 at 4:35 PM, Gyrd Thane Lange > > > > > <gyrd...@thanelange.no> wrote: > > > > > > On Tue, 28 Oct 2014 17:01:39 -0600 > > > > > > Ian Lepore <i...@freebsd.org> wrote: > > > > > > > > > > > >> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote: > > > > > >> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > > > > > >> > > > > > >> Do a "make kernel-toolchain" which will build a new > > > > > >> ctfconvert and put it in the right place within /usr/obj to > > > > > >> be used during buildkernel. > > > > > > > > > > > > Thanks, I will try this (building now). But if it works I'll > > > > > > be somewhat confused. I thought kernel-toolchain was implicit > > > > > > when doing a full buildworld (which I've already done), and I > > > > > > already have a ctfconvert > > > > > > (/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert). > > > > > > > > Finished a make kernel-toolchain (but it left me with even less > > > > binaries than make buildworld): > > > > > > > > # find /usr/src/ /usr/obj -name ctfconvert -type f > > > > (nothing found) > > > > > > > > > > The problem looks more like buildkernel is ignoring the > > > > > > ctfconvert tool in /usr/obj/ and instead is expecting to find > > > > > > it in /usr/bin (or some such). > > > > > > > > > > It should be located in /usr/obj -- we should not expect the > > > > > tool in /usr/bin to be correct/compatible with the source tree. > > > > > > > > I agree. :) > > > > > > > > while waiting for a proper solution for this, I'll try looking at > > > > the Makefiles and bsd.*.mk files under /usr/src my self, but I > > > > have never looked at them before so I don't expect a speedy > > > > success. > > > > > > Discovered that the tools are set in /usr/src/share/mk/sys.mk: > > > > > > CTFCONVERT ?= ctfconvert > > > CTFMERGE ?= ctfmerge > > > DTRACE ?= dtrace > > > > > > I then set the following in my /etc/src.conf (NB! long lines): > > > > > > CTFCONVERT=env > > > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf/ > > > /usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert > > > CTFMERGE=env > > > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf > > > /usr/obj/usr/src/cddl/usr.bin/ctfmerge/ctfmerge > > > DTRACE=env > > > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf:/usr/obj/usr/src/cddl/lib/libdtrace > > > /usr/obj/usr/src/cddl/usr.sbin/dtrace/dtrace > > > > > > This allowed me to successfully build the kernel. > > > > > > > The important question to be asking at this point: > > > > Why are you the only person in the world who has had to do this? > > > > Until you have an answer to that, nothing is really fixed. The thing > > that's different for you than for most people, I guess, is that you > > originally built the system WITHOUT_CDDL then removed that option. > > That's almost certainly a factor somehow. > > > > Also, the copy of the tool within obj that it should use is not the > > copy you manually pointed to with those changes. When newer build > > tools are needed, they exist within /usr/obj/usr/src/tmp/. So... why > > doesn't ctfconvert exist for you in that location after making > > kernel-toolchain? > > It does not exist in that location for anybody (not just me)*. I just
Umm, no. It exists for me, for example: revolution > find obj/ -name ctfconvert -type f obj/arm.armv6/local/build/staging/freebsd/wand/src/cddl/usr.bin/ctfconvert/ctfconvert obj/arm.armv6/local/build/staging/freebsd/wand/src/tmp/legacy/usr/bin/ctfconvert obj/arm.armv6/local/build/staging/freebsd/wand/src/tmp/local/build/staging/freebsd/wand/src/cddl/usr.bin/ctfconvert/ctfconvert The first file is the one that will get installed to DESTDIR during installworld. The second is the one that gets built in the legacy step and then is used to build the one in the bootstrap step. The third is the one built in the bootstrap step that gets used for buildworld and buildkernel. These exist for me because my build system is older than 1100006. Yours is not, so there's no need to build a newer ctfconvert because the already-installed one on your system is good enough. Except there was no already-installed one, because you had WITHOUT_CDDL when you did installworld. Then I offered bad advice that "make kernel-toolchain" should fix it. I just didn't think hard enough about what the actual problem was. The right advice would have been that you should install the ctfconvert that didn't get installed originally because of your options. In other words "make buildworld installworld SUBDIR_OVERRIDE=cddl" is probably the right way to undo the WITHOUT_CDDL decision. It appears that src/Makefile.inc1 already does the right thing in regards to building ctconvert as a bootstrap tool when it needs to. > happen to notice it sooner because I have no ctfconvert installed on > the host beforehand. Actually, mine is the better situation in that the > build stopped with an up front error instead of using the wrong > (possible outdated) tools and introduced other subtle errors. > > I believe this is reproducible on anybodys system by deleting/moving > the ctfconvert tool away from the host, before trying to build a dtrace > enabled kernel. > I think you'll find that that is true of any number of programs in /usr/bin including, for example, cc or ar or ld. > I see elsewhere in the thread that Garret and Mark are onto the real > problem and solution. > I don't think so. Mark referred to a problem with the wrong version of ctfconvert, and he said he thought it had been fixed. Your problem wasn't corrupted files due to wrong-version. We must not let this situation turn into some kind of mythology about an incompatibility that doesn't exist. You reported that a tool was missing during the build, we know why it was missing, and we know what to do to make it not be missing anymore. Problem solved. -- Ian > Gyrd ^_^ > > * Actually, I did see some libraries copied to /usr/obj/usr/src/tmp/.../ > but none of the tools. Users that are upgrading from quite older > versions and/or are crossbuilding may have the tools. > > > > > -- Ian > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscr...@freebsd.org" _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
