-
Notifications
You must be signed in to change notification settings - Fork 37
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
Alire Project does not currently build OpenSSL #366
Comments
Hi @andrewathalye which release of AWS do you have on Alire? The 23.0.0 should have openssl enabled: https://github.com/alire-project/alire-index/blob/stable-1.2.1/index/aw/aws/aws-23.0.0.toml#L17 |
I am using 23.0.0, however unfortunately it does not actually seem to build with OpenSSL support. I can try a fresh build though to be sure. |
Have just done a rebuild and can confirm that OpenSSL support is not built in when a project "withs" aws. When I build it on its own (~/bin/alr build from inside aws-23.0.0/) it does build OpenSSL support though. The contents of Makefile.setup indicate that SOCKET=openssl, so it should be built. Edit: I think I’ve sorted why it doesn’t work. Even though the Makefile is executed correctly for the setup phase, the actual GPR project for aws expects to read $SOCKET as an environment variable, and since the Alire toml doesn’t set it itself and doesn’t build via the Makefile, the build cannot proceed. Maybe a better solution long-term would be to allow Alire to execute an external build script for non-Ada projects that can / need to be built locally. |
Another solution would be to have the alire project use the makefile to build and install. I just realised that it currently isn’t building, but just running setup. I think that’s probably the root cause of the issue. With that done it shouldn’t be necessary to set PRJ_TARGET and TARGET in the alire toml either :) Alternatively, making it so that running "make setup" generates its own config gpr would work pretty well, then the whole build could be run through gprbuild only. Edit: I think my last idea is the best, because it looks like even having it do a full build in post_fetch doesn’t work well and requires rebuilding some files during each dependent project build. A very simple example: abstract project AWS_Config is
prefix := "install_dir"
DEFAULT_LIBRARY_TYPE := "static"
ENABLE_SHARED := "true"
ZLIB := "false"
XMLADA := "false"
LAL := "false"
NETLIB := "gnat"
SOCKET := "openssl"
SSL_DYNAMIC := "false"
LDAP := "false"
DEBUG := "true"
PROCESSORS := "0"
TARGET := "x86_64-gentoo-linux-musl"
THREAD_SANITIZER := "false"
GSOAP := "false"
SERVER_HTTP2 := "true"
CLIENT_HTTP2 := "false"
end AWS_Config; It wouldn’t even be too bad to generate a build_config project the same way as is currently done for aws_xmlada, aws_lal, etc. |
Hi @andrewathalye , we poster the 24.0 release of AWS in Alire. It should fix the issue you mentioned. Can you have a look and let us know if it is ok on your side? |
It looks like the intent of the alire.toml is to build OpenSSL support, however the resulting library does not have OpenSSL support. A quick fix is to add "SOCKET="openssl"" to the [gpr-set-externals] section. I’m not sure what the actual issue here is unfortunately.
The text was updated successfully, but these errors were encountered: