OpenSSL breaks with gcc 4.2
gcc 4.2 no longer allows function casting - which is used rather heavily by openssl. (To make things worse, it compiles but inserts abort() statements resulting in app crashes). You can see http://gcc.gnu.org/ml/gcc/2006-07/msg00037.html for a discussion on the gcc devel list. Is there a fix to make OpenSSL compatible with gcc 4.2/4.3 yet? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL breaks with gcc 4.2
On Tue, Nov 07, 2006, Bernhard Rosenkraenzer wrote: gcc 4.2 no longer allows function casting - which is used rather heavily by openssl. (To make things worse, it compiles but inserts abort() statements resulting in app crashes). Ugh, I would've thought that flagging a compiliation error would make more sense rather that outputting bad code... You can see http://gcc.gnu.org/ml/gcc/2006-07/msg00037.html for a discussion on the gcc devel list. Is there a fix to make OpenSSL compatible with gcc 4.2/4.3 yet? No there isn't yet, some technique will be needed to make this still work by tweaking some of the macros. Does casting a function to (void *) first then the function cast work? Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL breaks with gcc 4.2
On Tue, Nov 07, 2006, Bernhard Rosenkraenzer wrote: gcc 4.2 no longer allows function casting - which is used rather heavily by openssl. (To make things worse, it compiles but inserts abort() statements resulting in app crashes). Ugh, I would've thought that flagging a compiliation error would make more sense rather that outputting bad code... It is perfectly reasonable (though certainly not optimal) for a compiler to output bad code when the code it's compiling invokes undefined behavior. You can see http://gcc.gnu.org/ml/gcc/2006-07/msg00037.html for a discussion on the gcc devel list. Is there a fix to make OpenSSL compatible with gcc 4.2/4.3 yet? No there isn't yet, some technique will be needed to make this still work by tweaking some of the macros. Does casting a function to (void *) first then the function cast work? Not if by work you mean anything more than accidentally happen to work on some platforms. There is no reason a 'void (*) (struct bar *);' needs to be even remotely like a 'void (*) (char *);'. OpenSSL should be fixed to cast the parameters, not the functions. Look at this code: char * PEM_ASN1_read_bio(char *(*d2i)(),const char *name,BIO *bp,char **x, pem_password_cb *cb, void *u); #define PEM_read_X509(fp,x,cb,u) (X509 *)PEM_ASN1_read( \ (char *(*)())d2i_X509,PEM_STRING_X509,fp,(char **)x,cb,u) #define PEM_read_SSL_SESSION(fp,x,cb,u) (SSL_SESSION *)PEM_ASN1_read( \ (char *(*)())d2i_SSL_SESSION,PEM_STRING_SSL_SESSION,fp,(char **)x,cb,u) This is just wrong. A pointer to d2i_X509 and a pointer to d2i_SSL_SESSION are of different types. You cannot cast them into a common type and then write a function that can call either of them through such a pointer. The error is *NOT* from casting function pointers (like you must do to the return from 'dlsym'). It's from casting a pointer to a function of one type into a function of *another* type and then *calling* it through that pointer. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and LSB (patch)
Ben Laurie wrote: Camp, TracyX E wrote: I really didn't hear much back on this topic, but what I did hear seemed to support the approach I have been taking thus far. Please see my previous message in this thread for the details. So in hopes of moving this topic along in a practical sense, I have attached two patches that implement all the macro to function conversion that I believe would be necessary to support OpenSSL ABI stability from an LSB perspective going forward by allowing applications to always treat OpenSSL data structures as opaque types. One patch is against the released OpenSSL 0.9.8d and another is against the development snapshot from October 16th. As far as I can tell, these conversions should not present any sort of noticeable performance impact since they are almost all related to protocol setup in some manner. I also believe the changes should not impact binary compatibility with applications that where build using the macro versions of these routines. Where possible I've also attempted to preserve the coding style in use. To get OpenSSL into the LSB either a different approach would need to be proposed, or some form of the attached patches would need to make it into an OpenSSL release, followed by a significant number of Linux distributions picking up that release or later. There is an upcoming early next-year LSB 3.2 release that potentially could be the release vehicle for OpenSSL in LSB. Comments, etc. welcomed. I'm very much in favour of this. so am I Cheers, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
