In message <[EMAIL PROTECTED]> on Fri, 13 Dec 2002 14:45:15 +0100, Andy Polyakov <[EMAIL PROTECTED]> said:
appro> > Let me rephrase that: I haven't seen a compiler the requires "-.pic" appro> > and can't take "-.PIC". appro> appro> So that your suggestion is basically to change all -.pic to -.PIC in appro> ./Configure. That is also a way... Ah, hadn't looked in Configure. No, I don't think that's a good idea, unless you know for sure that there will be no bad impact. appro> > That will however be something for 0.9.8. There's been some requests appro> > for production of both 32- and 64-bit variants as well, so I'm appro> > thinking of introducing the possibility of building library variants. appro> appro> What is more important to fix *first* is dual-ABI header files. I mean appro> the first "milestone" in the "grand plan" should be same header files appro> providing for all ABIs supported by target OS. In my opinion that is:-) I can agree with that. How complicated is that? I know that for 64bit Windows, the biggest issue is that don't have proper size_t handling (we make a horrible mix between that and unsigned int). On VMS, it's more a decision between using 32- and 64-bit routines for certain operations, and that's not a header problem... I've no idea what the impact would be on Unixen. appro> > That will also require that we have separate build directories and so appro> > on, so that's a rather large job. appro> appro> I myself would actually be reluctant to strive for building all possible appro> combinations (matrix of supported ABI and static/dynamic combinations) appro> in so to say one move and by default. I'd rather document how to achieve appro> any particular result and leave the rest to binary package/OS appro> distribution builders/maintainers. After all it's them who has better appro> understanding of where does run-time linker look for ABI-specific appro> components, etc. I mean idea is basically that we stand for headers, appro> implementation and documentation and they stand for ABI selection and appro> for dealing with linker. When it comes to single user deploying OpenSSL appro> application in some particular application, then [s]he would surely have appro> less trouble dealing with a single ABI chosen at ./config time. Every appro> single thing doesn't have to be more complicated then it really has to. Good point. I'll ponder over that. appro> But I'd rather leave this discussion for next year:-) Really... A. OK :-). -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See <http://www.stacken.kth.se/~levitte/mail/> for more info. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]