Hi, cURL uses --prefix to find the include files as well and assumes that the libraries are in <prefixdir>/lib. Till now, cURL has a possibility to say where the library reside (with LDFLAGS environment variable). The problem is (but I'm not 100% sure) that the pkgconfig dir is also not in a fixed place. If the pkgconfig dir is always under <prefixdir>/lib (I don't know whether this is possible), some problems may be solved. You may like to check some more details of the problem at: https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3029420&group_id=976
I don't know whether it helps if you and Daniel Stenberg talk together... Regards, Kees -----Original Message----- From: Andy Polyakov via RT [mailto:[email protected]] Sent: Thursday, 15 July, 2010 16:33 To: Kees Dekker Cc: [email protected] Subject: Re: [openssl.org #2307] building cURL with OpenSSL 1.0.0a on 64-bit Unix flavors is almost impossible 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 Yes, this is result of ongoing attempt to make openssl "multilib"-aware. Admittedly it was inappropriate to assume that it would work for arbitrary prefix. I'd suggest to refine logic to see if target "multilib" location actually exists and if it doesn't, then suffix would be omitted. I mean if you configure with --prefix=/usr, i.e. where linker does look for 64-bit libs in designated directories, then "multilib" suffix will be used. And should you choose another --prefix, it will be omitted. Does it make more sense? A.
