Repository: comtrya/comtrya (language: rust)

Issue:
OpenSSL issue when compiling on NetBSD
I am working on trying to port comtrya over to NetBSD and ran into an initial issue in the build process. Look like it has an issue with the vendored version of openssl.

Here is the output:
```
error: failed to run custom build command for `openssl-sys v0.9.72`

Caused by:
  process didn't exit successfully: `/home/todd/Projects/comtrya/target/debug/build/openssl-sys-dede6734a7187c76/build-script-main` (exit status: 101)
  --- stdout
  cargo:rustc-cfg=const_fn
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_NETBSD_OPENSSL_NO_VENDOR
  X86_64_UNKNOWN_NETBSD_OPENSSL_NO_VENDOR unset
  cargo:rerun-if-env-changed=OPENSSL_NO_VENDOR
  OPENSSL_NO_VENDOR unset
  CC_x86_64-unknown-netbsd = None
  CC_x86_64_unknown_netbsd = None
  HOST_CC = None
  CC = None
  CFLAGS_x86_64-unknown-netbsd = None
  CFLAGS_x86_64_unknown_netbsd = None
  HOST_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("true")
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
  running "perl" "./Configure" "--prefix=/home/todd/Projects/comtrya/target/debug/build/openssl-sys-235ad40d71f59b42/out/openssl-build/install" "no-dso" "no-shared" "no-ssl3" "no-unit-test" "no-comp" "no-zlib" "no-zlib-dynamic" "no-md2" "no-rc5" "no-weak-ssl-ciphers" "no-camellia" "no-idea" "no-seed" "BSD-x86_64" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64"
  Configuring OpenSSL version 1.1.1m (0x101010dfL) for BSD-x86_64
  Using os-specific seed configuration
  Creating configdata.pm
  Creating Makefile

  **********************************************************************
  ***                                                                ***
  ***   OpenSSL has been successfully configured                     ***
  ***                                                                ***
  ***   If you encounter a problem while building, please open an    ***
  ***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
  ***   and include the output from the following command:           ***
  ***                                                                ***
  ***       perl configdata.pm --dump                                ***
  ***                                                                ***
  ***   (If you are new to OpenSSL, you might want to consult the    ***
  ***   'Troubleshooting' section in the INSTALL file first)         ***
  ***                                                                ***
  **********************************************************************
  running "make" "depend"
  running "make" "build_libs"

  --- stderr
  make: illegal argument to -j -- must be positive integer!
  thread 'main' panicked at '


  Error building OpenSSL:
      Command: "make" "build_libs"
      Exit status: exit status: 1


      ', /home/todd/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-src-111.17.0+1.1.1m/src/lib.rs:479:13
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
```

OS: NetBSD 9.2
Arch: Amd64

I have also opened an issue on OpenSSL's github.


Discussion / hints:
This has been the case for me as well. I could only ever get Comtrya built on FreeBSD by first editing Cargo.toml and removing the "vendored" feature from the openssl crate. Doing so resulted in a Comtrya binary that worked for me, however I have no idea what side effects it may cause (e.g. I have only ever used local manifests). Would be interesting to know the rationale for defining it this way in the first place and what a proper solution might be.
Let's see what happens if I remove it 😮 #144 
OK. Looks like this was a problem because Windows doesn't have a system level OpenSSL to build with. I've told Cargo to only vendor on Windows. 

I hope this helps. Should be merged when the tests pass. 
This fix has been merged to main. Going to close this issue, but please feel free to reopen if there are any further problems. 
Sounds good, thanks! Kraileth had mentioned this to me over email and it worked. I hit another issue, but I don't think it is comtrya specific but mostly how NetBSD handled the shared object library for libssl.
Earlier versions of Comtrya tried to avoid OpenSSL altogether by using ring, but it was rather unstable. I'll try again on Monday. 
If you just want a reference from NetBSD, here is the terminal output. It compiles with not using the vendored version of openssl. But it hits a runtime issue.

![image](https://user-images.githubusercontent.com/33560895/158014638-5bf47a48-e538-40ad-b765-6caa452ab860.png)

The warning is for an import I have not started using yet that I will be using in the pkgin package provider to set everything up for the boostrap.

What does `locate libssl.so` return?

I may need to try and get a NetBSD VM running to test this myself, but one of the goals of Comtrya is to run everywhere; so I'm happy to help get this working
@martintc This is interesting. Are you building with Cargo.toml as is after the recent fix or did you modify anything?

At least for me on FreeBSD this does not work for some reason. I need to comment out the line ```openssl = { version = "0.10", features = ["vendored"] }``` even though it should only apply to windows.. Tried out replacing ```[target.'cfg(windows)'.dependencies]``` with ```[target.'cfg(target_os = "windows")'.dependencies]``` which I found mentioned on the net, placed the unix part before it and such - with no success so far.

Now FreeBSD certainly isn't Windows and I'm not sure what's going on with cargo there. Would be interesting to know if it works as intended on NetBSD.
Damn, that's frustrating @kraileth. I'm going to need to dig in to this further. I am really surprised Cargo didn't respect that import definition
@rawkode I can offer you SSH access to a FreeBSD jail and a NetBSD VM with Rust and Git installed if it helps. Just drop me a mail with a public key if you want me to provide the two dev systems.
@kraileth and @rawkode 

This is with the adjustment to `Cargo.toml` to removing the vendored version and just using `openssl = '0.10'`

![image](https://user-images.githubusercontent.com/33560895/158015506-721042e3-b117-4ace-9200-acf3733ff657.png)

What is look like is the linker is finding `libssl.so.14` when it expects `libssl.so.1.1.` At least that was the jist I got from a chain of emails in the NetBSD mailing list. Looks like this issue was hit with firefox on NetBSD since firefox uses a lot of Rust code. One possible solution I saw was changing the path in the BSD Makefile in pkgsrc to help comtry/rust find the appropriate libssl during the linking phase.

[Email from NetBSD mailing list](https://mail-index.netbsd.org/pkgsrc-users/2020/02/21/msg030505.html)

To see any changes to my fork for working on NetBSD

[My working branch for NetBSD](https://github.com/martintc/comtrya/tree/NetBSD)


Huh, interesting. I pulled the recent change from main into my NetBSD branch and yea, Cargo doesn't seem to be respecting the `[target.`cfg(unix)`.dependencies]` so current it does not compile. I will probably revert that back.

Have removed those lines from my NetBSD branch. So now that branch compiles without error on NetBSD.

Fix patch:
diff --git a/Cargo.toml b/Cargo.toml
index 834c6f7c..238e7981 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -36,11 +36,7 @@ walkdir = "2"
 which = "4.0.2"
 whoami = "1.1.0"
 
-[target.'cfg(windows)'.dependencies]
-openssl = { version = "0.10", features = ["vendored"] }
-
 [target.'cfg(unix)'.dependencies]
-openssl = { version = "0.10" }
 users = "0.11.0"
 
 [dev-dependencies]


Test patch: