Page MenuHomeFreeBSD

lang/llvm40: Update for ino64
ClosedPublic

Authored by kib on May 18 2017, 3:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Dec 1, 8:54 PM
Unknown Object (File)
Oct 20 2024, 4:11 PM
Unknown Object (File)
Oct 7 2024, 3:37 AM
Unknown Object (File)
Oct 3 2024, 8:09 PM
Unknown Object (File)
Oct 2 2024, 4:03 PM
Unknown Object (File)
Oct 2 2024, 7:31 AM
Unknown Object (File)
Aug 31 2024, 11:32 PM
Unknown Object (File)
Aug 19 2024, 3:39 PM

Details

Reviewers
brooks
ed
Group Reviewers
portmgr
Commits
rP441623: Adapt to ino64 changes.[0]
Summary

This change adopts the port to ino64 commit, which is explained in
https://lists.freebsd.org/pipermail/freebsd-current/2017-April/065687.html
The src change is nearly ready to commit, and is undergoing a final round
of pre-commit testing. This will likely happen in the next few days,
unless some issue found.

In general, patches for ino64 support will be conditional on FreeBSD
version. It is likely that __FreeBSD_version / kern.osreldate 1200031
will be the value used for the ino64 change, and the port patch may have
a conditional test using that value. Of course, if the final value in
the src commit is different the ports patches will be updated before
commit.

A number of ports require updates after this change is committed to src.
I seek approval of the change to the port in this review, either directly
from the maintainer or portmgr blanket approval of the set of ino64 port
updates. In either case I will commit the ports change shortly after the
src tree commit.

I am also happy if you, as maintainer of the port, wish to handle this
yourself. Please add a comment here with your preference for this port.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

The ino64 src change is in review D10439

devel/llvm40/Makefile
343

How is the being handling upstream in llvm? It seems that something conditionally applied isn't going to fly.

devel/llvm40/Makefile
343

Upstream does not handle this at all, for obvious reasons.

Some bits of the patch, like use of fstatat() instead of fstat() or getdirentries() instead of getdents(), can be applied unconditionally. But pieces where llvm redefines system structures, cannot.

Presumably upstream will need a patch with embedded __FreeBSD_version conditional blocks.

brooks added subscribers: dim, ed.

This is fine for the moment. Hopefully someone with an llvm commit bit can upstream these two pieces.

This revision is now accepted and ready to land.May 18 2017, 9:47 PM

Presumably upstream will need a patch with embedded __FreeBSD_version conditional blocks.

That would lock the compiled library to the version compiled on. It's a compromise, but hopefully acceptable.

In D10797#224198, @dim wrote:

Presumably upstream will need a patch with embedded __FreeBSD_version conditional blocks.

That would lock the compiled library to the version compiled on. It's a compromise, but hopefully acceptable.

Indeed, but I think that's reasonable for the sanitizer libraries, which by their nature have pretty deep knowledge of ABI internals.

I'm going to commit this with the diff split in two as I expect it to land upstream in two parts.

This revision was automatically updated to reflect the committed changes.

PORTREVISION went backwards. :-(

In D10797#225646, @jkim wrote:

PORTREVISION went backwards. :-(

Whoops. Fixed in rP441626. Thanks for the report.