> appro> Should we check for "-.pic" also? > > I haven't seen any compiler with such a flag, yet...
??? What do you mean? All compilers support both -.PIC and -.pic! Or do you mean that you have interpreted . literally? I ment . as an arbitrary character in regular expression and is it was depicted in awk command line... To be certain we take one step back then. All compilers [capable of generating position independent code] support either -fpic and -fPIC or -Kpic and -KPIC. PIC and pic are different only on *some* platforms where they denote how large offsets are permitted. It should be noted however that "pic times" [narrow offsets] are long gone as modern programmers don't tend to care about memory footprint (nor do optimizers:-) so that you can *hardly* find an application that would actually survive in pic. You may wonder why are there a number of targets in ./Configure with pic then. Well, those are IA-32 targets which are not so to say "PIC/pic case sensitive." > appro> Finally ./Configure modifications. As proposed I omit CAST assembler > appro> module if shared build was requested. Then I add $shared_cflag to > appro> $cflags *only* if a shared build was actually requested. Till now > appro> $shared_cflags was added unconditionally which is not safe practice. > > There was a specific reason for that: there were people who would link > routines from libcrypto.a into another shared library. If the > libcrypto.a routines weren't built with -fPIC, it broke badly. Those people probably should have been instructed to explicitely './config shared' then. After all, when libcrypto.so.0.x is likned, libcrypto.a is still around, isn't it? So what's the problem? But what do you mean "broke badly?" It's perfectly possible to use non-PIC code in a shared library. It kind of obsoletes the idea, but it *does* work. What might be broken is linking stage [exactly what this very ticket is about!], but not the run-time. So what do we say? Conditional -.PIC as proposed or unconditional as it used to be? > appro> So that if user didn't ask for shared build, then we basically > appro> shouldn't pass -.PIC flag to compiler. Which also means that > appro> even if user asked for shared build, apps/openssl and tests are > appro> not compiled with -.PIC, but I don't touch this at this time. > > It also probably means that we should name libcrypto.a differently > when the included modules are compiled with -fPIC. Something like > libcrypto_pic.a. I've seen such practice elsewhere... Absolutely! A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
