Front page | perl.perl5.porters |
Postings from November 2007
Andy Lester wrote: >>> OK, but what about the VMS part? That's really the key question: How >>> much simpler does the code get by removing VMS support? >> >> Not much, as I've already pointed out. > > I understand that you pointed it out. I was suggesting that Gerard's > kurila work could be an easy way to get a better feel for that. Who > knows what might shake loose? As of a year ago, I could compile and link the unmodified SAMBA V3 and SAMBA V4 UNIX code base on VMS using the unmodified UNIX build procedures. Part of the build procedure for SAMBA V4 required running the then blead perl, and part of it required Perl with some changes that I have not yet integrated into blead. I was also building and running the unmodified UNIX source code and build procedures for GTK+ 2.x and all of its components. In a few cases, I needed to remove some VMS specific code that was incorrect from some of the libraries. The main things that shook out are: * VMS is missing some libraries that UNIX assumes to be there. * UNIX programmers are assuming that undocumented and unsupported entry points to shared libraries like OpenSSL and Kerberos are present. This is one of the things blocking the SAMBA to VMS port from completion. * The VMS compiler by defaults emits some diagnostics for ANSI required warnings that GCC 3.x and earlier by default do not. * A few issues with fork()/exec() and poll()/select() showed up. * Configure tests are incorrect on any platform that has backward binary compatibility. Many configure tests are incorrect when GCC is not being used. Newer configure scripts seem to be worse on this than older, and it looks like at least 1/3 of the tests that configure is doing are unneeded. And in some cases those unneeded tests are adding significate time to the build time. -John wb8tyw@qsl.net Personal Opinion OnlyThread Previous | Thread Next