In building libcurl, version 7.18.1, on Solaris 10 with the Studio 12 compilers, the build fails when the linker tries to find the ssl libraries. I have established that this is because the scripts put the -L and -R flags in the wrong place, too late on the command line and in the wrong order for the linker. This causes the linker to not be able to find the compile time libraries and therefore fails to find the ssl libraries.
I have been able to manually workaround this problem:
I changed into the lib directory and corrected the positions of the -L and -R flags in the call to libtool where the linking fails and manually ran the call. The call to libtool and the following link then succeeds, however this still has errors, which are revealed only later on when trying to complete the build from the main directory. The linking which libtool makes is also wrong as it too puts the -L and -R flags in the wrong place. Again in the lib directory, a correction and manually running the linker, archiver and ranlib, then returning to the parent directory and rerunning make successfully completes the build.
I am attaching a file with the complete build history. From Line 723 onwards is where you can see what this problem does, and in the following lines how I have worked around it.
text file containing complete build history
Logged In: YES
user_id=1110
Originator: NO
Can you please try a recent daily snapshot? http://cool.haxx.se/curl-daily/
I believe this is an automake 1.10 bug and the snapshots are made with an older automake than I used when I did the release package.
Logged In: YES
user_id=1590006
Originator: NO
Ian Ball wrote:
> I have established that this is because the scripts put the -L and
> -R flags in the wrong place, too late on the command line and in the
> wrong order for the linker.
Your libcurl_build_history file shows that before libcurl's configure script is called environment vars LDFLAGS and LDFLAGS are defined and have the following values:
LDFLAGS=-L/usr/local/open-ldap/lib -L/usr/local/openssl/lib -L/opt/sfw/lib -L/usr/sfw/lib -L/usr/lib -R/usr/local/open-ldap/lib -R/usr/local/openssl/lib -R/opt/sfw/lib -R/usr/sfw/lib -R/usr/lib
CPPFLAGS=-I/usr/local/open-ldap/include -I/usr/local/openssl/include -I/opt/sfw/include -I/usr/sfw/include -I/usr/include
User is supposed to be allways right, so don't be surprised when libcurl's configure script uses the already defined LDFLAGS and CPPFLAGS.
Clear out (unset) LDFLAGS and CPPFLAGS before calling libcurl's configure script. And then run configure simply in the following way:
./configure --prefix=/usr/local/curl-7.18.1 --with-ssl=/usr/local/openssl
Logged In: YES
user_id=1234316
Originator: YES
Ok, took the daily snapshot from 18 April, and it builds without any problems. It looks like your suspicion of a libtool problem is correct. A history of the build is attached.
Regarding your comments about the -L and -R flags, this is the correct way to build software on Solaris, it needs these in order to compile and to execute successfully, otherwise it cant find any of it's includes or libraries. Many people mistakenly believe that they should use the LD_LIBRARY_PATH environment variable, however this is only intended for short testing, not for a productive system. The ld.so.conf file on Linux is nothing more than a formalisation of the LD_LIBRARY_PATH, which, depending on your point of view, is either a good or bad thing.
File Added: libcurl_build_history2
build history (successful) from 18 April snapshot
Logged In: YES
user_id=1110
Originator: NO
Have you considered writing up a bug report to the automake project about this? The only thing we can do about this in this project is to revert back to using 1.9.6 in the upcoming releases... :-/
Anyway, I've reverted this on my primary release build machine now so the case is closed here until next time I try to upgrade this!