2015-02-10 3:45 GMT+03:00 Konstantin Kolinko <knst.koli...@gmail.com>: > 2015-02-09 22:52 GMT+03:00 Rainer Jung <rainer.j...@kippdata.de>: >> Am 09.02.2015 um 20:31 schrieb Rainer Jung: >> >> >>>>> src/sslinfo.c: In function >>>>> 'Java_org_apache_tomcat_jni_SSLSocket_getInfoB': >>>>> src/sslinfo.c:221:51: error: dereferencing pointer to incomplete type >>>>> array = tcn_new_arrayb(e, &session->session_id[0], >>>>> ^ >>>>> src/sslinfo.c:222:47: error: dereferencing pointer to incomplete type >>>>> session->session_id_length); >>>>> ^ >>>>> src/sslinfo.c: In function >>>>> 'Java_org_apache_tomcat_jni_SSLSocket_getInfoS': >>>>> src/sslinfo.c:301:51: error: dereferencing pointer to incomplete type >>>>> char *hs = convert_to_hex(&session->session_id[0], >>>>> ^ >>>>> src/sslinfo.c:302:50: error: dereferencing pointer to incomplete type >>>>> session->session_id_length); >>>>> ^ >>>> >>>> >>>> Hmm, that's weird. That code's been like that for ... ever. >>>> >>>> Does anybody know what the build environment looks like for this? >>>> >>>> SSL_SESSION.session_id is an unsigned char[] >>>> >>>> It would be odd to do "&session->session_id[0]" instead of simply >>>> "session->session_id" unless one wanted to obfuscate the loss of type >>>> information. >>>> >>>> SSL_SESSION.session_id_length is an unsigned int and .. it should be >>>> fine. >>>> >>>> I think the OpenSSL being used here might be borked. >>> >>> >>> I followed a couple of links from the above ones and landed at a gump >>> page looking like it would use the master branch of OpenSSL at github. >>> >>> If that is true, it can well be, that direct access to internal OpenSSL >>> structures is no longer possible. The general tendency is making >>> structures opaque and allowing access only via accessor functions. >>> >>> I haven't checked, whether this is the case here. >> >> >> OK, this should probably be (from ssl/ssl.h): >> >> const unsigned char *SSL_SESSION_get_id(const SSL_SESSION *s, >> unsigned int *len); >> >> The function exists at least since 0.9.8 (checked with 0.9.8za). >> >> I tried to fix it in r1658557. > > I merged that into 1.1.x branch in r1658603. > > [....]
FYI: As of now, with this and subsequent fixes, there are no more build errors. The build at Gump was successful. http://vmgump.apache.org/gump/public/tomcat-native/tomcat-native-make/index.html Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
