-
-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix ld error with TBB_LIB on macos #3070
Conversation
And we still get the right TBB being linked in on macOS? The flag was introduced on Linux to enforce that no system defaults lead to link against a system TBB rather than the supplied TBB by Stan. |
The flag is only used when the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great!
We've actually been patching this out in the conda build for some time, I've just continuously forgotten to upstream it: https://github.com/conda-forge/cmdstan-feedstock/blob/main/recipe/no-dtag-flag.patch
Peak downstream behaviour |
Jenkins Console Log Machine informationNo LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focalCPU: G++: Clang: |
This change broke a build I had that was manually setting The build in question is not on a Mac, but does use clang's lld. We don't really have a good way of detecting this automatically. I also noticed this flag is only actually being passed if you are using a custom TBB, not one vendored by Stan, so I wonder why we even need it at all? |
A that makes sense, we could just wrap the
Because if you try to use a custom TBB with Stan on Macos then you can't build the math library/cmdstan at all - because macos doesn't support the flag |
I meant "why do we need |
Ah sorry, I thought you were asking why we needed the change. I don't know enough about the TBB & linking or what the flag does, but @wds15 mentioned above that it was used to stop Stan from unintentionally linking to the wrong TBB |
I think we can get nice, customizable behavior with # MacOS ld does not support --disable-new-dtags
ifneq ($(OS),Darwin)
LDFLAGS_TBB_DTAGS ?= -Wl,--disable-new-dtags
endif
# Windows LLVM/Clang does not support -rpath, but is not needed on Windows anyway
ifneq ($(OS), Windows_NT)
LDFLAGS_TBB_RPATH ?= -Wl,-rpath,"$(TBB_LIB)"
endif
LDFLAGS_TBB ?= -Wl,-L,"$(TBB_LIB)" $(LDFLAGS_TBB_DTAGS) $(LDFLAGS_TBB_RPATH) |
Summary
While helping a user specify the Homebrew TBB for use with CmdStan, I discovered that the linker on macos doesn't support the
-Wl,--disable-new-dtags
argument:It's not an issue with the Linux clang though (checked in a Debian Sid docker image)
Tests
N/A
Side Effects
N/A
Release notes
Fix linker error when using external TBB on MacOS
Checklist
Copyright holder: Andrew Johnson
The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
- Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
- Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
the basic tests are passing
./runTests.py test/unit
)make test-headers
)make test-math-dependencies
)make doxygen
)make cpplint
)the code is written in idiomatic C++ and changes are documented in the doxygen
the new changes are tested