In order to support Boost 1.66 this is in preparation for the upgrade
port will build with both Boost 1.65 and 1.66
But the Boost 1.66 libraries will only recognised correctly IFF when
the CMake port is patched to actually recognised this Boost version in
Modules.
Details
Details
- Reviewers
jbeich - Commits
- rP457752: net/ceph: update to 12.2.2
Ceph has its onw testset included, and is correctly executed on this
version.
Diff Detail
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 13961 Build 14155: arc lint + arc unit
Event Timeline
Comment Actions
Since my port was change in between by ports-managers
there were some unneeded changes.
So reduce the difference between version.
| net/ceph/Makefile | ||
|---|---|---|
| 71 | Why do you need LLD? If it's just to fix build maybe try the following: .if ${/usr/bin/ld:L:tA} != "/usr/bin/ld.lld" # <describe rationale or error message briefly> USE_BINUTILS= yes LDFLAGS+= -B${LOCALBASE}/bin .endif
| |
Comment Actions
- I need LLD because otherwise one off the executables does not link. Seems to be a size limitation in the regular ld And after discussion with Ed Maste this was the solution that worked. Not sure how that impacts on 11.x. But my Ceph testruns do seem to work.
- I tried all kinds of incantations to get LLD to work, and this was the one that actually worked. It was painfull since it needs a poudriere rerun for every attempt. And even with ccache Ceph is big to build.
- Not really sure on how to verify that. But I would expect LDFLAGS to end up in LINK_FLAGS
| net/ceph/Makefile | ||
|---|---|---|
| 21 | Ah, I did add that line from the online version but did Sort of a pitty that changes by others to the port I maintain Will change | |
Comment Actions
Is it OK to land before Boost 1.66.0 for 2018Q1 users given Ceph 12.2.2 builds fine against Boost 1.65.1? Or did you disable some features (e.g., WITH_RADOSGW_BEAST_FRONTEND) for the sake of Boost 1.66?
| net/ceph/Makefile | ||
|---|---|---|
| 71 | I haven't tested in net/ceph yet but the conditional is based on rP457430 which itself is based on rP448576 and relies on ld.lld being a symlink (unlike ld.bfd). -B${LOCALBASE}/bin doesn't force LLD, so is less likely to break custom LDFLAGS in make.conf or on architectures still stuck with GCC (powerpc*). | |
Comment Actions
Exactly,
There is a small issue in Beast, and that is with a command for which there is an alternative.
But it can land before Boost 1.66 lands, giving you the option to pull the trigger on Boost whenever you have also fixed the Cmake FindBoost module.
And net/Ceph should build on both sides of the barrier.
| net/ceph/Makefile | ||
|---|---|---|
| 71 | Would not be able to help with PPC stuff if it broke. :) | |
| net/ceph/Makefile | ||
|---|---|---|
| 5 | DISTVERSIONPREFIX= v | |
Comment Actions
@jbeich
Could you approve once again, fixed the way the versioning was done.
This makes more sense IMHO
| net/ceph/Makefile | ||
|---|---|---|
| 71 | ceph-12.2.2 built fine on 11.1 against boost 1.65.1 with the above workaround instead of -fuse-ld=. | |
Comment Actions
I can't reproduce. Even without -fuse-ld= and -B${LOCALBASE}/bin ceph-12.2.2 builds fine: boost-libs-1.65.1_1 (11.1 amd64, 12.0 amd64), boost-libs-1.66.0 (11.1 amd64, 12.0 amd64). Can you provide more details e.g., poudriere log?
- I tried all kinds of incantations to get LLD to work, and this was the one that actually worked. It was painfull since it needs a poudriere rerun for every attempt. And even with ccache Ceph is big to build.
Have you tried disabling ccache?
Comment Actions
Oke, interesting since it has been bothering me for quite some time.
And I spent plenty of poudriere runs to find out what to use here.
I'll see if I can get a poudriere run going today with regular ld.bfd as it is.
- I tried all kinds of incantations to get LLD to work, and this was the one that actually worked. It was painfull since it needs a poudriere rerun for every attempt. And even with ccache Ceph is big to build.
Have you tried disabling ccache?
On and off, but not systematically. But (test)building ceph without ccache is a long
process on the limited hardware I have.
I'll run some more tests, but it seems that you are no longer held back by ceph
in your migration?
| net/ceph/Makefile | ||
|---|---|---|
| 71 | Yup, this is what I found in my poudriere this morning. | |