From nobody@FreeBSD.ORG Tue Jul 20 11:33:10 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id D4E7A14D7C; Tue, 20 Jul 1999 11:33:10 -0700 (PDT)
Message-Id: <19990720183310.D4E7A14D7C@hub.freebsd.org>
Date: Tue, 20 Jul 1999 11:33:10 -0700 (PDT)
From: mistwolf@mushhaven.net
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: gdbm (And possibly other libraries in /usr/local/lib) not usable under 3.*
X-Send-Pr-Version: www-1.0

>Number:         12720
>Category:       misc
>Synopsis:       gdbm (And possibly other libraries in /usr/local/lib) not usable under 3.*
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 20 11:40:01 PDT 1999
>Closed-Date:    Mon Mar 12 19:57:24 PST 2001
>Last-Modified:  Mon Mar 12 19:57:47 PST 2001
>Originator:     Jamie Norwood
>Release:        3.2-RELEASE
>Organization:
>Environment:
FreeBSD diarmadhi.mushhaven.net 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Fri Jul  9 09:10:44 PDT 1999     root@:/usr/src/sys/compile/DIARMADHI  i386

>Description:
After either installing by the port or by hand the GDBM ports, nothing
is able to use them using -lgdmb, nor does setting LD_LIBRARY_PATH to
include /usr/local/lib allow it. The only way I have found to get it
to be seen is to use -L/usr/local/lib when compiling. This breaks any
GNU configure script looking for things.

First off, after installing, the only libraries that are seen in ldconfig
are ones with only one version letter. IE, libreadline.so.4 is seen, but
libreadline.so.4.0 is not (Symlinks /seem/ to work, but most packages do
not make that link).

However, even with the symlink, which gets these libraries to show in 
ldconfig, -l<library> does /not/ work, nor can configure scripts see them.

2.2.8 works fine with these libraries; I have not tried on 4.x. I have 
set the severity and priority to the top because this appears to be
broken for any library, please adjust as needed. To me they are doubly
critical as the machine I run this on is for hosting MU*s that rely
heavily on GDBM. I've wrestled with this for months, and unless I can
get it fixed, will have to either downgrade to 2.2.8 or else move
to a Linux or Solaris platform, which I do not want to do.

>How-To-Repeat:
Install gdbm, then try linking against it. Try also any configure script
from a package that looks for gdbm. 
For example:

http://www.mushhaven.net/~mistwolf/tinymush-unoff1.tgz
>Fix:


>Release-Note:
>Audit-Trail:

From: Jason Young <jyoung@accessus.net>
To: freebsd-gnats-submit@freebsd.org, mistwolf@mushhaven.net
Cc:  
Subject: Re: misc/12720: gdbm (And possibly other libraries in /usr/local/lib) 
 not usable under 3.*
Date: Sun, 01 Aug 1999 23:51:41 -0500

 gdbm 1.7.3 under 3.2-RELEASE didn't build or install ELF libraries. I
 had trouble with this myself. The port is now based on gdbm 1.8.0
 (upgrade request in PR 11811). This was done at or around 6/6/99. This
 PR is most likely now closeable unless the submitter still sees a
 problem.
 

From: Chris Piazza <cpiazza@home.net>
To: freebsd-gnats-submit@freebsd.org, mistwolf@mushhaven.net
Cc:  
Subject: Re: misc/12720: gdbm (And possibly other libraries in /usr/local/lib) not usable under 3.*
Date: Sun, 1 Aug 1999 23:09:11 -0700

 This is not a problem with the port or package of gdbm, it is a problem
 with the configure scripts.  Here's a fancy fix:
 
 % env LDFLAGS="-L/usr/local/lib" ./configure
 [..]
 checking for dbm_close in -lgdbm... yes
 checking for main in -lresolv... no
 checking for getpwnam in -lsun... no
 checking for main in -lseq... no
 checking for main in -lintl... yes
 
 Conclusion:
 It's not the gdbm port's problem that these configure scripts don't
 check /usr/local/lib.  I'll close this PR if you don't object.
 
 -Chris
 
 -- 
 cpiazza@home.net              cpiazza@FreeBSD.org
 "I don't like principles.  I prefer prejudices."
                                      -Oscar Wilde
 
State-Changed-From-To: open->feedback  
State-Changed-By: cpiazza 
State-Changed-When: Sun Aug 1 23:12:28 PDT 1999 
State-Changed-Why:  
Waiting to see if explanation given is accepted 

