Bugs item #1944825, was opened at 2008-04-17 13:52
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1944825&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: compile or build problem
Group: portability problem
>Status: Closed
>Resolution: Fixed
Priority: 6
Private: No
Submitted By: Ian Ball (ianball)
Assigned to: Daniel Stenberg (bagder)
Summary: Solaris 10 build fails, wrong -L and -R flag positions

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2008-04-25 00:49

Message:
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!

----------------------------------------------------------------------

Comment By: Ian Ball (ianball)
Date: 2008-04-18 16:19

Message:
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

----------------------------------------------------------------------

Comment By: Yang Tse (yangtse)
Date: 2008-04-18 02:14

Message:
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

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2008-04-17 22:53

Message:
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.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1944825&group_id=976
Received on 2008-04-25