On Sat, Dec 08, 2001 at 12:43:54AM -0000, [EMAIL PROTECTED] 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
