You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by je...@apache.org on 2001/12/08 01:43:54 UTC
cvs commit: apr-util STATUS
jerenkrantz 01/12/07 16:43:54
Modified: . STATUS
Log:
Grumble, grumble. One problem fixed, another created.
Revision Changes Path
1.35 +9 -7 apr-util/STATUS
Index: STATUS
===================================================================
RCS file: /home/cvs/apr-util/STATUS,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- STATUS 2001/11/29 10:25:27 1.34
+++ STATUS 2001/12/08 00:43:54 1.35
@@ -1,5 +1,5 @@
APRUTIL LIBRARY STATUS: -*-text-*-
-Last modified at [$Date: 2001/11/29 10:25:27 $]
+Last modified at [$Date: 2001/12/08 00:43:54 $]
Release:
2.0a9 : released December 12, 2000
@@ -22,12 +22,14 @@
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
- * 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.
Other bugs that need fixing:
Re: cvs commit: apr-util STATUS
Posted by Aaron Bannert <aa...@clove.org>.
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