ssl.o: In function `rdssl_rkey_get_exp_mod': ssl.c:(.text+0x415): undefined reference to `RSA_get0_key' collect2: error: ld returned 1 exit status make: *** [Makefile:39: rdesktop] Error 1 * ERROR: net-misc/rdesktop-1.8.3-r3::gentoo failed (compile phase): ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-developer_libressl_20180816-174630 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.0 [2] x86_64-pc-linux-gnu-7.3.1 [3] x86_64-pc-linux-gnu-8.2.0 * Available Python interpreters, in order of preference: [1] python3.7 [2] python3.6 [3] python2.7 (fallback) [4] pypy (fallback) Available Ruby profiles: [1] ruby23 (with Rubygems) [2] ruby25 (with Rubygems) * emerge -qpv net-misc/rdesktop [ebuild N ] net-misc/rdesktop-1.8.3-r3 USE="alsa ipv6 libressl -ao -debug -kerberos -libsamplerate -oss -pcsc-lite -xrandr"
Created attachment 544314 [details] emerge-info.txt
Created attachment 544316 [details] emerge-history.txt
Created attachment 544318 [details] environment
Created attachment 544320 [details] etc.portage.tbz2
Created attachment 544322 [details] logs.tbz2
Created attachment 544324 [details] net-misc:rdesktop-1.8.3-r3:20180821-081513.log
Created attachment 544326 [details] temp.tbz2
libressl and openssl-1.1 support at the same time, OK let's try it! From failure log the undefined symbol appears in this test: #if OPENSSL_VERSION_NUMBER < 0x10100000L I will update the patch to also check for libressl version number (pulling a container to test it)
I forgot to update the bug after pushing the fix, this should have been fixed for some time now: https://gitweb.gentoo.org/repo/gentoo.git/commit/net-misc/rdesktop?id=c987c9feec42910b20ffdee9b72dddbf5a6978ca
got at the unstable amd64 chroot image 17.0-no-multilib-hardened_libressl-test_20190103-234110 this : ssl.c:(.text+<snip>): undefined reference to RSA_get0_key
Created attachment 559970 [details] emerge-info.txt
Created attachment 559972 [details] emerge-history.txt
Created attachment 559974 [details] environment
Created attachment 559976 [details] etc.portage.tbz2
Created attachment 559978 [details] logs.tbz2
Created attachment 559980 [details] net-misc:rdesktop-1.8.4:20190105-085325.log
Created attachment 559982 [details] temp.tbz2
(In reply to Bernard Cafarelli from comment #9) > I forgot to update the bug after pushing the fix, this should have been > fixed for some time now: > https://gitweb.gentoo.org/repo/gentoo.git/commit/net-misc/ > rdesktop?id=c987c9feec42910b20ffdee9b72dddbf5a6978ca this change used as a patch for 1.8.4 fixes the build and i could successfully use rdesktop.
Created attachment 563060 [details, diff] fixes build with libressl and rdesktop-1.8.4
Ah indeed, the libressl fix was lost with the 1.8.4 bump (which included openssl 1.1 support) I will commit this patch soon, @jo77ah can you take it upstream too? https://github.com/rdesktop/rdesktop
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=314daf2f1ee5933326ebe0dde344d10e11501d1d commit 314daf2f1ee5933326ebe0dde344d10e11501d1d Author: Bernard Cafarelli <voyageur@gentoo.org> AuthorDate: 2019-01-29 13:02:08 +0000 Commit: Bernard Cafarelli <voyageur@gentoo.org> CommitDate: 2019-01-29 13:02:19 +0000 net-misc/rdesktop: restore libressl fix It was lost in the 1.8.4 bump Closes: https://bugs.gentoo.org/664202 Package-Manager: Portage-2.3.59, Repoman-2.3.12 Signed-off-by: Bernard Cafarelli <voyageur@gentoo.org> .../rdesktop/files/rdesktop-1.8.4-libressl.patch | 16 +++++ net-misc/rdesktop/rdesktop-1.8.4-r1.ebuild | 70 ++++++++++++++++++++++ 2 files changed, 86 insertions(+)
i did: https://github.com/rdesktop/rdesktop/issues/308 but i'm not sure if it will land, since they plan to switch to gnutls for the next release.
(In reply to jo77ah from comment #22) > i did: https://github.com/rdesktop/rdesktop/issues/308 > > but i'm not sure if it will land, since they plan to switch to gnutls for > the next release. Thanks! Yes, if 1.9 is the next release it should not matter much, but at least it is available upstream if another maintenance release drops in