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]
