php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #9571 Undefined symbols in apache build using PHP 4.0.4pl1
Submitted: 2001-03-06 00:43 UTC Modified: 2001-05-24 09:03 UTC
From: jcb at best dot com Assigned:
Status: Closed Package: ODBC related
PHP Version: 4.0.4pl1 OS: Solaris 8 Sparc
Private report: No CVE-ID: None
View Developer Edit
 [2001-03-06 00:43 UTC] jcb at best dot com 
Same problem as in Bug #9161 - Undefined Symbol errors.

./configure --with-mysql=/export/db/mysql --with-apache=/export/home/temp/apache_1.3.14 --with-pgsql=/export/
home/app/pgsql --with-openlink --with-dom=shared,/usr/local --with-zlib=/usr/local --with-gd --with-tiff-dir=/usr/local --with-jpeg-dir=/usr/local --with-pdflib=/usr/local --with-ttf=shared,/usr/local
 --enable-debug --enable-magic-quotes --enable-libgcc --enable-calendar --enable-ftp --enable-gd-imgstrttf --
enable-track-vars

First was getting errors like:

Undefined                          First referenced
  symbol                            in file
some_png_symbol                   modules/php4/libphp4.a(libpng.o)

 adding --with-gd=shared,/usr/local got past it, but then

isinf                    modules/php4/libphp4.a(mod_php4.o)

 after several clean make, clean installs, finally went into config.cache and set isinf to 'no'.  Clean make, clean install of PHP, reconfig apache with --activate-module, make and she finally built and started right up.

Seems to be some issue with the shared libs.... also maybe smells like Solaris not having ldconfig....?

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-03-06 06:21 UTC] sniper@php.net 
Please try the latest CVS snapshot from http://snaps.php.net/

--Jani
 [2001-03-07 11:54 UTC] jcb at best dot com 
Many thanks, that did it.  4.0.5 Dev built with:

./configure --with-mysql=/export/db/mysql --with-apache=/export/home/temp/apache_1.3.14 --with-pgsql=/export/home/app/pgsql --with-openlink --with-dom=/usr/local --with-zlib-dir=/usr/local --with-gd=/usr/local --with-xpm-dir=/usr/local --with-t1lib=/usr/local --with-tiff-dir=/usr/local --with-png-dir=/usr/local --with-jpeg-dir=/usr/local --with-pdflib=/usr/local --with-ttf=/usr/local --enable-debug --enable-magic-quotes --enable-libgcc --enable-calendar --enable-ftp --enable-gd-imgstrttf --enable-gd-native-ttf --enable-trans-sid --enable-shmop --enable-track-vars

Note that v.4 of the Openlink dirver manager no longer uses (or includes with the distribution) the file iodbc.h.  This file has been replaced with sqltypes.h (located in <openlink_install_dir>/odbcsdk/include).  The file php_odbc.h includes iodbc.h at or about line 128, so the build fails.  The solution is to remove the reference to iodbc.h.  The file sqltypes.h is included within sql.h, which is included within isql.h, which is included at line 129 of php_odbc.h.  Placing iodbc.h (from a previous installation, say) into the include directory breaks the build with type definition errors.
 [2001-03-16 19:48 UTC] sniper@php.net 
Reclassified.
 [2001-04-16 22:34 UTC] kalowsky@php.net 
can we get one of the OpenLink people to comment on this please?
 [2001-05-04 15:08 UTC] ahill@php.net 
This is true.  To follow the standard more closely we have removed some files and standardized the iODBC Driver Manager SDK.  

The current SDK is contained here:
ftp://www.openlinksw.com/open40/l2kozzzz.taz

I did not find that the compile fails however.  One reason is probably because using --with-openlink is no longer the recommended option.  

Using --with-iodbc should work in all cases.
 [2001-05-24 09:03 UTC] kalowsky@php.net 
no feedback from user.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon May 05 21:01:29 2025 UTC