Add initial cross-build support for OpenBSD

[am11]

Contributes to #124911
eng/common mirror dir's upstream PR dotnet/arcade#16561

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

cc @sethjackson this is an incremental step. Currently failing at:

-- Performing Test HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS - Success
-- Looking for ucol_clone
-- Looking for ucol_clone - found
CMake Error at System.Net.Security.Native/extra_libs.cmake:11 (message):
Cannot find libgssapi and System.Net.Security.Native cannot build without
it. Try installing heimdal (or the appropriate package for your platform)
Call Stack (most recent call first):
System.Net.Security.Native/CMakeLists.txt:12 (append_extra_security_libs)

Probably needs an include directory reference etc. but this is to get cross-build rolling and give you an idea how it went with other platform ports.

[sethjackson]

I got stuck on the Heimdal stuff natively too. Am a bit unsure how to fix it properly.

I have to pass this stuff to CMake to get it to "work":

-DHeimdalGssApi=ON -DCMAKE_HAVE_HEIMDAL_HEADERS=true -DCMAKE_C_FLAGS=-I/usr/local/heimdal/include

I've tried so many different combos of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, etc. and nothing works.

[am11]

Yes, it's a bit tricky. Usually cmake stuff can be figured out by looking in cmake log files; in this case, it's at: artifacts/obj/native/openbsd-x64-Debug/CMakeFiles/CMakeConfigureLog.yaml

We will eventually figure it out step by step. I'll have some time over the weekend, will take a look.

[sethjackson]

So that's where the log is at! Thanks! I was struggling trying to figure out where to look so I could debug. I was mostly looking at the .txt files heh 😬 I should also have some time this week/weekend and will look as well but I will admit to not having deep CMake knowledge.

[am11]

I haven’t tested -lunwind backtracking (OS-level unwinding) yet, but I plan to try it tonight.

