Hi, I noticed that the output directories of any prefixed (--prefix) OpenSSL build for some Unix 64-bit flavors changed. In the past (at least with openSSL openssl-0.9.8k), after calling gmake install, the include files were in prefix/include, the libraries in prefix/lib. Due to the changed output structure of any prefixed OpenSSL build, libraries for non-32-bit builds may reside in: HPIA64: prefix/lib/hpux64 HPPArisc: prefix/lib/pa20_64 Linux: prefix/lib64 Solaris: prefix/lib/64
Unfortunatelly, there is no good method to pass these directories to cURL. Using cURL's --with-ssl=<path> is not possible, since cURL assumes all libraries to stay in <path>/lib, which is not true, as explained before. Also, when using the openSSL libraries, building a 64-bit application (on e.g. Solaris), by using cc -o <program> -L<curlprefixdir>/lib does not work if the 64-bit libraries are under <curlprefixdir>/lib/64. It is true that the compiler searches at default in /usr/lib/64 for 64-bit builds, but that's is (about the) only one. Users need to specify different link flags to be able to build cURL. In our case, we use isolated directory trees for build, but a common caller (Makefile) script. In that case, it would be useful, and consistent, to put static libraries/archives under <prefixdir>/lib in all cases (both 32-bit as well 64-bit). I did not see a note in the CHANGES file about this changed behavior. Is there a special reason to use different output directories for 64-bit Unix (some Operating systems)? Regards, Kees
Hi,
I noticed that the output directories of any prefixed (--prefix) OpenSSL build for some Unix 64-bit flavors changed.
In the past (at least with openSSL openssl-0.9.8k), after calling gmake install, the include files were in prefix/include, the libraries in prefix/lib.
Due to the changed output structure of any prefixed OpenSSL build, libraries for non-32-bit builds may reside in:
HPIA64: prefix/lib/hpux64
HPPArisc: prefix/lib/pa20_64
Linux: prefix/lib64
Solaris: prefix/lib/64
Unfortunatelly, there is no good method to pass these directories to cURL. Using cURL’s --with-ssl=<path> is not possible, since cURL assumes all libraries to stay in <path>/lib, which is not true, as explained before.
Also, when using the openSSL libraries, building a 64-bit application (on e.g. Solaris), by using cc -o <program> -L<curlprefixdir>/lib does not work if the 64-bit libraries are under <curlprefixdir>/lib/64. It is true that the compiler searches at default
in /usr/lib/64 for 64-bit builds, but that’s is (about the) only one. Users need to specify different link flags to be able to build cURL. In our case, we use isolated directory trees for build, but a common caller (Makefile) script. In that case, it would
be useful, and consistent, to put static libraries/archives under <prefixdir>/lib in all cases (both 32-bit as well 64-bit).
I did not see a note in the CHANGES file about this changed behavior. Is there a special reason to use different output directories for 64-bit Unix (some Operating systems)?
Regards,
Kees
