Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:1032 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10245 invoked from network); 24 Apr 2003 21:06:09 -0000 Received: from unknown (HELO mail.modwest.com) (216.129.251.30) by pb1.pair.com with SMTP; 24 Apr 2003 21:06:09 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.modwest.com (Postfix) with ESMTP id C30CD40F4D9D for ; Thu, 24 Apr 2003 15:06:08 -0600 (MDT) Received: from mail.modwest.com ([127.0.0.1]) by localhost (marshall.modwest.com [127.0.0.1]) (amavisd-new) with ESMTP id 14579-16 for ; Thu, 24 Apr 2003 15:06:08 -0000 (MDT) Received: from [10.0.0.137] (unknown [69.24.111.150]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.modwest.com (Postfix) with ESMTP id 9497D40F5CF2 for ; Thu, 24 Apr 2003 15:06:07 -0600 (MDT) Date: Thu, 24 Apr 2003 15:08:19 -0700 To: internals@lists.php.net Message-ID: <690628031.1051196899@[10.0.0.137]> X-Mailer: Mulberry/3.0.3 (Win32 Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new amavisd-new-20020630 Subject: Bug # 21533 NOT SOLVED! (Trouble building PHP w/ GD and including ImageTTFxxx functions) From: mloftis@modwest.com (Michael Loftis) I've made a note/comment in the bug itself but figured I should post it here too. This bug is NOT yet fixed. In 4.3.1 the code can and still does produce bogus code that doesn't set error. my main/php_config.h generates with this area (not verbatim): /* */ /* #undef HAVE_GD_STRINGTTF */ /* */ /* #undef HAVE_GD_STRINGFT */ /* */ /* #undef HAVE_GD_STRINGFTEX */ /* */ #define USE_GD_IMGSTRTTF 1 /* */ #define USE_GD_IMGSTRTTF 1 Notice we have neither FT nor the FTEX, nor TTF! So why in the world does USE_GD_IMGSTRTTF get 1? TAke a look at gd.c:2937 In this case error still ends up undefined as we never execute any of the four functions!!!! I traced the calls back up, the bt is included below along with a print error to point out the fact. GDB OUTPUT: #0 0x080c114b in xbuf_format_converter (xbuf=0xbfffd1a0, fmt=0x40357707 "s", ap=0xbfffd260) at /usr/src/webserver/php-4.3.1/main/spprintf.c:438 #1 0x080c1601 in vspprintf (pbuf=0xbfffd208, max_len=0, format=0x40357706 "%s", ap=0xbfffd25c) at /usr/src/webserver/php-4.3.1/main/spprintf.c:622 #2 0x080be757 in php_verror (docref=0x0, params=0x80f92af "", type=2, format=0x40357706 "%s", args=0xbfffd25c) at /usr/src/webserver/php-4.3.1/main/main.c:423 #3 0x080bea1d in php_error_docref0 (docref=0x0, type=2, format=0x40357706 "%s") at /usr/src/webserver/php-4.3.1/main/main.c:508 #4 0x403489f6 in php_imagettftext_common (ht=8, return_value=0x817e304, this_ptr=0x0, return_value_used=0, mode=0, extended=0) at /usr/src/webserver/php-4.3.1/ext/gd/gd.c:2957 #5 0x4034861b in zif_imagettftext (ht=8, return_value=0x817e304, this_ptr=0x0, return_value_used=0) at /usr/src/webserver/php-4.3.1/ext/gd/gd.c:2835 #6 0x402fb542 in zend_assign_to_variable_reference () from /usr/local/libexec/php-4.3.1/ZendOptimizer.so #7 0x40304a02 in zend_oe () from /usr/local/libexec/php-4.3.1/ZendOptimizer.so #8 0x080c02cb in php_execute_script (primary_file=0xbffffcb0) at /usr/src/webserver/php-4.3.1/main/main.c:1576 #9 0x080f8d84 in main (argc=2, argv=0xbffffd54) at /usr/src/webserver/php-4.3.1/sapi/cgi/cgi_main.c:1424 0> (gdb) up #4 0x403489f6 in php_imagettftext_common (ht=8, return_value=0x817e304, this_ptr=0x0, return_value_used=0, mode=0, extended=0) at /usr/src/webserver/php-4.3.1/ext/gd/gd.c:2957 2957 /usr/src/webserver/php-4.3.1/ext/gd/gd.c: No such file or directory. in /usr/src/webserver/php-4.3.1/ext/gd/gd.c (gdb) print error $2 = 0x20
(gdb) And the PHP script that will reproduce this every time:: mloftis@modwest:/htdocs/www/gd/431$ cat ttf.php #!/usr/local/bin/php-4.3.1-4 And our ./configure statment. ./configure --disable-debug --disable-rpath --with-pear=/usr/local/lib/php-4.3.1 --with-config-file-path=/etc --prefix=/usr/local --libexecdir=/usr/local/libexec/php-4.3.1 --enable-shared=yes --enable-track-vars --enable-magic-quotes --enable-trans-sid --with-kerberos --enable-all=shared --without-cyrus --without-fbsql --without-fdftk --without-fribidi --without-hwapi --without-informix --without-ingres --without-interbase --without-ircg --without-java --without-mcve --without-msession --without-oracle --without-oci8 --without-ovrimos --without-qtdom --without-readline --without-libedit --without-sybase --without-sybase-ct --without-msql --without-mssql --with-imap-ssl --with-openssl --enable-session --with-sablot-js=/usr --with-xslt-sablot=/usr --with-gdbm=shared,/usr --with-ndbm=shared,/usr --with-db2=shared,/usr --with-db3=shared,/usr --with-unixODBC=shared,/usr --disable-calendar --enable-overload --without-ncurses --disable-mime-magic --with-zlib --with-pcre-regex --disable-yp --disable-path-info-check --enable-discard-path --enable-mw-php-ini --enable-mw-deprecated-extension --with-jpeg-dir=/usr --enable-gd-native-ttf --with-ttf=/usr --with-png-dir=/usr Relevant output around the GD extension config: checking for FDF support... no checking whether to enable the bundled filePro support... yes, shared checking for FriBidi support... no checking whether to enable FTP support... yes, shared checking for GD support... yes, shared checking for the location of libjpeg... yes, shared checking for the location of libpng... yes, shared checking for the location of libXpm... yes, shared checking for FreeType 1.x support... yes, shared checking for FreeType 2... yes, shared checking for T1lib support... yes, shared checking whether to enable truetype string function in GD... yes, shared checking for fabsf... yes checking for floorf... yes checking for jpeg_read_header in -ljpeg... yes checking for png_write_image in -lpng... yes If configure fails try --with-xpm-dir= If configure fails try --with-freetype-dir= checking for GNU gettext support... yes, shared checking for bindtextdomain in -lintl... no checking for bindtextdomain in -lc... yes Need anything else? -- Michael Loftis Modwest Sr. Systems Administrator Powerful, Affordable Web Hosting