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

ID: 6464 User Update by: cahagn_o@epita.fr Old-Status: Feedback Status: Open Bug Type: Compile Failure Description: Compilation w/ curl support fails with _gd_parse error (?) 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. Previous Comments: --------------------------------------------------------------------------- [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 --------------------------------------------------------------------------- [2000-09-12 00:48:35] cahagn_o@epita.fr As stated in the bug report, I _don't_ have bison installed on this machine. Zeev told me it's not needed anyway. (see no aggresivity in this statement, it's just to make myself clear as the previous bug report might have been confusing :) I tried latest php snapshot 200009110745 with ./configure --with-curl=/path/to/curl I also recompiled cURL 7.2.1 and removed every #line directive in lib/getdate.c as it gives warnings with gcc 2.7.2.2 here (see bug #6465) I now get these warnings when linking php: parsedate.c:619: Definition of symbol `_gd_parse' (multiply defined) getdate.y:617: Definition of symbol `_gd_parse' (multiply defined) getdate.y is in cURL distribution and it contains one reference to _gd_parse: pc1: ~/php/curl-7.2.1 % rgrep gd_parse * lib/getdate.y:#define yyparse gd_parse lib/getdate.c:#define yyparse gd_parse I shouldn't need to have bison and regenerate the parser. I tried anyway on another box with bison 1.28 and then recompiled from scratch on NetBSD with gcc 2.7.2.2 and got the same warnings. I'm trying to reach cURL's author to see if and how I can solve this problem. --------------------------------------------------------------------------- [2000-09-10 18:31:57] sterling@php.net Try updating bison to the latest version and seeing whether it still happens --------------------------------------------------------------------------- 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