In message <20151222134741.72034a0b79m0z...@www.polarhome.com> on Tue, 22 Dec 2015 13:47:41 +0100, Zoltan Arpadffy <z...@polarhome.com> said:
zoli> Hi, zoli> zoli> > zoli> > (unfortunately, "cpan install Text::Template" doesn't work zoli> > because zoli> > zoli> > there's a lack of action lines in the test: target it its zoli> > Makefile, zoli> > zoli> > and mms isn't too happy about that...) zoli> zoli> > That's tough, unfortunately... I've only access to a V8.4 cluster zoli> > (Alpha and IA64), so I don't know how to help you further. Of course, zoli> > there's the option to build perl from source, which isn't very hard at zoli> > all (I've done so a few times). zoli> zoli> I do have access to VAX, Alpha and IA64 architectures... on range of zoli> 7.3 to 8.3 OpenVMS versions. zoli> Also I do have functional perl installed on them. zoli> I am not the problem here, but ordinary developers that work on an old zoli> system developing for a legacy program and do not have SYSTEM rights - zoli> what is the common case. zoli> The build solution should be designed to be usable by those developers zoli> too. Is perl still that uncommon on VMS? I'm sorry to say that's gonna be tough, then. Just as an example, the old test scripts are gone, and have been replaced with Test::More / Test::Harness recipes, and I'm pretty sure VMS devs who're building OpenSSL are just as eager to run the test scripts as anyone. I could argue that for a developer to work, he/she needs a functional development environment. In this day and age, that should include perl. Pressure on the sysadmin! (having been a VMS sysadmin, I'm saying that very much toungue in cheak ;-)) zoli> > Well, the aim is to have a common structure to build from on all zoli> > architectures we claim to support. You've seen for yourself how the zoli> > scripts for VMS builds were lagging behind, and quite frankly, it's zoli> > hellish to keep them up to date (I've completely dropped the ball for zoli> > 1.1). That's not something I'm willing to have us do all over again. zoli> zoli> Absolutely agree with you. This is the way forward. Good :-) zoli> May I ask you, if the new build will cover the long names issue ( zoli> symhacks.h ) too? It's been pointed out to me by the vms-ports folks that it should be possible to solve using the compiler's "#pragma names shortened" rather than maintaining symhacks... Then, it's just a matter of doing the same thing manually when producing the SYMBOL_VECTOR for a shareable image. I'm also thinking that "#pragma names as_is" should be norm and that we could produce upper case aliases in SYMBOL_VECTOR (you know how that's done, right?). Does that sound like a way forward to you? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev