Skip to content
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

got vibe to compile against openssl 1.1.0 #1759

Closed
wants to merge 1 commit into from
Closed

Conversation

@burner
Copy link
Contributor

@burner burner commented May 12, 2017

just a crude hack, but I think nothing is fundamentally wrong with it.

#1758

@burner
Copy link
Contributor Author

@burner burner commented May 12, 2017

is there any way to see the openssl version

@s-ludwig
Copy link
Member

@s-ludwig s-ludwig commented May 12, 2017

There is OpenSSL_version_num() - hopefully available on all involved versions.

@burner
Copy link
Contributor Author

@burner burner commented May 12, 2017

I meant at link time. The tests seem to fail to link.

@burner
Copy link
Contributor Author

@burner burner commented May 27, 2017

libressl looks like an alternative, has anyone had a look at that one yet?
they wrote a new tls library (tls.h) https://github.com/daniloegea/libressl-tls-api-examples shows an example

@wilzbach
Copy link
Member

@wilzbach wilzbach commented Jul 10, 2017

I meant at link time. The tests seem to fail to link.

@burner: if you want to build a hack on top of a hack, you could use a preBuildsCommands and utilize the output of:

readelf -d /usr/lib/libssl.so | grep SONAME | sed -E 's/.*libssl[.]so[.](.*)].*/\1/'

e.g. by storing it in a gitignored D file

@burner
Copy link
Contributor Author

@burner burner commented Jul 11, 2017

@wilzbach thanks I will try that

@s-ludwig s-ludwig closed this in 44ee1ad Aug 12, 2017
@s-ludwig
Copy link
Member

@s-ludwig s-ludwig commented Aug 12, 2017

I've pulled this now and embedded it into a version (VibeUseOpenSSL11) until a better option supported by DUB is available.

@s-ludwig
Copy link
Member

@s-ludwig s-ludwig commented Aug 12, 2017

Maybe this can be solved in a proper way by extending the libs field to support version specifications or similar. The actual version could also be reported through a mechanism analog to dlang/dub#6.

BTW, @burner thanks a lot for having done the fiddling to get this working!

@burner
Copy link
Contributor Author

@burner burner commented Aug 12, 2017

@s-ludwig nice thanks

@MartinNowak
Copy link
Contributor

@MartinNowak MartinNowak commented Aug 14, 2017

Maybe this can be solved in a proper way by extending the libs field to support version specifications or similar. The actual version could also be reported through a mechanism analog to dlang/dub#6.

BTW, @burner thanks a lot for having done the fiddling to get this working!

One supported way would be to let people choose different openssl dub versions, e.g. 1.1.5+1.0.2j or 2.0.1+1.1.0f. Unfortunately this is not automatic.
The libs field already does support versioned libraries, see the workaround in #1748 (comment). Most ld versions do support this syntax by now.

@wilzbach
Copy link
Member

@wilzbach wilzbach commented Aug 14, 2017

Why not list the openssl library dynamically?
Dlang-requests does this: ikod/dlang-requests#45 (comment)

s-ludwig added a commit that referenced this pull request Mar 18, 2018
s-ludwig added a commit that referenced this pull request Apr 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants