Page MenuHomeFreeBSD

2020-02-29 rm GCC 4.2.1 build infrastructure
Needs ReviewPublic

Authored by emaste on Jan 10 2020, 5:28 PM.

Details

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

emaste created this revision.Jan 10 2020, 5:28 PM
brooks added a subscriber: brooks.Jan 10 2020, 10:23 PM
brooks added inline comments.
Makefile.inc1
234

Can drop parenthesis.

3004

I'm confused what removed .if this aligns with.

3335

Does XDEV make sense without a compiler?

emaste added inline comments.Jan 12 2020, 5:32 PM
Makefile.inc1
234

Will do in next update.

3004

It doesn't; seems it came from a mis-rebase. In the next update I'll combine the MK_CXX and MK_LIBCPLUSPLUS above.

lwhsu added a subscriber: lwhsu.Jan 13 2020, 9:09 AM
emaste added inline comments.Jan 13 2020, 2:32 PM
Makefile.inc1
3335

removing ${_gcc} is needed anyway; what do you suggest we do w/ XDEV if MK_CLANG==no?

emaste updated this revision to Diff 66683.Jan 13 2020, 2:33 PM

minor tweaks from @brooks

imp added inline comments.Jan 13 2020, 2:38 PM
Makefile.inc1
3335

It makes no sense. It should fail in some way. Xdev is there to make the compiler and toolchain stuff. It was only a variable here since clang was introduced. It used to be unconditional gcc.

emaste added inline comments.Jan 13 2020, 3:35 PM
Makefile.inc1
3335

This issue predates my proposed change though; archs without either clang or gcc 4.2.1 (like riscv) would have had this problem already.

brooks accepted this revision.Jan 14 2020, 4:27 AM
This revision is now accepted and ready to land.Jan 14 2020, 4:27 AM
imp accepted this revision.Jan 14 2020, 5:45 AM
imp added inline comments.
Makefile.inc1
3335

It's ok, I guess. It only makes sense for in tree toolchain... we can leave it likes this...

emaste added inline comments.Jan 14 2020, 3:38 PM
Makefile.inc1
3335

I think we could/should still do something about it, but it can happen before or after this change. Probably if any of ${_clang_libs}, ${_lld}, ${_binutils}, ${_elftctools}, ${_clang} are empty it could be a .error. Well, empty ${_binutils} is OK depending on arch.

jhb added inline comments.Jan 14 2020, 5:46 PM
Makefile.inc1
180–181

We should probably rm the bits to try to set CROSS_BINUTILS_PREFIX. aarch64 and riscv64 were the users of this before and they both now use LLD. I think it won't conflict. I'll see if I can do that as a separate change sooner.

One thing we want to make sure of today is that right now 'make buildworld' for mips and sparc64 should be failing unless someone has manually set WITH_GCC to yes. Not sure where that needs to happen (either here or src.opts.mk)

We should probably rm the bits to try to set CROSS_BINUTILS_PREFIX. aarch64 and riscv64 were the users of this before and they both now use LLD. I think it won't conflict. I'll see if I can do that as a separate change sooner.

I don't think it will conflict, and in any case I'll rebase this over the change if it goes in first.

emaste added inline comments.Jan 22 2020, 3:47 PM
tools/build/mk/OptionalObsoleteFiles.inc
1766–1767

@jhb is the intent that we keep these here in OptionalObsoleteFiles.inc but move the rest to ObsoleteFiles.inc?

jhb added a comment.Thu, Jan 30, 6:19 PM

So one question I have is if 'make xdev' makes sense in a clang world? clang is already a cross-compiler via -target. Probably not for this change, but if 'make xdev' is now obsolete it might be nice to GC those bits as a followup.

tools/build/mk/OptionalObsoleteFiles.inc
1766–1767

I think it is simplest if we just move it all.

imp added a comment.Thu, Jan 30, 7:28 PM
In D23124#514030, @jhb wrote:

So one question I have is if 'make xdev' makes sense in a clang world? clang is already a cross-compiler via -target. Probably not for this change, but if 'make xdev' is now obsolete it might be nice to GC those bits as a followup.

