php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27847 deplibs_check_method is being defined as unknown and pgsql.so won't build
Submitted: 2004-04-02 18:32 UTC Modified: 2004-04-09 11:14 UTC
From: shorej at sktc dot net Assigned:
Status: Not a bug Package: PostgreSQL related
PHP Version: 4.3.6RC1 OS: Redhat 9
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: shorej at sktc dot net
New email:
PHP Version: OS:

 

 [2004-04-02 18:32 UTC] shorej at sktc dot net
Description:
------------
I gave 4.3.6rc1 a whirl today.  It sounded like it was fairly stable.  I compiled it with:

--prefix=/usr/local --with-pgsql=shared,/usr/local/pgsql --with-kerberos --with-imap --with-imap-ssl --with-openssl --
with-ldap --with-gd --with-zlib --with-apache=../../apache/apache_1.3.29

pgsql support was critical here.  I tried 3 different variants of --with-pgsql.  None of the times was pgsql.so built and installed.  Tech support for a company that we're buying a product from that requires PHP w/ pgsql support gave us a hand finding the problem.  One of the errors I was getting was:

*** Warning: inter-library dependencies are not known to be supported.
*** All declared inter-library dependencies are being dropped.

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module pgsql.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.
/bin/sh /usr/local/src/php/php-4.3.6RC1/libtool --silent --preserve-dup-deps --mode=install cp ext/pgsql/pgsql.la
/usr/local/src/php/php-4.3.6RC1/modules
PATH="$PATH:/sbin" ldconfig -n /usr/local/src/php/php-4.3.6RC1/modules

This tech support guy finally found that apparently $deplibs_check_method is being defined as "unknown" in libtool for whatever reason.  We decided to back off to 4.3.5 for grins and sure enough it configured, compiled, and instaled like a champ.  I started searching for why it was set to unknown in configure but could never figure enough of out what was going on there to be of any good.

Expected result:
----------------
I'd expect deplibs_check_method in 4.3.6rc1 to be detected and set the same as deplibs_check_method in 4.3.5.  It is the same box after all.  That seems to be the underlying problem as to why pgsql.so wasn't compiling.  

Actual result:
--------------
deplibs_check_method is defined as "unknown" and libtool refuses to build pgsql.so on 4.3.6rc1, but not 4.3.5.

I'm listing this under PostgreSQL even though I really don't think it has anything to do with this particular pgsql problem.  I think it's a configure script issue, not detecting something correctly in 4.3.6rc1.  pgsql 7.4.2 is compiled in a very standard manner and installed to the default /usr/local/pgsql base directory.  ld.so.conf of course has /usr/local/pgsql/lib in it and ldconfig has been run multiple times.

I can't think of anything else I could add to this report other than that even though this is techically a RH9 box, I've upgraded most every important library (except c) on this box and made the installation my own.  Most of the stupid RH9 hacks have been undone.

Looking back through the other posts with similar problems, it appears that libtool has been known to have issues in the past.  Could 4.3.6rc1 have brought out another one?

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-04-03 07:22 UTC] derick@php.net
I just had a look and the code inside configure between 4.3.5 and 4.3.6rc1 is 100% the same, we only have one additional check for something not related at all, and some changes in the line-number comments.

Can you put both config.log files (from 4.3.5 AND 4.3.6RC1) on line somewhere, and also please provide the FULL ./configure line (including any CFLAGS etc. you might have set before running it).
 [2004-04-08 13:58 UTC] shorej at sktc dot net
Sorry for the delay.  I've been swamped lately.

http://www.sktc.net/~shorej/4.3.5-config.log
./configure  --prefix=/usr/local --with-pgsql=shared,/usr/local/pgsql --with-kerberos --with-imap --with-imap-ssl --with-openssl --with-ldap --with-gd --with-zlib --with-apache=../../apache/apache_1.3.29


http://www.sktc.net/~shorej/4.3.6rc1-config.log
./configure  --prefix=/usr/local --with-pgsql=shared,/usr/local/pgsql --with-kerberos --with-imap --with-imap-ssl --with-openssl --with-ldap --with-gd --with-zlib --with-apache=../../apache/apache_1.3.29
 [2004-04-08 19:34 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

It looks like either you messed around with the configure yourself, defined some environment variables differently or your system is totally screwed.. please get the latest STABLE snapshot and just do this:

# ./configure --with-pgsql=shared,/usr/local/pgsql

And tell us whether you got a working pgsql.so or not..

 [2004-04-09 03:14 UTC] shorej at sktc dot net
php4-STABLE-200404090630 configured with the minimal ./configure options you requested compiled pgsql.so just fine.  I recompiled 4.3.6rc1 again both with the simplistic configure options and what I was trying before.  I haven't been able to recreate the problem on any of the 3 boxes that were (all) experiencing the same problem before.  None of these boxes have undergone any pertinent upgrades since before this bug report was submitted.  For some reason they aren't showing the things of the problem now.  I'm going to try again in the morning after getting some sleep.  Maybe I'm missing something.
 [2004-04-09 11:14 UTC] sniper@php.net
So it's some user error and NOT any bug in PHP -> bogus.

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 09 06:01:27 2024 UTC