You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Aaron Bannert <aa...@clove.org> on 2001/12/08 02:17:01 UTC
Re: cvs commit: apr-util STATUS
On Sat, Dec 08, 2001 at 12:43:54AM -0000, jerenkrantz@apache.org wrote:
> jerenkrantz 01/12/07 16:43:54
>
> Modified: . STATUS
> Log:
> Grumble, grumble. One problem fixed, another created.
...
> - * Try doing --with-dbm=db2 when you have db3 available. No go.
> - Justin says: We'll probably need to add logic to check first
> - in db2/db.h when we want db2 and db3/db.h for db3.
> - Only fallback to db.h when the above don't exist
> - in the include path.
> -
> + * Solaris's Sun Freeware (sfw) package has a busted gcc/ld setup.
> + This gcc passes -L/opt/sfw/lib to /usr/ccs/bin/ld, but does not
> + pass -R. Therefore, when trying to run the code using a
> + library from /opt/sfw/lib (say, libdb), the run-time linker
> + will not look in /opt/sfw/lib and the program will die.
> + Status: Workaround is to add "-R/opt/sfw/lib" to LDFLAGS.
> + Should check latest sfw package set and see if Sun
> + may have fixed this.
I have the 7/01 release of the Companion CD installed and I have this
problem. You'll recall recent problems with gcc+solaris-ld recently
reported on this and other lists (by me). This is the same problem.
Libtool 1.4.2 detects but does not correct this problem.
The biggest problem for me is that gcc looks in /opt/sfw/include
and /opt/sfw/lib. Autoconf implements AC_CHECK_LIB for me like this:
configure:2562: gcc -o conftest -Wall -g -Wall -g conftest.c -ldb 1>&5
(gcc is calling /usr/ccs/bin/ld internally, but with some extra -I/-L paths.)
OTOH, libtool calls ld directly with the "libtool --mode=link" command,
and of course ld knows nothing about /opt/sfw/bin, so libdb is detected
by autoconf but unable to be linked by libtool.
I'd like to figure out a way to convince libtool to always use gcc for
linking, and not ld, but setting LD doesn't seem to work.
-aaron