PHP 4.0 Bug #6464 Updated: Compilation w/ curl support fails with _gd_parse error (?)

From: Date: Fri, 08 Dec 2000 17:48:20 +0000
Subject: PHP 4.0 Bug #6464 Updated: Compilation w/ curl support fails with _gd_parse error (?)
Groups: php.dev 
Request: Send a blank email to php-dev+get-40581@lists.php.net to get a copy of this message
ID: 6464 User Update by: cahagn_o@epita.fr Old-Status: Duplicate Status: Closed Bug Type: Compile Failure Description: Compilation w/ curl support fails with _gd_parse error (?) Fixed thanks to Sacha's fix seen on bug #8416. It now compiles fine. I onlt have a minor warning left with cURL which I didn't have 1 month ago: curl.c: In function `php_if_curl_init': curl.c:303: warning: passing arg 3 of `zend_llist_init' from incompatible pointer type Thanks a lot. I hope I had the rights to close this bug otherwise you may consider closing it. Previous Comments: --------------------------------------------------------------------------- [2000-12-07 19:05:03] sniper@php.net Ok. I'll make this one duplicate of #8146. --Jani --------------------------------------------------------------------------- [2000-12-07 05:15:05] cahagn_o@epita.fr Just tested RC4 --with-curl (7.3 I guess) One build warning I did not have before: curl.c: In function `php_if_curl_init': curl.c:303: warning: passing arg 3 of `zend_llist_init' from incompatible pointer type And still the same fatal warning when linking: parsedate.c:619: Definition of symbol `_gd_parse' (multiply defined) y.tab.c:1102: Definition of symbol `_gd_parse' (multiply defined) ./configure --with-config-file-path=/usr/www/etc/httpd/conf/php_cgi --enable-discard-path --without-mysql --with-curl=/u/guest/www/mbin/i386-NetBSD You can consider closing this bug unfortunately because: - I won't have the time to test PHP on this particular platform in the future (it takes 1 hour to build !) - Adding cURL support would increase the PHP binary even more and slowing down its execution (running as CGI). It's really related to old version of gcc, and the file indicated in previous updates. --------------------------------------------------------------------------- [2000-12-07 04:00:22] sniper@php.net Is this still happening with PHP4.0.4RC4?? (I can't reproduce this..) --Jani --------------------------------------------------------------------------- [2000-10-04 18:39:26] cahagn_o@epita.fr The problem still occurs with cURL 7.3 and PHP4.0.3RC2 or latest snapshot. parsedate.c:619: Definition of symbol `_gd_parse' (multiply defined) getdate.y:617: Definition of symbol `_gd_parse' (multiply defined) parsedate.c defines gd_parse in PHP source. getdate.y (.c) defines gd_parse in cURL source. I tried regenerating cURL getdate.c from getdate.y with yacc but the problem still occurs. Here's a note from cURL source (getdate.y), it might help understand what happens (I use old gcc 2.7.2.2): /* Remap normal yacc parser interface names (yyparse, yylex, yyerror, etc), as well as gratuitiously global symbol names, so we can have multiple yacc generated parsers in the same program. Note that these are only the variables produced by yacc. If other parser generators (bison, byacc, etc) produce additional global names that conflict at link time, then those parser generators need to be fixed instead of adding those names to this list. */ #define yymaxdepth gd_maxdepth #define yyparse gd_parse Is there any expert in yacc/bison here ? :) --------------------------------------------------------------------------- [2000-10-02 23:25:24] sniper@php.net What is the situation with this?? --Jani --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=6464

« previous php.dev (#40581) next »