From: Jamie Norwood <mistwolf@mushhaven.net>
To: Chris Piazza <cpiazza@home.net>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: misc/12720: gdbm (And possibly other libraries in /usr/local/lib) not usable under 3.*
Date: Sun, 1 Aug 1999 23:15:04 -0700

 Compiling things at the command line with -lgdbm should, as it did in 2.2.8,
 work. The /only/ way to use gdbm is using the -L flags. Maybe I am missing
 something important here, but given that /usr/local/lib is in the ldconfig
 information, it should be probed with a standard -l and not need a -L. I
 could be wrong, I am new to programming, but this is how it worked in 2.2.8,
 and how it works under Linux and Solaris...
 
 Jamie
 
 
 On Sun, Aug 01, 1999 at 11:09:11PM -0700, Chris Piazza wrote:
 > This is not a problem with the port or package of gdbm, it is a problem
 > with the configure scripts.  Here's a fancy fix:
 > 
 > % env LDFLAGS="-L/usr/local/lib" ./configure
 > [..]
 > checking for dbm_close in -lgdbm... yes
 > checking for main in -lresolv... no
 > checking for getpwnam in -lsun... no
 > checking for main in -lseq... no
 > checking for main in -lintl... yes
 > 
 > Conclusion:
 > It's not the gdbm port's problem that these configure scripts don't
 > check /usr/local/lib.  I'll close this PR if you don't object.
 > 
 > -Chris
 > 
 > -- 
 > cpiazza@home.net              cpiazza@FreeBSD.org
 > "I don't like principles.  I prefer prejudices."
 >                                      -Oscar Wilde
 

From: Jamie Norwood <mistwolf@mushhaven.net>
To: Chris Piazza <cpiazza@home.net>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: misc/12720: gdbm (And possibly other libraries in /usr/local/lib) not usable under 3.*
Date: Sat, 7 Aug 1999 21:28:26 -0700

 On Sun, Aug 01, 1999 at 11:09:11PM -0700, Chris Piazza wrote:
 > This is not a problem with the port or package of gdbm, it is a problem
 > with the configure scripts.  Here's a fancy fix:
 > 
 > % env LDFLAGS="-L/usr/local/lib" ./configure
 > [..]
 > checking for dbm_close in -lgdbm... yes
 > checking for main in -lresolv... no
 > checking for getpwnam in -lsun... no
 > checking for main in -lseq... no
 > checking for main in -lintl... yes
 > 
 > Conclusion:
 > It's not the gdbm port's problem that these configure scripts don't
 > check /usr/local/lib.  I'll close this PR if you don't object.
 > 
 > -Chris
 > 
 > -- 
 > cpiazza@home.net              cpiazza@FreeBSD.org
 > "I don't like principles.  I prefer prejudices."
 >                                      -Oscar Wilde
 
 As a follow up, below is a 'script' output of this. Even using the above        
 'fix' doesn't work; the configure script runs, but the subsequent 'gmake'       
 fails when trying to link using -lgdbm. This is /not/ a problem with the
 configure scripts. I am about to reinstall to Linux because I cannot run        
 the server I run with these breakages.                                          
 
 Orignally, I just send the above to Chris, resending now so it gets in the 
 list. Also, as a test, I forced gdbm to install in /usr instead of 
 /usr/local, and lo and behold, it worked flawlessly. To recap, this is NOT
 a problem with configure, it is a problem with how FreeBSD handles the files
 installed in /usr/local/lib. This is very, very recreateable and should
 be fixed; I don't know about anyone else, but it certainly seems like 
 a major bug to me when libraries that are correctly installed are not being
 read at all!
 
 Jamie
 
 

From: Chris Piazza <cpiazza@home.net>
To: Jamie Norwood <mistwolf@mushhaven.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/12720: gdbm (And possibly other libraries in /usr/local/lib) not usable under 3.*
Date: Sat, 7 Aug 1999 22:01:14 -0700

 On Sat, Aug 07, 1999 at 09:30:02PM -0700, Jamie Norwood wrote:
 >  
 >  As a follow up, below is a 'script' output of this. Even using the above 
 >  'fix' doesn't work; the configure script runs, but the subsequent 'gmake'
 >  fails when trying to link using -lgdbm. This is /not/ a problem with the
 >  configure scripts. I am about to reinstall to Linux because I cannot run
 >  the server I run with these breakages.
 >  
 >  Orignally, I just send the above to Chris, resending now so it gets in the 
 >  list. Also, as a test, I forced gdbm to install in /usr instead of 
 >  /usr/local, and lo and behold, it worked flawlessly. To recap, this is NOT
 >  a problem with configure, it is a problem with how FreeBSD handles the files
 >  installed in /usr/local/lib. This is very, very recreateable and should
 >  be fixed; I don't know about anyone else, but it certainly seems like 
 >  a major bug to me when libraries that are correctly installed are not being
 >  read at all!
 
 OK.  I think I actually understand what you want now.  You want to not
 have to specify -L/usr/local/lib to gcc to search in that directory
 for libraries.  If this is not happening (IMO) it's a bug in the Makefiles
 and configure scripts of said programs, not FreeBSD.
 
 -Chris
 -- 
 cpiazza@home.net              cpiazza@FreeBSD.org
 "It's better to be quotable than to be honest."
                                    --Tom Stoppard
 
State-Changed-From-To: feedback->closed 
State-Changed-By: des 
State-Changed-When: Mon Mar 12 19:57:24 PST 2001 
State-Changed-Why:  
Not a bug; should have been closed a long time ago. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=12720 
>Unformatted:
