php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #7003 configure not setting -L for extras (like png, tiff, etc.)
Submitted: 2000-10-04 01:15 UTC Modified: 2000-11-29 04:18 UTC
From: swenson at heronetwork dot com Assigned:
Status: Closed Package: Compile Failure
PHP Version: 4.0.2 OS: OpenBSD 2.7 & SuSE
Private report: No CVE-ID: None
 [2000-10-04 01:15 UTC] swenson at heronetwork dot com
After unpacking the distribution running ./configure with any of these options:
 --with-png-dir[=DIR]
 --with-tiff-dir[=DIR]
 --with-mm[=DIR]

The configure script is failing to find libgd, libpng, etc. After examining the configure script and the config.log I found that for these options:
 --with-ds-dir[=DIR]
 --with-jpeg-dir[=DIR]

The $LIBS variable is getting properly set to "-L[DIR] -l<option>". But, for the above options (and a few more I think) the $LIBS variable is only getting set to "-l<option>". So when configure attempts to confirm the option is present it 'ld' can not find the library and the option is not activated.

The easiest work around is to copy the apropriate libs into /usr/lib temporarily for the compile. Another work around is to edit the configure script and find all the places '[=DIR]' is not getting included and adding the '-L' option to the $LIBS variable.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-10-05 00:02 UTC] sr@php.net
Did you use --with-gd(=...)?

There was a problem in the configure script if you used the "default" gd configure, i.e. didn't say --with-gd.

