Page MenuHomeFreeBSD

2020-02-29 rm GCC 4.2.1 build infrastructure
ClosedPublic

Authored by emaste on Jan 10 2020, 5:28 PM.
Tags
None
Referenced Files
F80141408: D23124.id.diff
Thu, Mar 28, 12:14 PM
Unknown Object (File)
Sat, Mar 9, 4:03 AM
Unknown Object (File)
Sat, Mar 9, 4:03 AM
Unknown Object (File)
Sat, Mar 9, 4:03 AM
Unknown Object (File)
Sat, Mar 9, 4:03 AM
Unknown Object (File)
Sat, Mar 9, 4:03 AM
Unknown Object (File)
Sat, Mar 9, 4:03 AM
Unknown Object (File)
Thu, Mar 7, 10:56 PM

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

brooks added inline comments.
Makefile.inc1
234

Can drop parenthesis.

3003

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

3334

Does XDEV make sense without a compiler?

Makefile.inc1
234

Will do in next update.

3003

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

Makefile.inc1
3334

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

Makefile.inc1
3334

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.

Makefile.inc1
3334

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

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

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

Makefile.inc1
3334

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.

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.

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?

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.

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.)

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.

  • 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.Feb 5 2020, 3:02 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.

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.)

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

Makefile.inc1
2690

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...

3334

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

share/mk/src.opts.mk
309

ah, gdb...

481

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

This revision is now accepted and ready to land.Feb 6 2020, 12:18 AM
share/mk/src.opts.mk
481

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

update ObsoleteFiles.inc and OptionalObsoleteFiles.inc

This revision now requires review to proceed.Feb 11 2020, 5:40 PM
ObsoleteFiles.inc
40

Looks good to me, thanks

  • rebase
  • add UPDATING entry
This revision is now accepted and ready to land.Mar 5 2020, 9:58 PM