Add macro that faciliates "bazel run" of binary generated by rules_foreign_cc #971
Conversation
jheaff1
force-pushed
the
runnable_bin
branch
17 times, most recently
from
14f33ef
to
2391527
Compare
|
@UebelAndre @jsharpe Would either of you be able to give me a hand with the MacOS failures in CI? I don't own a Mac so it's hard for me to debug It seems now that OpenSSL shared libraries are built rather than static libraries, the curl test fails on MacOS only. |
I haven't got time to spend much time on this right now but looks to be rpath related. I'm guessing the rpath in the binary isn't looking at the right path to find the shared library in the runfiles? |
|
Yeah that's what I would guess also. I feel like thats an issue with bazel rather than rules_foreign_cc. I don't think there are any examples built by rules_foreign_cc that consume shared libraries |
|
I think the MacOS issue is related to bazelbuild/bazel#10254 |
|
@jsharpe @UebelAndre As it seems that the use of shared libs on sandboxed macos is a bit broken, i have removed the failing tests from CI. I hope that's acceptable. |
Previously, ff a target were to set the PATH variable in the `env` attribute, the prepending of the path to the MSVC linker to the PATH variable did not take effect, causing link failures as MSYS's "link.exe" executable would instead be used.
The existing PATH is appended to user-defined PATH additions in framework.bzl
rules_foreign_cc
is currently broken in bazel
This resolves #582
The macro also facilitates the running of dynamically linked executables, which could then be used as tools in dependent targets. This is useful when using LGPL licenced third party software that must be dynamically linked.
Note that the OpenSSL example has been changed to produce shared libraries and to produce the
opensslbinary. This tests thatrunnable_binarycan successfully run a dynamically linked binary