i wrote: |a deeply felt «Thank you!» goes to OpenCSW [1], which equipped me |with a SSH login to their Solaris build cluster! Very special |thanks to Dagobert Michelsen (dam at), who managed all that!
Oh, yes! Thank you, www.opencsw.org! |So this is all very fresh and i haven't yet tried the complete |cluster but only the login machine, but after quite some fixes This is still true, but in the meanwhile i have found standards(5) there and according to that we now do right. The only code adjustment needed in the end was renaming some stuff to avoid name clashes ([56a6e4e]). Good. What was needed, however, and what i have done, is a major overhauling of the build system, which was kinda rotten already and indeed had some bugs regarding variable passing from the makefiles through etc. etc. (hi, Juan and Ypnose!). Also we now simply compile-test wether compiler flags are supported *if* WANT_AUTOCC is set, and may use -O3 and -fstack-protector-strong (yet "only" -all we had), too. That extends build time (with WANT_AUTOCC); can't be helped. This ten year old SunOS revealed that our socket error handling is nonexisting (it has no entry for POP3S in /etc/services but a user won't be able to tell what the problem is). Really, i did it right naturally in my phk-utcdrift.c, for example. Really. Also -- i didn't act for SMTPS -- we really should check wether the error -- once we actually check errors -- is happening because of failed service lookup, and then retry with some fallback port numbers (like 995 for POP3S)! Also, OpenSSL v1.1.0 ([master]) obsoletes SSLv23_client_method(). It seems to replace it with another function family that uses a protocol-dependend name, but, who am i, i can't help it! Anyway, our [master] has the necessary adjustments already. To cut a long story short: i think there will be a v14.8.1 around the meteorological beginning of summer. Until then i will have checked the entire SunOS / Solaris build cluster and verified we really do right, and maybe some small things here and there. I'd be happy if anyone reported a (fixable) bug until then, too! Is a smooth experience for me beside that, hope so for you, too! P.S.: i was not lying when i said i plugged "the leaks". I did plug those easy-provocable leaks which happened due to broken pipes when viewing messages (e.g., [4e0d9b9]). Things are different for OpenSSL memory allocations: this is an inherent problem of the codebase and won't go away before v15.0: you simply cannot perform signal-caused longjmp()s when I/O blocking from within an external library! And such. |Ciao, and Farewell! (^_^)/" Have a nice weekend! --steffen ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ S-nail-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/s-nail-users
