The trick above works, although I set the path to the OpenSSL header
directory on my system (/usr/include/openssl), so that the target can
provide the headers as well as the libraries.
native.new_local_repository(
name = "boringssl",
path = "/usr/include/openssl",
build_file_content = """
cc_library(
name = "ssl",
hdrs = glob(["*"]),
copts = ["-lcrypto", "-lssl"],
)
""",
)
In lieu of an official OpenSSL Bazel build, could workarounds like this be
officially supported and mentioned in the build instructions?
On Wednesday, March 11, 2020 at 10:47:30 PM UTC-4 priy...@gmail.com wrote:
> To close the loop, the following "hack" worked for us. We ended up
> defining the following repository before grpc in our WORKSPACE file.
>
> new_local_repository(
> name = "boringssl",
> path = "/usr/lib/x86_64-linux-gnu",
> build_file_content = """
> cc_library(
> name = "ssl",
> linkopts = ["-lssl", "-lcrypto"],
> visibility = ["//visibility:public"],
> )
> """,
> )
>
> On Wednesday, March 4, 2020 at 1:15:35 PM UTC-8, Nicolas Noble wrote:
>
>> The trick here is that there's no official Bazel BUILD file for OpenSSL.
>> There's still ways to build OpenSSL using bazel, but I find it a bit iffy:
>>
>>
>> https://stackoverflow.com/questions/58094591/build-makefile-target-in-bazel/58106111#58106111
>>
>>
>> On Tue, Mar 3, 2020 at 3:55 PM 'Richard Belleville' via grpc.io <
>> grp...@googlegroups.com> wrote:
>>
>
>>> "We are currently exploring defining a fake `boringssl` local_repository
>>> which has a single target (`@boringssl//:ssl` which points to system
>>> provided openssl)"
>>>
>>> This actually sounds ideal to me. Compare what the protobuf repo does
>>> about Python headers
>>> <https://github.com/protocolbuffers/protobuf/blob/2e51ad6344111db2e1c38e1c4b78eac5f2029d17/util/python/BUILD#L3>.
>>>
>>> If you come up with a robust repository rule to pull in the system openssl,
>>> consider making it available as an example. I imagine it will be useful to
>>> many besides yourself.
>>> On Tuesday, March 3, 2020 at 3:30:35 PM UTC-8 priy...@gmail.com wrote:
>>>
>>>> Hello,
>>>>
>>>> I am trying to compile GRPC without BoringSSL. Looks like this is
>>>> supported via cmake. Is there a way to also support it via Bazel? My
>>>> current understanding is that the Bazel build unconditionally depends on
>>>> @boringssl//:ssl.
>>>>
>>>> We are using Bazel to build a custom binary that links in aws-cpp-sdk
>>>> and grpc. It seems like aws-cpp-sdk wants openssl while grpc seems to want
>>>> boringssl. We are currently exploring defining a fake `boringssl`
>>>> local_repository which has a single target (`@boringssl//:ssl` which
>>>> points
>>>> to system provided openssl). Would love to know if this is likely to be a
>>>> fool's errand.
>>>>
>>>> Regards!
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "grpc.io" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to grp...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/e8d97291-f292-444a-85c5-10eb94883bf4%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/grpc-io/e8d97291-f292-444a-85c5-10eb94883bf4%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/e308a35d-fc27-4220-8a6b-2fd67ad9e955n%40googlegroups.com.
