PHP :: Bug #17944 :: ./configuring with GD and jpeg/png

Bug #17944	./configuring with GD and jpeg/png
Submitted:	2002-06-24 08:49 UTC	Modified:	2002-06-26 18:35 UTC
From:	potnoddle at hotmail dot com	Assigned:
Status:	Not a bug	Package:	GD related
PHP Version:	4.1.2	OS:	solaris 8
Private report:	No	CVE-ID:	None

View Developer Edit

[2002-06-24 08:49 UTC] potnoddle at hotmail dot com

i'm trying to bult php as a so module with GD to work on a solaris box.

using this 
"CC=Gcc ./configure --prefix=/usr/local/php --with-oci8=/usr/home/oracle/product/8.1.7/ --with-apxs=/usr/apache/bin/apxs --with-gd=/us
r/local/  --with-pear=/usr/local/pear --without-sapi --with-jpeg-dir=/usr/local"

i get this 
"configure: error: Problem with libjpeg.(a|so). Please check config.log for more information."
and config.log
says's this

configure:19561: checking for the location of libjpeg
configure:19610: checking for jpeg_read_header in -ljpeg
configure:19631: gcc -o conftest -g -O2  -D_POSIX_PTHREAD_SEMANTICS -DEAPI -DMOD_PERL -DUSE_EXPAT  -R/usr/ucblib -L/usr/ucblib -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3 -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3 conftest.c -ljpeg
      -L/usr/local/lib
     -lcrypt -lresolv -lresolv -lresolv -lm -ldl -lnsl -lsocket  -lsocket -lgcc -lcrypt 1>&5
ld: warning: file /usr/local/lib/libjpeg.a(jdapimin.o): wrong ELF class: ELFCLASS64
Undefined                       first referenced
 symbol                             in file
jpeg_read_header                    /var/tmp/ccWyMCNT.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure: failed program was:
#line 19620 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char jpeg_read_header();

int main() {
jpeg_read_header()
; return 0; }

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2002-06-24 08:59 UTC] sander@php.net

It seems your libjpeg is broken. Reinstall it. Also, try the latest version of PHP, I think lots has been changed since 4.1.x (even better: try a CVS version from http://snaps.php.net)

[2002-06-24 10:16 UTC] sniper@php.net

This should be fixed in PHP 4.2.1, so please try it first.

[2002-06-24 12:30 UTC] potnoddle at hotmail dot com

i've tryed the latest versions get more but only this

httpd starting.
Syntax error on line 236 of /etc/apache/httpd.conf:
Cannot load /usr/apache/libexec/libphp4.so into server: ld.so.1: /usr/apache/bin/httpd: fatal: libgcc_s.so.1: open failed: No such file or directory
/usr/apache/bin/apachectl start: httpd could not be started

i can't find libgcc_s.so ???

[2002-06-24 14:07 UTC] sniper@php.net

Is that libgcc_s.so.1 anywhere in your system?
(try 'find / -name libgss_s.so.1')

And was this with 4.2.1?

[2002-06-25 04:25 UTC] potnoddle at hotmail dot com

found this only when i redirected the out of configure, solaris comes with gcc 2.9.1 as a defualt! this may work, will hear back from me if it has'nt


*** Warning: Releases of GCC earlier than version 3.0 cannot reliably
*** create self contained shared libraries on Solaris systems, without
*** introducing a dependency on libgcc.a.  Therefore, libtool is disabling
*** -no-undefined support, which will at least allow you to build shared
*** libraries.  However, you may find that when you link such libraries
*** into an application without using GCC, you have to manually add
*** `gcc --print-libgcc-file-name` to the link command.  We urge you to
*** upgrade to a newer version of GCC.  Another option is to rebuild your
*** current GCC to use the GNU linker from GNU binutils 2.9.1 or newer.

[2002-06-25 11:38 UTC] sniper@php.net

Let us know in any case..

[2002-06-26 05:19 UTC] potnoddle at hotmail dot com

found this hidden in configure only after i had outputed the results to a file!

*** Warning: Releases of GCC earlier than version 3.0 cannot reliably
*** create self contained shared libraries on Solaris systems, without
*** introducing a dependency on libgcc.a.  Therefore, libtool is disabling
*** -no-undefined support, which will at least allow you to build shared
*** libraries.  However, you may find that when you link such libraries
*** into an application without using GCC, you have to manually add
*** `gcc --print-libgcc-file-name` to the link command.  We urge you to
*** upgrade to a newer version of GCC.  Another option is to rebuild your
*** current GCC to use the GNU linker from GNU binutils 2.9.1 or newer.

i upgraded and got this

libpng warning: Application was compiled with png.h from libpng-1.0.6
libpng warning: Application  is running with png.c from libpng-1.2.0
gd-png:  fatal libpng error: Incompatible libpng version in application and library
[Wed Jun 26 09:40:09 2002] [notice] child pid 20535 exit signal Segmentation Fault (11)

downgraded and used the below

'./configure' '--prefix=/usr/local/php' '--with-oci8=/usr/home/oracle/product/8.1.7/' '--with-apxs=/usr/apache/bin/apxs' '--with-gd' '--with-pear=/usr/local/pear' '--with-jpeg-dir=/usr/local/lib' '--with-zlib' '--with-png-dir=/usr/local/lib' '--enable-exif' '--without-mysql' '--enable-gd-native-ttf' '--enable-debug'

[2002-06-26 18:35 UTC] sniper@php.net

So this obviously is not any bug in PHP.

And btw. the correct path for --with-jpeg-dir / --with-png-dir options is /usr/local in your case.

(no /lib is supposed to be there.)

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2025 The PHP Group All rights reserved.	Last updated: Fri May 09 21:01:27 2025 UTC