php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #17312 Build problem with GCC 3.1
Submitted: 2002-05-20 12:05 UTC Modified: 2003-02-08 13:42 UTC
Votes:53
Avg. Score:4.4 ± 0.9
Reproduced:49 of 50 (98.0%)
Same Version:13 (26.5%)
Same OS:14 (28.6%)
From: asautins at yahoo dot com Assigned:
Status: No Feedback Package: MySQL related
PHP Version: 4.2.1 OS: Redhat 7.2
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2002-05-20 12:05 UTC] asautins at yahoo dot com
  Building php 4.2.1 ( ./configure with no options ) using GCC 3.1 causes the following error:

/usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':
/home/asautins/php4/ext/mysql/libmysql/my_tempnam.c:86: the use of `tempnam' is dangerous, better use `mkstemp'
collect2: ld returned 1 exit status

  It looks like a warning, but php will not link.  If I comment out the call to tempnam in my_temnam.c, it links correctly.

  Given that GCC 3.1 does not come as part of the standard distribution and I built it from source, that could be the problem, but I was able to reproduce on two separate instances.

  It would be nice to use php_open_temporary_file (main/php_open_temporary_file.c ) to avoid duplicating the effort, but it does not seem to be intended for use by modules.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-05-22 12:31 UTC] asautins@php.net
It seems that the functions in my_tempnam.c are not used.  If I removed my_tempnam.c from ext/mysql/config.m4 php builds and seems to run correctly.

config.m4
53c53
<       libmysql/my_delete.c libmysql/my_tempnam.c libmysql/my_open.c libmysql/mf_casecnv.c libmysql/my_read.c \
---
>       libmysql/my_delete.c libmysql/my_open.c libmysql/mf_casecnv.c libmysql/my_read.c \


 [2002-05-22 15:19 UTC] mfischer@php.net
Does this mean by chance the gcc 3.1 treats this as an error what used to be a warning only in 2.9x ?
 [2002-05-22 15:32 UTC] asautins@php.net
To me it looks like the linker has trouble with it somehow.  Compiles OK, but fails in linking with the 'unhandled FORM value: 14' error.

  Again, it looks as if the routines in my_tempnam.c are not referenced anywhere in the extension, so to me it looks as if it would be safe to remove the source file.
 [2002-05-22 15:39 UTC] mfischer@php.net
I've found this line through google: http://gcc.gnu.org/ml/gcc/2002-02/msg00965.html
 [2002-05-22 15:41 UTC] mfischer@php.net
Even better this one http://gcc.gnu.org/ml/gcc/2002-02/msg01071.html (one of the Follow-Ups)
 [2002-05-29 23:56 UTC] asautins@php.net
  Is this something that could be caught when ./configure is run?  My concern is that ./configure checks for tempnam successfully eventhough it will not link.

  However, since this seems to be the behavior of AC_CHECK_FUNCS there might not be anything to do.
 [2002-07-02 09:56 UTC] sniper@php.net
Please try this snapshot:

http://snaps.php.net/php4-latest.tar.gz

(has updated bundled libmysql)

 [2002-08-03 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2003-01-08 01:17 UTC] renjin at starhub dot net dot sg
OS: linux mandrake 2.4.18
PHP: 4.3.0

i got the problem... again...
my 4.2.3 make nicely.
my 4.3.0 screw up with this error
--------
ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':
/home/install/tmp/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp'
--------

can anyone tell me which files in my
php-4.3.0/ext/mysql/
should i replace to re-fix the problem, please?

thanks
 [2003-02-06 17:40 UTC] ecarter at uci dot edu
/usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':
/local/src/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Here's the gcc ver:
gcc-2.96-98
gcc3-g77-3.0.4-1
gcc-g77-2.96-98
libgcc-3.0.4-1
gcc-chill-2.96-98
gcc3-3.0.4-1
gcc3-objc-3.0.4-1
gcc-c++-2.96-98
gcc-objc-2.96-98
gcc3-java-3.0.4-1
gcc-java-2.96-98
gcc3-c++-3.0.4-1

-- I'm not sure what the problem is.
It seems that I have no problems with
another machine, here's the gcc ver on that:

gcc-chill-2.96-98
libgcc-3.0.1-3
gcc-g77-2.96-98
gcc-c++-2.96-98
gcc3-g77-3.0.1-3
gcc-java-2.96-98
gcc-2.96-98
gcc3-objc-3.0.1-3
gcc3-c++-3.0.1-3
gcc-objc-2.96-98
gcc3-3.0.1-3
gcc3-java-3.0.1-3

Both are redhat linux,
eric
 [2003-02-08 13:42 UTC] moriyoshi@php.net
Be sure to use the latest version of binutils that matches the gcc version you are using.

 [2003-03-17 14:17 UTC] mule at themule dot net
also works for Red Hat 7.3 and PHP 4.3.1:  

install:
mysql-3.23.54a-3.73.rpm
mysql-devel-3.23.54a-3.73.rpm

./configure --with-mysql=/usr
 [2003-04-10 15:51 UTC] dpenezic at srce dot hr
RedHat 9, standard instalation, PHP 4.3.1

Solution 

  --with-mysql=/path_to_base_mysql_directory

solve a problem
 [2003-04-22 12:48 UTC] lanttis at homeharmony dot fi
On Mandrake 9.1 none of the above methods seem to work. By installing libmysql12 and adding --with-mysql=/mysql_base_dir I just get "No header files in this location".

However, when putting --with-mysql=/usr I get:

...
ext/mysql/php_mysql.o(.text+0x1c74): In function `zif_mysql_create_db':
/home/lanttis/php-4.3.1/ext/mysql/php_mysql.c:1118: undefined reference to `mysql_create_db'
ext/mysql/php_mysql.o(.text+0x1e06): In function `zif_mysql_drop_db':
/home/lanttis/php-4.3.1/ext/mysql/php_mysql.c:1160: undefined reference to `mysql_drop_db'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php] Error 1

Any enlightment on the matter is deeply appreciated!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 22:01:26 2024 UTC