It's used in package building. There, cc needs to generate the target's binaries w/o a lot of ability to intercept. We'd have to rework that stuff to be a series of shell scripts to be a drop in. This is in the context of the arm jail on a amd64 host. We drop the amd64 binaries into that for better performance. so definitely not for this change.

In D23124#514059, @imp wrote:
In D23124#514030, @jhb wrote:

So one question I have is if 'make xdev' makes sense in a clang world? clang is already a cross-compiler via -target. Probably not for this change, but if 'make xdev' is now obsolete it might be nice to GC those bits as a followup.

It's used in package building. There, cc needs to generate the target's binaries w/o a lot of ability to intercept. We'd have to rework that stuff to be a series of shell scripts to be a drop in. This is in the context of the arm jail on a amd64 host. We drop the amd64 binaries into that for better performance. so definitely not for this change.

Won't that completely stop working the moment we remove gcc 4.2.1?

Won't that completely stop working the moment we remove gcc 4.2.1?

No, I'm confused. That being said, we almost certainly want to move this be something we do in ports and I'm a bit concerned that it's going to be hard to make this model work with riscv (where someone decided the triple should encode nearly nothing about the ABI.)

imp added a comment.Fri, Jan 31, 1:04 AM

Won't that completely stop working the moment we remove gcc 4.2.1?

No, I'm confused. That being said, we almost certainly want to move this be something we do in ports and I'm a bit concerned that it's going to be hard to make this model work with riscv (where someone decided the triple should encode nearly nothing about the ABI.)

I suspect that it will become something that generates the cc, et al, shell scripts that call clang with the right args, which may be more than just --target triple, if need be. I suspect that will answer this concern. At the moment, clang built this will works, at least for arm and mips. After the change, xdevbuild will creaete the shell scripts and xdevinstall will arrange things such that they can be run in the chroot jail we use to build packages.

And to be clear, this is cross-building packages only, not 100% native on native hardware.

emaste updated this revision to Diff 67816.Wed, Feb 5, 3:02 PM
  • rebase
  • remove gperf remnants
  • remove cc_tools leftovers from Makefile.inc1
-       # Clean out improper TARGET=MACHINE files
-       ${_+_}cd ${.CURDIR}/gnu/usr.bin/cc/cc_tools; ${NXBTMAKE} cleandir
This revision now requires review to proceed.Wed, Feb 5, 3:02 PM
jhb added inline comments.Wed, Feb 5, 8:27 PM
Makefile.inc1
223–224

I think this case can't even happen anymore since you just removed the WANT_COMPILER_TYPE=gcc above? That is, I think you can just remove the .elif and not bother adding this .error.

emaste added inline comments.Wed, Feb 5, 8:40 PM
Makefile.inc1
223–224

Good point, fixed locally and will be included in next upload.
(If no other changes I plan to rebase, update ObsoleteFiles.inc etc. and upload again a few days before the end of the month.)

imp accepted this revision.Thu, Feb 6, 12:18 AM

I like it, and agree with the other comments you've already said you'd address.

Makefile.inc1
2691

as others have noted, we should revisit what we want to do with xtools/xdev targets once we have gcc out of the tree since clang may be able to do a lot of the heavy lifting more easily. Though it's complicated by the fact that we build libraries and such too...

3335

I'd suggest having the whole 'rototil xdev' stuff be separate from this change.

share/mk/src.opts.mk
308

ah, gdb...

480

This will cause a merge conflict before the end of the month...

This revision is now accepted and ready to land.Thu, Feb 6, 12:18 AM
emaste added inline comments.Thu, Feb 6, 12:22 AM
share/mk/src.opts.mk
480

A rather trivial one though :)
I expect to rebase this every week or so leading up to the end of the month.

emaste updated this revision to Diff 68123.Tue, Feb 11, 5:40 PM

update ObsoleteFiles.inc and OptionalObsoleteFiles.inc

This revision now requires review to proceed.Tue, Feb 11, 5:40 PM
jhb added inline comments.Tue, Feb 11, 9:28 PM
ObsoleteFiles.inc
40

Looks good to me, thanks

emaste updated this revision to Diff 68635.Fri, Feb 21, 1:52 PM
  • rebase
  • add UPDATING entry