Re: [openssl-users] Dealing with RFC2553 and RFC3493 where NI_MAXHOST and NI_MAXSERV no longer exist
On 1/22/19 2:58 PM, Kurt Roeckx wrote: On Fri, Jan 18, 2019 at 06:40:05PM -0500, Dennis Clarke wrote: On 1/18/19 1:53 AM, Dennis Clarke wrote: Going in circles trying to compile 1.1.1a with strict C99 and no optimizations and with a ready to debug and single step resultant library. Ignore all this. Thou shalt not C99 here. Our code base is currently C89/C90, with some extenions, but things like gcc default to something like "gnu99", "gnu11" or "gnu17". And we actually make use of some of those extensions not in C89. I tend to look at anything 'gnu-foo' as clearly non-standard but still very very popular and thus defacto standard. Whatever that means. :-) The ones I know about: - asm(): Most of those should go away if you define PEDANTIC. No need with the Oracle Studio compilers. Just use c99 and strict CFLAGS and watch it utter the endless complaints. I think the only exception is code we compile when gcc is used. - strdup() and strcasecmp() which are in POSIX, but not in C Yep .. that thing. - Setting the mutex type, which seems to be UNIX98 or XOPEN2K8 - isascii: XOPEN - usleep: Was in POSIX, has been replaced by nanosleep - long long: Since C99 Then we also use things like int32_t, but define the type ourself if the compiler is C89. We detect C11 support for atomics. Anyway, if you have a good patch to remove things that are no longer in a standard, and it also works with older systems, I suggest submit a patch. I think that Rich Salz has already weighed in on this battle and the code base is C89 clean. A leap to C99 compliance may not be on anyones horizon at all and I am not sure how much work would be needed. Curious to look at it however. Dennis Clarke ps: see excellent email from Michael Wojcik Fri Jan 18 01:25:10 UTC 2019 where "strcasecmp is a heresy" : https://mta.openssl.org/pipermail/openssl-users/2019-January/009735.html -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Dealing with RFC2553 and RFC3493 where NI_MAXHOST and NI_MAXSERV no longer exist
On Fri, Jan 18, 2019 at 06:40:05PM -0500, Dennis Clarke wrote: > On 1/18/19 1:53 AM, Dennis Clarke wrote: > > > > Going in circles trying to compile 1.1.1a with strict C99 and no > > optimizations and with a ready to debug and single step resultant > > library. > > Ignore all this. Thou shalt not C99 here. Our code base is currently C89/C90, with some extenions, but things like gcc default to something like "gnu99", "gnu11" or "gnu17". And we actually make use of some of those extensions not in C89. The ones I know about: - asm(): Most of those should go away if you define PEDANTIC. I think the only exception is code we compile when gcc is used. - strdup() and strcasecmp() which are in POSIX, but not in C - Setting the mutex type, which seems to be UNIX98 or XOPEN2K8 - isascii: XOPEN - usleep: Was in POSIX, has been replaced by nanosleep - long long: Since C99 Then we also use things like int32_t, but define the type ourself if the compiler is C89. We detect C11 support for atomics. Anyway, if you have a good patch to remove things that are no longer in a standard, and it also works with older systems, I suggest submit a patch. Kurt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Compiling openssl 1.0.2q for OS390-Unix
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Thiagu Mohan > Sent: Tuesday, January 22, 2019 00:59 > > When i tried compiling openssl 1.0.2q for OS390-Unix i got sevaeral warning > like below but > got the libraries libcrypto.a and libssl.a compiled > INFORMATIONAL CCN3764 /usr/include/signal.h:62Option rent is ignored for > variable __sigign > because pragma variable(NORENT) is specified. > INFORMATIONAL CCN3684 ./openssl.c:218 Exporting function main is not > allowed. > INFORMATIONAL CCN3684 ./bntest.c:143 Exporting function main is not > allowed. IEW2689W 4C40 > DEFINITION SIDE FILE IS NOT DEFINED. > FSUM3065 The LINKEDIT step ended with return code 4. None of those look relevant to your issue. The RENT (reentrant, if memory serves) option is specifically suppressed for __sigign by a pragma; that's probably done in the system header, so it's behaving as expected. For the openssl utility program and the test programs, you're getting diagnostics saying you can't export the main function - that's expected too. > But while building my project with these libraries i am getting lot of > unresolved errors like > plink: error: symbol 'X509_SIG_it' from archive member > "libcrypto.a(p12_asn.o)" is unresolved > plink: error: symbol 'PKCS12_AUTHSAFES_it' from archive member > "libcrypto.a(p12_add.o)" is > unresolved Are you sure you're linking against the libraries you built, and not other copies elsewhere on the system? I did a quick scan through the 1.0.2n source (don't have 1.0.2q handy), and I don't see X509_SIG_it anywhere. There's X509_SIG, X509_SIG_new, and X509_SIG_free. Similarly, there's PKCS12_AUTHSAFES but no PKCS12_AUTHSAFES_it. It's possible those were introduced after 1.0.2n, though. My suggestion would be to scan all the generated .o files with nm to see where those symbols are being introduced (apparently they're at least in p12_asn.o and p12_add.o, but maybe elsewhere as well?). That will help narrow the problem down. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
