Bug 12720

Summary:	gdbm (And possibly other libraries in /usr/local/lib) not usable under 3.*
Product:	Base System	Reporter:	mistwolf <mistwolf>
Component:	misc	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	3.2-RELEASE
Hardware:	Any
OS:	Any

Description mistwolf 1999-07-20 19:40:01 UTC

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

Comment 1 jyoung 1999-08-02 05:51:41 UTC

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.

Comment 2 cpiazza 1999-08-02 07:09:11 UTC

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

Comment 3 cpiazza freebsd_committer

1999-08-02 07:12:28 UTC

State Changed
From-To: open->feedback

Waiting to see if explanation given is accepted

Comment 4 mistwolf 1999-08-02 07:15:04 UTC

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

Comment 5 mistwolf 1999-08-08 05:28:26 UTC

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

Comment 6 cpiazza 1999-08-08 06:01:14 UTC

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

Comment 7 Dag-Erling Smørgrav freebsd_committer

2001-03-13 03:57:24 UTC

State Changed
From-To: feedback->closed

Not a bug; should have been closed a long time ago.