Please try the latest CVS (or snapshot available from http://snaps.php.net/ ) and give us feedback, if the bug still exists.

 [2000-10-05 00:33 UTC] swenson at heronetwork dot com
You are correct. I was only using '--with-gd'. After changing the OpenBSD's /usr/ports/www/php4/Makefile to also use '--with-gd=${PREFIX}' the conifiguration then correctly found all the libraries for png & tiff.

I have not tried the latest CVS archive for the OpenBSD install since the patch files etc are pretty specific to the version in the ftp controls. In this case the php-4.0.2.tar.gz archive.
 [2000-10-05 00:49 UTC] sr@php.net
Hmm, the bug which was fixed should only occur if you don't say --with-gd at all (gd is (still) enabled by default), so maybe it's another one.

Can you test the latest snapshot (only download and copy the configure line from your Makefile and try that, you don't need to apply any OpenBSD patches (or even compile the thing ;-) ) )? 4.0.3 should be released very soon, so maybe it is possible to fix this bug (if it isn't already fixed) before the release.

Thank you.

 [2000-10-05 02:40 UTC] swenson at heronetwork dot com
Alright, I downloaded the latest CVS tarball and tried this:

PREFIX=/usr/local ./configure --with-apxs=/usr/sbin/apxs \
--with-config-file-path=/var/http/conf \
--enable-calendar \
--with-xml \
--enable-track-vars \
--with-regex=php \
--with-mm \
--with-zlib \
--with-gd \
--with-t1lib=${PREFIX} \
--with-jpeg-dir=${PREFIX} \
--with-png-dir=${PREFIX} \
--with-tiff-dir=${PREFIX} \
--with-ttf=${PREFIX} \
--with-xpm
[...]
checking for gdImageString16 in -lgd... no
checking for gdImagePaletteCopy in -lgd... no
checking for gdImageColorClosestHWB in -lgd... no
checking for compress in -lz... no
checking for png_info_init in -lpng... no
checking for gdImageColorResolve in -lgd... no
checking for gdImageCreateFromPng in -lgd... no
checking for gdImageCreateFromGif in -lgd... no
checking for gdImageCreateFromXbm in -lgd... no
checking for gdImageWBMP in -lgd... no
checking for libjpeg (needed by gd-1.8+)... yes
checking for jpeg_read_header in -ljpeg... no
no
checking for gdImageCreateFromJpeg in -lgd... no
checking for libXpm (needed by gd-1.8+)... no
checking for libXpm (needed by gd-1.8+)... no
configure: warning: If configure fails try --with-xpm-dir=<DIR>
checking for gdImageCreateFromXpm in -lgd... no

Also tried:
./configure \
--with-gd \
--with-t1lib \
--with-jpeg-dir \
--with-png-dir \
--with-tiff-dir \
--with-ttf \
--with-xpm
[...]
checking for gdImageString16 in -lgd... no
checking for gdImagePaletteCopy in -lgd... no
checking for gdImageColorClosestHWB in -lgd... no
checking for compress in -lz... no
checking for png_info_init in -lpng... no
checking for gdImageColorResolve in -lgd... no
checking for gdImageCreateFromPng in -lgd... no
checking for gdImageCreateFromGif in -lgd... no
checking for gdImageCreateFromXbm in -lgd... no
checking for gdImageWBMP in -lgd... no
checking for libjpeg (needed by gd-1.8+)... yes
checking for jpeg_read_header in -ljpeg... yes
checking for gdImageCreateFromJpeg in -lgd... yes
checking for libXpm (needed by gd-1.8+)... no
configure: warning: If configure fails try --with-xpm-dir=<DIR>
checking for gdImageCreateFromXpm in -lgd... yes
checking whether to include ttf support... yes
checking for T1lib support... checking for T1_GetExtend in -lt1... yes
yes

Also tried:
./configure \
--with-gd
[...]
checking for gdImageColorResolve in -lgd... no
checking for gdImageCreateFromPng in -lgd... no
checking for gdImageCreateFromGif in -lgd... no
checking for gdImageCreateFromXbm in -lgd... no
checking for gdImageWBMP in -lgd... no
checking for libjpeg (needed by gd-1.8+)... no
configure: warning: If configure fails try --with-jpeg-dir=<DIR>
checking for gdImageCreateFromJpeg in -lgd... no
checking for libXpm (needed by gd-1.8+)... no
configure: warning: If configure fails try --with-xpm-dir=<DIR>
checking for gdImageCreateFromXpm in -lgd... no
checking whether to include ttf support... yes
checking for T1lib support... no

./configure \
--with-gd=/usr/local
[...]
checking for gdImageString16 in -lgd... yes
checking for compress in -lz... yes
checking for png_info_init in -lpng... yes
checking for gdImageColorResolve in -lgd... yes
checking for gdImageCreateFromPng in -lgd... yes
checking for gdImageCreateFromGif in -lgd... no
checking for gdImageCreateFromXbm in -lgd... yes
checking for gdImageWBMP in -lgd... yes
checking for libjpeg (needed by gd-1.8+)... no
configure: warning: If configure fails try --with-jpeg-dir=<DIR>
checking for gdImageCreateFromJpeg in -lgd... yes
checking for libXpm (needed by gd-1.8+)... no
configure: warning: If configure fails try --with-xpm-dir=<DIR>
checking for gdImageCreateFromXpm in -lgd... yes
checking whether to include ttf support... yes
checking for T1lib support... no

It appears that the only way to get everthing in correctly is to include a /usr/local dir option on all of the graphics features AND to include --with-gd=/usr/local
 [2000-10-05 02:53 UTC] sr@php.net
But this variant seems ok, because if you install everything into /usr/local, you need to use the --with-xx=DIR options to tell configure, where you installed it. I think that's the expected use of these options.

Please reopen the bug report if I didn't unsterstand you right and something doesn't work.
 [2000-10-05 04:02 UTC] swenson at heronetwork dot com
I am reopening this for only a quick item.

I have found that on a majority of other configure based packages requesting a feature using the --with-XX option causes a check in the "normal install locations" which is one of: '/usr', '/usr/local', '/'. In that order. The --with-XX=DIR is used for 'other locations' or OSs which are a bit off. People with those types of systems are aware of it and understandably are use to having to descibe the installed locations.

I suggest that you consider adjusting php's configure script to be a little more adaptive in the spirit of 'easing installation woes'.

Thats it. At least this bug report is now in the system so others can search it out as I tried to. :^)
 [2000-11-29 04:18 UTC] sniper@php.net
Every --with-* option checks those default 
locations now. If some extension does not,
please open a new bug report for each.
(with correct 'Type' )

--Jani
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved.
Last updated: Sat Oct 10 22:00:02 2026 UTC