>>Both pa-risc and ia64 linkers look for both .so and .sl and once program >>is linked with some shared object it will require that particular one. >>And at run-time shared object extension has no meaning whatsoever, it's >>the contents matching ABI for current process, which determines if any >>particular file is successfully loaded to address space. > > True. But this creates problem when compiling on one host, and distributing > the binaries into other hosts.
I can't imagine any problems at binary distribution stage... Once again, once application is linked with any particular shared object it will require object with the same name without regard to extention. If you managed to distribute e.g. pa-risc shared object with ia64 application, extensions are hardly ones to blame... >>Can you present evidence that it's not [in OpenSSL context]? A. > > I discovered this problem because some of our hppa binaries had been > distributed to our ia64 binaries, which also had ia64 openssl > libraries with .sl extentions. Well, take it to the next step. HPUX supports two IA-64 ABIs: 32- and 64-bit ones. Both would have same extenstion and application would stop working if you try to link with mismatching object at run-time in exactly same way... I mean it looks like your procedures assume type of shared object solely by extension and it's not actually fool-proof... In other words I'm still not convinced that changing to .so would actually solve any problem. And I mean *actually* *solve* problem*s*, not just linger some particular one... > These libraries were used instead of > the correct hppa libraries, and the binaries broke. (This is a long > time ago, so I do not remember the details.) The whole point with stable branch is that one is reluctant to make cosmetic changes to it. Or rather changes which were believed to be cosmetic so far, which is why I asked for evidence... Essentially the matter is not really an issue. It's just that the reason why the ticket was [attempted to be] resolved now is that we're scheduling 0.9.7f release and it's more about bad timing than real technical problem. I'll see what I can do prior 0.9.7f, but I can't make any promises... Cheers. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