On OpenBSD, there appears to be a system-provided unwinder via libunwind.h, though there is no libunwind.so. Hopefully the necessary functionality is available through libc. In the worst case, we may need to port HP libunwind (https://github.com/libunwind/libunwind) and update the shadow copy in this repository at src/native/external/libunwind which would be an entire project on its own.

That said, we are also working to reduce our reliance on OS-level unwinding. If that effort succeeds, the requirement to port libunwind to new platforms should eventually become unnecessary.

[sethjackson]

I will also pull in the changes tonight and try as well. The only thing I wasn't super sure about here is the register patterns. I'm hoping they are the same as FreeBSD. I know the ptrace() definition will work though.

[sethjackson]

One other thing I had to do in my host build is:

-DOPENSSL_CRYPTO_LIBRARY=/usr/local/lib/eopenssl35/libcrypto.so.37.0 -DOPENSSL_SSL_LIBRARY=/usr/local/lib/eopenssl35/libssl.so.37.0 -DOPENSSL_INCLUDE_DIR=/usr/local/include/eopenssl35

Not entirely sure how to get this working with cross builds because we'd have to hardcode eopenssl35 and the so names...

The above will use the OpenSSL library from ports which is API compatible with what is needed to build. The build doesn't work with LibreSSL which is what is found by default.

[am11]

@sethjackson, it turned out OpenBSD doesn't have unwinding APIs we require (unw_step) and it needs https://github.com/libunwind/libunwind port. It's a non-trivial amount of work.

@akoeplinger, lets merge this initial patch, still many incomplete pieces but PR's intention is to set the course.

[akoeplinger]

/ba-g unrelated infra timeout

[am11]

Contributes to #124911
eng/common mirror dir's upstream PR dotnet/arcade#16561

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

cc @sethjackson this is an incremental step. Currently failing at:

-- Performing Test HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS - Success
-- Looking for ucol_clone
-- Looking for ucol_clone - found
CMake Error at System.Net.Security.Native/extra_libs.cmake:11 (message):
Cannot find libgssapi and System.Net.Security.Native cannot build without
it. Try installing heimdal (or the appropriate package for your platform)
Call Stack (most recent call first):
System.Net.Security.Native/CMakeLists.txt:12 (append_extra_security_libs)

Probably needs an include directory reference etc. but this is to get cross-build rolling and give you an idea how it went with other platform ports.

[sethjackson]

I got stuck on the Heimdal stuff natively too. Am a bit unsure how to fix it properly.

I have to pass this stuff to CMake to get it to "work":

-DHeimdalGssApi=ON -DCMAKE_HAVE_HEIMDAL_HEADERS=true -DCMAKE_C_FLAGS=-I/usr/local/heimdal/include

I've tried so many different combos of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, etc. and nothing works.

[am11]

Yes, it's a bit tricky. Usually cmake stuff can be figured out by looking in cmake log files; in this case, it's at: artifacts/obj/native/openbsd-x64-Debug/CMakeFiles/CMakeConfigureLog.yaml

We will eventually figure it out step by step. I'll have some time over the weekend, will take a look.

[sethjackson]

So that's where the log is at! Thanks! I was struggling trying to figure out where to look so I could debug. I was mostly looking at the .txt files heh 😬 I should also have some time this week/weekend and will look as well but I will admit to not having deep CMake knowledge.

[am11]

I haven’t tested -lunwind backtracking (OS-level unwinding) yet, but I plan to try it tonight.

On OpenBSD, there appears to be a system-provided unwinder via libunwind.h, though there is no libunwind.so. Hopefully the necessary functionality is available through libc. In the worst case, we may need to port HP libunwind (https://github.com/libunwind/libunwind) and update the shadow copy in this repository at src/native/external/libunwind which would be an entire project on its own.

That said, we are also working to reduce our reliance on OS-level unwinding. If that effort succeeds, the requirement to port libunwind to new platforms should eventually become unnecessary.

[sethjackson]

I will also pull in the changes tonight and try as well. The only thing I wasn't super sure about here is the register patterns. I'm hoping they are the same as FreeBSD. I know the ptrace() definition will work though.

[sethjackson]

One other thing I had to do in my host build is:

-DOPENSSL_CRYPTO_LIBRARY=/usr/local/lib/eopenssl35/libcrypto.so.37.0 -DOPENSSL_SSL_LIBRARY=/usr/local/lib/eopenssl35/libssl.so.37.0 -DOPENSSL_INCLUDE_DIR=/usr/local/include/eopenssl35

Not entirely sure how to get this working with cross builds because we'd have to hardcode eopenssl35 and the so names...

The above will use the OpenSSL library from ports which is API compatible with what is needed to build. The build doesn't work with LibreSSL which is what is found by default.

[am11]

@sethjackson, it turned out OpenBSD doesn't have unwinding APIs we require (unw_step) and it needs https://github.com/libunwind/libunwind port. It's a non-trivial amount of work.

@akoeplinger, lets merge this initial patch, still many incomplete pieces but PR's intention is to set the course.

[akoeplinger]

/ba-g unrelated infra timeout

[am11]

Contributes to #124911
eng/common mirror dir's upstream PR dotnet/arcade#16561

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

cc @sethjackson this is an incremental step. Currently failing at:

-- Performing Test HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS - Success
-- Looking for ucol_clone
-- Looking for ucol_clone - found
CMake Error at System.Net.Security.Native/extra_libs.cmake:11 (message):
Cannot find libgssapi and System.Net.Security.Native cannot build without
it. Try installing heimdal (or the appropriate package for your platform)
Call Stack (most recent call first):
System.Net.Security.Native/CMakeLists.txt:12 (append_extra_security_libs)

Probably needs an include directory reference etc. but this is to get cross-build rolling and give you an idea how it went with other platform ports.

[sethjackson]

I got stuck on the Heimdal stuff natively too. Am a bit unsure how to fix it properly.

I have to pass this stuff to CMake to get it to "work":

-DHeimdalGssApi=ON -DCMAKE_HAVE_HEIMDAL_HEADERS=true -DCMAKE_C_FLAGS=-I/usr/local/heimdal/include

I've tried so many different combos of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, etc. and nothing works.

[am11]

Yes, it's a bit tricky. Usually cmake stuff can be figured out by looking in cmake log files; in this case, it's at: artifacts/obj/native/openbsd-x64-Debug/CMakeFiles/CMakeConfigureLog.yaml

We will eventually figure it out step by step. I'll have some time over the weekend, will take a look.

[sethjackson]

So that's where the log is at! Thanks! I was struggling trying to figure out where to look so I could debug. I was mostly looking at the .txt files heh 😬 I should also have some time this week/weekend and will look as well but I will admit to not having deep CMake knowledge.

[am11]

I haven’t tested -lunwind backtracking (OS-level unwinding) yet, but I plan to try it tonight.

On OpenBSD, there appears to be a system-provided unwinder via libunwind.h, though there is no libunwind.so. Hopefully the necessary functionality is available through libc. In the worst case, we may need to port HP libunwind (https://github.com/libunwind/libunwind) and update the shadow copy in this repository at src/native/external/libunwind which would be an entire project on its own.

That said, we are also working to reduce our reliance on OS-level unwinding. If that effort succeeds, the requirement to port libunwind to new platforms should eventually become unnecessary.

[sethjackson]

I will also pull in the changes tonight and try as well. The only thing I wasn't super sure about here is the register patterns. I'm hoping they are the same as FreeBSD. I know the ptrace() definition will work though.

[sethjackson]

One other thing I had to do in my host build is:

-DOPENSSL_CRYPTO_LIBRARY=/usr/local/lib/eopenssl35/libcrypto.so.37.0 -DOPENSSL_SSL_LIBRARY=/usr/local/lib/eopenssl35/libssl.so.37.0 -DOPENSSL_INCLUDE_DIR=/usr/local/include/eopenssl35

Not entirely sure how to get this working with cross builds because we'd have to hardcode eopenssl35 and the so names...

The above will use the OpenSSL library from ports which is API compatible with what is needed to build. The build doesn't work with LibreSSL which is what is found by default.

[am11]

@sethjackson, it turned out OpenBSD doesn't have unwinding APIs we require (unw_step) and it needs https://github.com/libunwind/libunwind port. It's a non-trivial amount of work.

@akoeplinger, lets merge this initial patch, still many incomplete pieces but PR's intention is to set the course.

[akoeplinger]

/ba-g unrelated infra timeout

[am11]

Contributes to #124911
eng/common mirror dir's upstream PR dotnet/arcade#16561

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

cc @sethjackson this is an incremental step. Currently failing at:

-- Performing Test HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS - Success
-- Looking for ucol_clone
-- Looking for ucol_clone - found
CMake Error at System.Net.Security.Native/extra_libs.cmake:11 (message):
Cannot find libgssapi and System.Net.Security.Native cannot build without
it. Try installing heimdal (or the appropriate package for your platform)
Call Stack (most recent call first):
System.Net.Security.Native/CMakeLists.txt:12 (append_extra_security_libs)

Probably needs an include directory reference etc. but this is to get cross-build rolling and give you an idea how it went with other platform ports.

[sethjackson]

I got stuck on the Heimdal stuff natively too. Am a bit unsure how to fix it properly.

I have to pass this stuff to CMake to get it to "work":

-DHeimdalGssApi=ON -DCMAKE_HAVE_HEIMDAL_HEADERS=true -DCMAKE_C_FLAGS=-I/usr/local/heimdal/include

I've tried so many different combos of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, etc. and nothing works.

[am11]

Yes, it's a bit tricky. Usually cmake stuff can be figured out by looking in cmake log files; in this case, it's at: artifacts/obj/native/openbsd-x64-Debug/CMakeFiles/CMakeConfigureLog.yaml

We will eventually figure it out step by step. I'll have some time over the weekend, will take a look.

[sethjackson]

So that's where the log is at! Thanks! I was struggling trying to figure out where to look so I could debug. I was mostly looking at the .txt files heh 😬 I should also have some time this week/weekend and will look as well but I will admit to not having deep CMake knowledge.

[am11]

I haven’t tested -lunwind backtracking (OS-level unwinding) yet, but I plan to try it tonight.

On OpenBSD, there appears to be a system-provided unwinder via libunwind.h, though there is no libunwind.so. Hopefully the necessary functionality is available through libc. In the worst case, we may need to port HP libunwind (https://github.com/libunwind/libunwind) and update the shadow copy in this repository at src/native/external/libunwind which would be an entire project on its own.

That said, we are also working to reduce our reliance on OS-level unwinding. If that effort succeeds, the requirement to port libunwind to new platforms should eventually become unnecessary.

[sethjackson]

I will also pull in the changes tonight and try as well. The only thing I wasn't super sure about here is the register patterns. I'm hoping they are the same as FreeBSD. I know the ptrace() definition will work though.

[sethjackson]

One other thing I had to do in my host build is:

-DOPENSSL_CRYPTO_LIBRARY=/usr/local/lib/eopenssl35/libcrypto.so.37.0 -DOPENSSL_SSL_LIBRARY=/usr/local/lib/eopenssl35/libssl.so.37.0 -DOPENSSL_INCLUDE_DIR=/usr/local/include/eopenssl35

Not entirely sure how to get this working with cross builds because we'd have to hardcode eopenssl35 and the so names...

The above will use the OpenSSL library from ports which is API compatible with what is needed to build. The build doesn't work with LibreSSL which is what is found by default.

[am11]

@sethjackson, it turned out OpenBSD doesn't have unwinding APIs we require (unw_step) and it needs https://github.com/libunwind/libunwind port. It's a non-trivial amount of work.

@akoeplinger, lets merge this initial patch, still many incomplete pieces but PR's intention is to set the course.

[akoeplinger]

/ba-g unrelated infra timeout

[am11]

Contributes to #124911
eng/common mirror dir's upstream PR dotnet/arcade#16561

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

cc @sethjackson this is an incremental step. Currently failing at:

-- Performing Test HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS - Success
-- Looking for ucol_clone
-- Looking for ucol_clone - found
CMake Error at System.Net.Security.Native/extra_libs.cmake:11 (message):
Cannot find libgssapi and System.Net.Security.Native cannot build without
it. Try installing heimdal (or the appropriate package for your platform)
Call Stack (most recent call first):
System.Net.Security.Native/CMakeLists.txt:12 (append_extra_security_libs)

Probably needs an include directory reference etc. but this is to get cross-build rolling and give you an idea how it went with other platform ports.

[sethjackson]

I got stuck on the Heimdal stuff natively too. Am a bit unsure how to fix it properly.

I have to pass this stuff to CMake to get it to "work":

-DHeimdalGssApi=ON -DCMAKE_HAVE_HEIMDAL_HEADERS=true -DCMAKE_C_FLAGS=-I/usr/local/heimdal/include

I've tried so many different combos of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, etc. and nothing works.

[am11]

Yes, it's a bit tricky. Usually cmake stuff can be figured out by looking in cmake log files; in this case, it's at: artifacts/obj/native/openbsd-x64-Debug/CMakeFiles/CMakeConfigureLog.yaml

We will eventually figure it out step by step. I'll have some time over the weekend, will take a look.

[sethjackson]

So that's where the log is at! Thanks! I was struggling trying to figure out where to look so I could debug. I was mostly looking at the .txt files heh 😬 I should also have some time this week/weekend and will look as well but I will admit to not having deep CMake knowledge.

[am11]

I haven’t tested -lunwind backtracking (OS-level unwinding) yet, but I plan to try it tonight.

On OpenBSD, there appears to be a system-provided unwinder via libunwind.h, though there is no libunwind.so. Hopefully the necessary functionality is available through libc. In the worst case, we may need to port HP libunwind (https://github.com/libunwind/libunwind) and update the shadow copy in this repository at src/native/external/libunwind which would be an entire project on its own.

That said, we are also working to reduce our reliance on OS-level unwinding. If that effort succeeds, the requirement to port libunwind to new platforms should eventually become unnecessary.

[sethjackson]

I will also pull in the changes tonight and try as well. The only thing I wasn't super sure about here is the register patterns. I'm hoping they are the same as FreeBSD. I know the ptrace() definition will work though.

[sethjackson]

One other thing I had to do in my host build is:

-DOPENSSL_CRYPTO_LIBRARY=/usr/local/lib/eopenssl35/libcrypto.so.37.0 -DOPENSSL_SSL_LIBRARY=/usr/local/lib/eopenssl35/libssl.so.37.0 -DOPENSSL_INCLUDE_DIR=/usr/local/include/eopenssl35

Not entirely sure how to get this working with cross builds because we'd have to hardcode eopenssl35 and the so names...

The above will use the OpenSSL library from ports which is API compatible with what is needed to build. The build doesn't work with LibreSSL which is what is found by default.

[am11]

@sethjackson, it turned out OpenBSD doesn't have unwinding APIs we require (unw_step) and it needs https://github.com/libunwind/libunwind port. It's a non-trivial amount of work.

@akoeplinger, lets merge this initial patch, still many incomplete pieces but PR's intention is to set the course.

[akoeplinger]

/ba-g unrelated infra timeout

[am11]

Contributes to #124911
eng/common mirror dir's upstream PR dotnet/arcade#16561

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

cc @sethjackson this is an incremental step. Currently failing at:

-- Performing Test HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS - Success
-- Looking for ucol_clone
-- Looking for ucol_clone - found
CMake Error at System.Net.Security.Native/extra_libs.cmake:11 (message):
Cannot find libgssapi and System.Net.Security.Native cannot build without
it. Try installing heimdal (or the appropriate package for your platform)
Call Stack (most recent call first):
System.Net.Security.Native/CMakeLists.txt:12 (append_extra_security_libs)

Probably needs an include directory reference etc. but this is to get cross-build rolling and give you an idea how it went with other platform ports.

[sethjackson]

I got stuck on the Heimdal stuff natively too. Am a bit unsure how to fix it properly.

I have to pass this stuff to CMake to get it to "work":

-DHeimdalGssApi=ON -DCMAKE_HAVE_HEIMDAL_HEADERS=true -DCMAKE_C_FLAGS=-I/usr/local/heimdal/include

I've tried so many different combos of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, etc. and nothing works.

[am11]

Yes, it's a bit tricky. Usually cmake stuff can be figured out by looking in cmake log files; in this case, it's at: artifacts/obj/native/openbsd-x64-Debug/CMakeFiles/CMakeConfigureLog.yaml

We will eventually figure it out step by step. I'll have some time over the weekend, will take a look.

[sethjackson]

So that's where the log is at! Thanks! I was struggling trying to figure out where to look so I could debug. I was mostly looking at the .txt files heh 😬 I should also have some time this week/weekend and will look as well but I will admit to not having deep CMake knowledge.

[am11]

I haven’t tested -lunwind backtracking (OS-level unwinding) yet, but I plan to try it tonight.

On OpenBSD, there appears to be a system-provided unwinder via libunwind.h, though there is no libunwind.so. Hopefully the necessary functionality is available through libc. In the worst case, we may need to port HP libunwind (https://github.com/libunwind/libunwind) and update the shadow copy in this repository at src/native/external/libunwind which would be an entire project on its own.

That said, we are also working to reduce our reliance on OS-level unwinding. If that effort succeeds, the requirement to port libunwind to new platforms should eventually become unnecessary.

[sethjackson]

I will also pull in the changes tonight and try as well. The only thing I wasn't super sure about here is the register patterns. I'm hoping they are the same as FreeBSD. I know the ptrace() definition will work though.

[sethjackson]

One other thing I had to do in my host build is:

-DOPENSSL_CRYPTO_LIBRARY=/usr/local/lib/eopenssl35/libcrypto.so.37.0 -DOPENSSL_SSL_LIBRARY=/usr/local/lib/eopenssl35/libssl.so.37.0 -DOPENSSL_INCLUDE_DIR=/usr/local/include/eopenssl35

Not entirely sure how to get this working with cross builds because we'd have to hardcode eopenssl35 and the so names...

The above will use the OpenSSL library from ports which is API compatible with what is needed to build. The build doesn't work with LibreSSL which is what is found by default.

[am11]

@sethjackson, it turned out OpenBSD doesn't have unwinding APIs we require (unw_step) and it needs https://github.com/libunwind/libunwind port. It's a non-trivial amount of work.

@akoeplinger, lets merge this initial patch, still many incomplete pieces but PR's intention is to set the course.

[akoeplinger]

/ba-g unrelated infra timeout

[am11]

Contributes to #124911
eng/common mirror dir's upstream PR dotnet/arcade#16561

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

cc @sethjackson this is an incremental step. Currently failing at:

-- Performing Test HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS - Success
-- Looking for ucol_clone
-- Looking for ucol_clone - found
CMake Error at System.Net.Security.Native/extra_libs.cmake:11 (message):
Cannot find libgssapi and System.Net.Security.Native cannot build without
it. Try installing heimdal (or the appropriate package for your platform)
Call Stack (most recent call first):
System.Net.Security.Native/CMakeLists.txt:12 (append_extra_security_libs)

Probably needs an include directory reference etc. but this is to get cross-build rolling and give you an idea how it went with other platform ports.

[sethjackson]

I got stuck on the Heimdal stuff natively too. Am a bit unsure how to fix it properly.

I have to pass this stuff to CMake to get it to "work":

-DHeimdalGssApi=ON -DCMAKE_HAVE_HEIMDAL_HEADERS=true -DCMAKE_C_FLAGS=-I/usr/local/heimdal/include

I've tried so many different combos of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, etc. and nothing works.

[am11]

Yes, it's a bit tricky. Usually cmake stuff can be figured out by looking in cmake log files; in this case, it's at: artifacts/obj/native/openbsd-x64-Debug/CMakeFiles/CMakeConfigureLog.yaml

We will eventually figure it out step by step. I'll have some time over the weekend, will take a look.

[sethjackson]

So that's where the log is at! Thanks! I was struggling trying to figure out where to look so I could debug. I was mostly looking at the .txt files heh 😬 I should also have some time this week/weekend and will look as well but I will admit to not having deep CMake knowledge.

[am11]

I haven’t tested -lunwind backtracking (OS-level unwinding) yet, but I plan to try it tonight.

On OpenBSD, there appears to be a system-provided unwinder via libunwind.h, though there is no libunwind.so. Hopefully the necessary functionality is available through libc. In the worst case, we may need to port HP libunwind (https://github.com/libunwind/libunwind) and update the shadow copy in this repository at src/native/external/libunwind which would be an entire project on its own.

That said, we are also working to reduce our reliance on OS-level unwinding. If that effort succeeds, the requirement to port libunwind to new platforms should eventually become unnecessary.

[sethjackson]

I will also pull in the changes tonight and try as well. The only thing I wasn't super sure about here is the register patterns. I'm hoping they are the same as FreeBSD. I know the ptrace() definition will work though.

[sethjackson]

One other thing I had to do in my host build is:

-DOPENSSL_CRYPTO_LIBRARY=/usr/local/lib/eopenssl35/libcrypto.so.37.0 -DOPENSSL_SSL_LIBRARY=/usr/local/lib/eopenssl35/libssl.so.37.0 -DOPENSSL_INCLUDE_DIR=/usr/local/include/eopenssl35

Not entirely sure how to get this working with cross builds because we'd have to hardcode eopenssl35 and the so names...

The above will use the OpenSSL library from ports which is API compatible with what is needed to build. The build doesn't work with LibreSSL which is what is found by default.

[am11]

@sethjackson, it turned out OpenBSD doesn't have unwinding APIs we require (unw_step) and it needs https://github.com/libunwind/libunwind port. It's a non-trivial amount of work.

@akoeplinger, lets merge this initial patch, still many incomplete pieces but PR's intention is to set the course.

[akoeplinger]

/ba-g unrelated infra timeout

[am11]

Contributes to #124911
eng/common mirror dir's upstream PR dotnet/arcade#16561

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

cc @sethjackson this is an incremental step. Currently failing at:

-- Performing Test HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS - Success
-- Looking for ucol_clone
-- Looking for ucol_clone - found
CMake Error at System.Net.Security.Native/extra_libs.cmake:11 (message):
Cannot find libgssapi and System.Net.Security.Native cannot build without
it. Try installing heimdal (or the appropriate package for your platform)
Call Stack (most recent call first):
System.Net.Security.Native/CMakeLists.txt:12 (append_extra_security_libs)

Probably needs an include directory reference etc. but this is to get cross-build rolling and give you an idea how it went with other platform ports.

[sethjackson]

I got stuck on the Heimdal stuff natively too. Am a bit unsure how to fix it properly.

I have to pass this stuff to CMake to get it to "work":

-DHeimdalGssApi=ON -DCMAKE_HAVE_HEIMDAL_HEADERS=true -DCMAKE_C_FLAGS=-I/usr/local/heimdal/include

I've tried so many different combos of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, etc. and nothing works.

[am11]

Yes, it's a bit tricky. Usually cmake stuff can be figured out by looking in cmake log files; in this case, it's at: artifacts/obj/native/openbsd-x64-Debug/CMakeFiles/CMakeConfigureLog.yaml

We will eventually figure it out step by step. I'll have some time over the weekend, will take a look.

[sethjackson]

So that's where the log is at! Thanks! I was struggling trying to figure out where to look so I could debug. I was mostly looking at the .txt files heh 😬 I should also have some time this week/weekend and will look as well but I will admit to not having deep CMake knowledge.

[am11]

I haven’t tested -lunwind backtracking (OS-level unwinding) yet, but I plan to try it tonight.

On OpenBSD, there appears to be a system-provided unwinder via libunwind.h, though there is no libunwind.so. Hopefully the necessary functionality is available through libc. In the worst case, we may need to port HP libunwind (https://github.com/libunwind/libunwind) and update the shadow copy in this repository at src/native/external/libunwind which would be an entire project on its own.

That said, we are also working to reduce our reliance on OS-level unwinding. If that effort succeeds, the requirement to port libunwind to new platforms should eventually become unnecessary.

[sethjackson]

I will also pull in the changes tonight and try as well. The only thing I wasn't super sure about here is the register patterns. I'm hoping they are the same as FreeBSD. I know the ptrace() definition will work though.

[sethjackson]

One other thing I had to do in my host build is:

-DOPENSSL_CRYPTO_LIBRARY=/usr/local/lib/eopenssl35/libcrypto.so.37.0 -DOPENSSL_SSL_LIBRARY=/usr/local/lib/eopenssl35/libssl.so.37.0 -DOPENSSL_INCLUDE_DIR=/usr/local/include/eopenssl35

Not entirely sure how to get this working with cross builds because we'd have to hardcode eopenssl35 and the so names...

The above will use the OpenSSL library from ports which is API compatible with what is needed to build. The build doesn't work with LibreSSL which is what is found by default.

[am11]

@sethjackson, it turned out OpenBSD doesn't have unwinding APIs we require (unw_step) and it needs https://github.com/libunwind/libunwind port. It's a non-trivial amount of work.

@akoeplinger, lets merge this initial patch, still many incomplete pieces but PR's intention is to set the course.

[akoeplinger]

/ba-g unrelated infra timeout