OK, I've spent most of the day trying to get PHP 4.2.2 w/ libgd, libjpeg, libpng, and libfreetype to work properly on a pretty much plain jane RH 7.2 system. I've had PHP 4.2.2 running on this system for a bit over a week with only XML and mysql support built in.

For a long time, I kept getting complaints about multiple definitions of something in gd (can't remember what right now), but I finally got rid of that error after removing my old versions of libfreetype, libpng, and libgd and installing new ones.

Now PHP compiles without any errors whatsoever. Apache starts up fine, no errors. However, any script that tries to use any of the image functions gives me a "call to undefined function" error. What gives? I've recompiled 3 or 4 times now just to make sure I was including all the png, jpg, freetype, and gd libraries and I wasn't getting any errors I was missing.


    I know you said you weren't getting any errors compiling, but make sure that when you run configure that it is able to find the libraries in question: libpng, libjpeg, zlib, and libfreetype. I had to tell configure specifically where each one was (it didn't even seem to be looking in the standard places, /usr/lib and /usr/local/lib, which is where all the libraries in question were located). When you are running configure you will get something like this if the libs aren't being found:

    Checking for libjpeg... no
    libjpeg not found, if configure fails, use --with-jpeg-dir=<DIR>

    However, configure will not fail, but GD will still not work. I had to set all the locations manually and they were all in /usr/lib except for freetype which was in /usr/local/lib because I'd put a newer version on. I don't know if this is a bug in the configure script or what, but if you specify the locations it should work.

    The only other problem you might be having is if you built GD as a shared PHP module. In the default php.ini file, all the Windows extensions are commented out and there isn't a section for Unix extensions whatsoever. So you have to make one and then just have a line that says "extension=gd.so" or something of that nature. Also make sure you set the extension path variable in php.ini to be the "modules" directory under the place where you unpacked the source. I suppose the right thing to do is make a mods directory somewhere else and copy gd.so out of the sources dir into the new one so you can delete the sources if you're running low on disk space, but I didn't do that. Anyways, a restart of Apache which in turn restarts PHP should make PHP load gd.so.

    Also, you mentioned that you'd previously compiled in MySQL support (as opposed to using the builtin clients that come with PHP. In my case, even though I used --with-mysql when I ran PHP's configure script, I still got a warning when configure was done saying that the builtin clients would be used. This apparently is also caused because configure doesn't look around too hard (MySQL was installed in /usr/local/mysql which seems like the first place that should've been checked), but oh well. This will get rid of the warning.

    Hope this helped and good luck!

    EDIT - Converting to my color scheme.

      undertow, thanks for your response.

      I should have known to paste my ./configure setup in the post, but I didn't . . . so here it is:

      ./configure --with-mysql --with-xml --with-gd-dir=/usr --with-png-dir=/usr/local --with-jpeg-dir=/usr/local --with-zlib-dir=/usr --with-apxs

      All of the --with-*-dir directives are pointing to the correct directories . . . I've double checked to make sure the libraries are there. I scrolled back through the output of ./configure and discovered that I was getting "checking for GD support... no", which seems quite odd since I'm specifically telling it where to look for gd.

      So . . . I deleted the entire source directory (I've been using make clean before trying to ./configure and compile again, but wanted to be on the safe side) and tried again. With the same ./configure, I got the same "checking for GD support... no".

      Somewhere in my searches I found someone adding a "--with-gd" to their ./configure, so I tried that:

      ./configure --with-mysql --with-xml --with-gd-dir="/usr" --with-png-dir=/usr/local --with-jpeg-dir=/usr/local --with-zlib-dir=/usr --with-apxs --with-gd

      The relevant output:
      checking for GD support... yes
      checking whether to enable truetype string function in GD... no
      checking for the location of libjpeg... yes
      checking for jpeg_read_header in -ljpeg... yes
      checking for the location of libpng... yes
      checking for png_write_image in -lpng... yes
      checking for the location of libXpm... no
      If configure fails try --with-xpm-dir=<DIR>
      checking for freetype(2)... no
      If configure fails try --with-freetype-dir=<DIR>
      checking for FreeType 1.x support... no
      checking for T1lib support... no
      checking for gdImageString16 in -lgd... no
      checking for gdImagePaletteCopy in -lgd... no
      checking for gdImageCreateFromPng in -lgd... no
      checking for gdImageCreateFromGif in -lgd... no
      checking for gdImageGif in -lgd... no
      checking for gdImageWBMP in -lgd... no
      checking for gdImageCreateFromJpeg in -lgd... no
      checking for gdImageCreateFromXpm in -lgd... no
      checking for gdImageCreateFromGd2 in -lgd... no
      checking for gdImageCreateTrueColor in -lgd... no
      checking for gdImageSetTile in -lgd... no
      checking for gdImageSetBrush in -lgd... no
      checking for gdImageStringTTF in -lgd... no
      checking for gdImageStringFT in -lgd... no
      checking for gdImageStringFTEx in -lgd... no
      checking for gdImageColorClosestHWB in -lgd... no
      checking for gdImageColorResolve in -lgd... no
      checking for gdImageGifCtx in -lgd... no

      Just to be on the safe side, I tried recompiling gd (with the test programs this time), and still got the same response. gddemo spits out the demoout.png just fine, so it doesn't appear to be a problem with gd.

      I'm going to see what I can find about compiling gd as a module now . . .


        First of all, it's --with-gd=<DIR>, not --with-gd-dir=<DIR> (I know it's a pain because each one is different). This should help configure in finding GD. I don't know where mine is installed (it came with RedHat 7.3) but it got found automatically so this wasn't a problem for me. Assuming you already have GD installed, which I think is a prereq, you can type "whereis gd" and use the directory it tells you.

        Second, your FreeType isn't being found, but you probably already knew that. I think I used --enable-gd-native-ttf as well, but I don't see how that would affect FreeType. Make sure the lib you're pointing configure at is the right version for the configure option you're using (--with-ttf=<DIR> for v1.x and --with-freetype-dir=<DIR> for v2.x).

        To build GD as a shared PHP module, use --with-gd=shared or --with-gd=shared,<DIR>.

        Since you were talking about being on the safe side, you can also delete config.cache along with using make clean if you don't want to delete the entire source directory again.

        Once again, good luck!

        EDIT - check out http://www.php.net/manual/en/install.configure.php#install.configure.options.graphics for the list of configure options that have to do with graphics.

          OK, changed --with-gd-dir= to --with-gd=, and I still have the same resulting output from ./configure as I posted above. Also no go at compiling gd as a shared library.

          I had decided to leave out Freetype support for the time being . . . is this possibly a problem?

          Also, I'm ashamed for not posting what versions of the libraries I've got installed. I personally know how difficult it can be to help troubleshoot a problem without that sort of information . . . not sure why I didn't initially include it. So, here they are:

          gd: 2.0.1 (needed TrueColor support)
          libpng: 1.2.4
          libjpeg: 6.0.1
          zlib: 1.1.4
          freetype: 2.1.2 (in case it's relevant)

          If I can't get it to work right now, it's not a show-stopper . . . I'm just trying to superimpose a client's logo over some images as a "watermark" of sorts (and I know the code works successfully on my PowerBook w/ OS X).

          Thanks again for your help.


            Leaving out FreeType should not be causing the problem.

            I'm away from my primary web server which has all the stuff you're talking about on it, so I can't check the version numbers for you. You said in the first post that you'd installed newer versions of the graphics libraries though. Did you recompile GD after doing so? I bet you did, since you said that fixed another problem, but I'm just checking. I use RedHat 7.3 which would most likely have the most recent versions, but from the sound of it you went and tracked down the newest versions of the libs yourself.

            My final suggestion may or may not even matter. I always remove the packaged version of software before I build and install the newer version from source so I don't need to worry about versions getting mixed up. This may not even be the problem, but if you still have the packaged version of the original libpng, libjpeg, etc. libs installed, you may wish to erase the package before building/installing the newer versions. Who knows, it just might work.

            You have reached the end of my limited knowledge. Maybe someone other than one of us will join this thread now :p.

              Yeah, I recompiled gd after installing the new versions of the other libs. Don't know about RH7.3, but my system is 7.2, and it had gd 1.8.3 on it originally . . . can't remember about the other libs. And I did make sure the old versions of the software were removed.

              In any case, even though the problem hasn't been solved, thank you very much for your willingness to help. Because of your "limited knowledge" I now know several things about configuring PHP that I didn't before. Thanks again!

              It seems odd to me, however, that I haven't really been able to find any mention of a similar problem w/ PHP 4.2.2 and gd compatibility . . . so I'm wondering if maybe it's an issue with gd 2+ and PHP, and few people are using that as of now. I'm tempted to try recompiling PHP with gd 1.8.3 installed and see if that works, when I've got the time.


                That's it! When you said that it was GD 1.8.3 that came with RH I remembered that that would be the version I have on mine since I didn't change GD at all after I installed the OS! So it is almost surely a problem with the 2.x line, which isn't too surprising in hindsight because often many more things are changed when the major version number is incremented. So yes, my advice definately would be to try the 1.8.3 version of GD. I just hope that first problem that you said you'd solved (in your first post) doesn't come back...

                Also, I don't have time to look around too much now, but you should see if there's a --with-gd2 type of configure option for PHP for using a 2.x version of GD like there is a --with-apxs2 one for building an Apache 2.0 DSO.

                Finally, the most likely reason that you weren't able to find much info on this problem is that probably very few people try to use GD. I myself couldn't get it to work until about a week ago. It's not included in the binaries on the official site so most non power users probably don't even know what it is and what it can do.

                Once again, good luck!

                EDIT - Small edit for clarity.

                  6 days later

                  I am having the same issue. Upgraded PHP from 4.1.2 with GD1.8.x to PHP 4.2.2. Now GD calls result in a segfault. I have tried rebuilding it a number of time but GD just doesn't want to come to the party.

                  A few of our hosted sites are affected. PHP was built exactly the same as 4.1.2. and against the same libraries.

                  My config statement
                  './configure' \
                  '--with-mysql=/usr/local/mysql' \
                  '--with-apxs=/usr/local/apache/bin/apxs' \
                  '--with-ming=/usr/local/src/ming-0.2a' \
                  '--with-gd=/usr/local/src/gd' \
                  '--with-png-dir=/usr/local/src/libpng' \
                  '--with-jpeg-dir=/usr/local/src/jpeg-6b' \
                  '--with-dom' \
                  '--with-zlib' \
                  '--with-imap-dir=/usr/local/src/imap' \
                  '--with-imap' \
                  '--with-java=/usr/local/j2sdk1.4.0' \
                  '--with-zend' \
                  '--with-pdf' \
                  '--with-pdflib=/usr/local' \
                  '--enable-shared-pdflib' \
                  '--with-xml' \
                  '--enable-xslt' \
                  '--with-xslt-sablot' \
                  '--enable-gd-native-ttf' \
                  '--enable-ftp' \
                  '--enable-track-vars' \

                  All builds fine.

                  When a customer php script attempts to generate a JPEG image I get this in the apache error logs.

                  [Tue Aug 20 17:13:01 2002] [notice] child pid 553 exit signal Segmentation fault (11)

                  VERY FRUSTRATING

                  My libs line from the GD Makefile

                  LIBS=libgd.a -lpng -lz -ljpeg -lm

                  Anyone else having grief with PHP4.2.2?

                  Anyone got any ideas on where to look?

                  regards,

                  Steve Kelly

                    Write a Reply...