I just did an emerge rsync today (16/02/2003) and then an emerge -u world. This brought in php-4.3.0-r4 (I'm currently using 4.3.0-r3). During the configure stage of the install, I get the following error: checking for fork... no configure: error: pcntl: fork() not supported by this platform See attachment for config.log file. Reproducible: Always Steps to Reproduce: 1. emerge rsync, as of 15/02/2003 2. emerge php (on a system with ACCEPT_KEYWORDS="~x86") Actual Results: The emerge process failed with an error about fork() being unsupported. Expected Results: The emerge process should have succeeded, resulting in a new version of PHP being installed. My USE settings: X gtk2 xft2 freetype smooth dvd apache2 -kde -qt -qtmt -arts -cups I am also have ACCEPT_KEYWORDS="~x86" in my /etc/make.conf file.
Created attachment 8345 [details] config.log file from ebuild process
*** Bug 15988 has been marked as a duplicate of this bug. ***
*** Bug 16004 has been marked as a duplicate of this bug. ***
same with 4.3.1
*** Bug 16058 has been marked as a duplicate of this bug. ***
*** Bug 16083 has been marked as a duplicate of this bug. ***
The problem is that when you do an 'emerge -pu world' and you're using blackdown-jdk, the new blackdown-jdk emerge is broken. php has java as a dependency so the emerge php won't go through to completion. The new blackdown-jdk emerge is _NOT_ updating the java envirnonmental variables. The broken blackdown-jdk ebuild is: blackdown-jdk-1.4.1.ebuild ===================================================================================== checking for hwapi support... no checking for Hyperwave support... no checking for iconv support... no checking for IMAP support... no checking for Informix support... no checking for Ingres II support... no checking for InterBase support... no checking for IRCG support... no checking for Java support... yes checking Java Jar location... configure: error: Unable to locate /opt/blackdown-jdk-1.4.1_beta/bin !!! ERROR: dev-php/php-4.3.1 failed. !!! Function src_compile, Line 183, Exitcode 1 !!! bad ./configure dragon kde # dragon root # env MANPATH=/usr/share/man:/usr/local/share/man:/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man:/usr/X11R6/man:/opt/blackdown-jdk-1.4.1_beta/man INFODIR=/usr/share/info:/usr/X11R6/info HOSTNAME=dragon.lamasondufeu.com SHELL=/bin/bash TERM=xterm QTDIR=/usr/qt/3 MOZILLA_FIVE_HOME=/usr/lib/mozilla FRACTDIR=/usr/share/xfractint USER=root KDEDIR=/usr/kde/3.1 CONFIG_PROTECT_MASK=/etc/gconf PAGER=/usr/bin/less XINITRC=/etc/X11/xinit/xinitrc MAIL=/var/spool/mail/root PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.2:/opt/ati/bin:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.1_beta/bin:/opt/blackdown-jdk-1.4.1_beta/jre/bin:/usr/qt/3/bin:/usr/kde/3.1/sbin:/usr/kde/3.1/bin:/usr/qt/2/bin INPUTRC=/etc/inputrc PWD=/root JAVA_HOME=/opt/blackdown-jdk-1.4.1_beta JAVAC=/opt/blackdown-jdk-1.4.1_beta/bin/javac EDITOR=/bin/nano KDEDIRS=/usr QMAKESPEC=linux-g++ PS1=\[\033[01;31m\]\h \[\033[01;34m\]\W \$ \[\033[00m\] CXX=g++ JDK_HOME=/opt/blackdown-jdk-1.4.1_beta SHLVL=1 HOME=/root LESS=-R LOGNAME=root CVS_RSH=ssh CLASSPATH=/opt/blackdown-jdk-1.4.1_beta/jre/lib/rt.jar:. LESSOPEN=|lesspipe.sh %s VIMRUNTIME=/usr/share/vim/vim61 INFOPATH=/usr/share/info:/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info CC=gcc DISPLAY=:0 CONFIG_PROTECT=/usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config _=/usr/bin/env dragon root # emerge -p blackdown-jdk These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] dev-java/blackdown-jdk-1.4.1 <==================== NOTE!!!!!!!!!!!!!! dragon root #
I don't use "~x86" , have blackdown 1.3.1-r7 and still get related error. See bug 15936
Regarding comment #8 Definite point. [sigh] Looks like multiple problems. I just haven't run into the 'fork' problem (yet). ;-) [/sigh]
I found some strange results searching for this bug. Hope this will give someone some ideas. I captured the ouput of the ebuild for php-4.3.1 and php-4.3.0-r3. r3 builds fine and 4.3.1 doesn't on the same machine. There are very few differences in the builds so this should narrow it down some. The only thing that could contribute is I recently unmerged and emerged blackdown-jdk,jre (mozilla probs). These 1.3.1-r7 ebuilds have some kind of problem -see bug 15936. Could this ebuild or maybe another messed up some env includes or something to cause the following? The problem isn't with fcntl - just because the build fails there. Look at the following diff of the ebuilt output. Why does 4.3.1's configure come up with 'size of char = 0'!!!!!!!!!! Also long long,ulong,uint,ushort are bogus??? No wonder the build fails during the fcntl check. =================================================================================== # diff '/var/tmp/portage/4.3.0-r3.txt' '/var/tmp/portage/4.3.1.txt' 1c1 < >>> Checking php-4.3.0.tar.bz2's mtime... --- > >>> Checking php-4.3.1.tar.bz2's mtime... 17a18 > java 322c323,326 < checking for Java support... no --- > checking for Java support... yes > checking Java Jar location... /opt/blackdown-jdk-1.3.1/bin/jar cf > checking Java C location... /opt/blackdown-jdk-1.3.1/bin/javac > checking Checking for libjava... /opt/blackdown-jdk-1.3.1/jre/lib/i386 339c343 < checking size of char... 1 --- > checking size of char... 0 342c346 < checking size of long long... 8 --- > checking size of long long... 0 346c350 < checking for type ulong... yes --- > checking for type ulong... no 348,349c352,353 < checking for type uint... yes < checking for type ushort... yes --- > checking for type uint... no > checking for type ushort... no ======================================================================================= next is where fcntl fails and the build stops
Same problem here. The config.log reveals that the problem is the failing of the link of the fork-checking program. All the missing symbols are in the libhpi.so library in /opt/blackdown-jdk-1.3.1/jre/lib/i386/native_threads. I kludged around this by adding this line into the ebuild file right before the ./configure line: export LIBS="-L/opt/blackdown-jdk-1.3.1/jre/lib/i386/native_threads -lhpi $LIBS" The build is still running on my system, though, so we'll see how things go. It seems to me that there must be a better fix than the above kludge.
Some help to narrow more.maybe. I untared php-3.2.1 and run multiple ./configure with various options. Any run with --with-java=/opt/blackdown-jdk-1.3.1 as passed by the ebuild will result in char len 0. Any run without it char len =1. The configure will continue in any case except with --enable-pcntl which seems to flag the problem by failing during the configure stage. Without pcntl make will fail similar to this: gcc -I/usr/portage/distfiles/php-4.3.1/ext/mysql/libmysql -Iext/mysql/ -I/usr/portage/distfiles/php-4.3.1/ext/mysql/ -DPHP_ATOM_INC -I/usr/portage/distfiles/php-4.3.1/include -I/usr/portage/distfiles/php-4.3.1/main -I/usr/portage/distfiles/php-4.3.1 -I/usr/portage/distfiles/php-4.3.1/Zend -I/usr/portage/distfiles/php-4.3.1/ext/xml/expat -I/usr/portage/distfiles/php-4.3.1/TSRM -g -O2 -c /usr/portage/distfiles/php-4.3.1/ext/mysql/libmysql/libmysql.c -o ext/mysql/libmysql/libmysql.o && echo > ext/mysql/libmysql/libmysql.lo In file included from /usr/portage/distfiles/php-4.3.1/ext/mysql/libmysql/libmysql.c:4: /usr/portage/distfiles/php-4.3.1/ext/mysql/libmysql/global.h:260: warning: redefinition of `uint' /usr/include/sys/types.h:152: warning: `uint' previously declared here /usr/portage/distfiles/php-4.3.1/ext/mysql/libmysql/global.h:261: warning: redefinition of `ushort' /usr/include/sys/types.h:151: warning: `ushort' previously declared here In file included from /usr/portage/distfiles/php-4.3.1/ext/mysql/libmysql/libmysql.c:11:
*** Bug 16234 has been marked as a duplicate of this bug. ***
My bug, 16234, just got marked as a dupe of this bug. Because I posted a lot of information in my bug, a) please read it while figuring this one out and b) notice that -lreadline needs -lncurses in the link line or else it will have unresolved symbols (this is the cause of two more bugs later on in the configure sequence). I also read anecdotally on the PHP bugzilla that this might be fixed in their CVS tree already. Someone might want to see if they've updated their configure script in CVS and just patch it into the 4.3.1 ebuild process...
Isn't this a kicker? Probably supports the everything is all f-up theory, since it looks like the script knows that -lreadline needs the tgetent, and is looking for it in both -lncurses and -ltermcap, but not finding it... checking for readline support... yes checking for tgetent in -lncurses... no checking for tgetent in -ltermcap... no checking for readline in -lreadline -lncurses... yes (I applied my patch to force -lreadline to include -lncurses, as seen in the last line there)
*** Bug 16289 has been marked as a duplicate of this bug. ***
*** Bug 16309 has been marked as a duplicate of this bug. ***
*** Bug 15936 has been marked as a duplicate of this bug. ***
I checked out the current CVS and build the configure... there is another bug in this version.
built*
*** Bug 16407 has been marked as a duplicate of this bug. ***
*** Bug 16433 has been marked as a duplicate of this bug. ***
*** Bug 16458 has been marked as a duplicate of this bug. ***
For anyone looking for a quick and easy work around until a more permanent solution is found so you can do an update world without having it die on php every time you can try the following command which works for me env USE="-java" emerge --update dev-php/php
Created attachment 8782 [details, diff] diff to resolve php build with java support enabled I've made this modification locally and php compiles and installs fine. Briefly, the existing ebuild tries to force the home of java to $JDK_HOME, on gentoo env-update does not set this variable in /etc/profile.env. $JAVA_HOME is this location so I modified the ebuild script to reference this instead. It may be more correct to append JDK_HOME to /etc/profiles.env if it's a variable that is normally set as part of the java development environment.
Created attachment 8783 [details, diff] diff to resolve php build with java support enabled I've made this modification locally and php compiles and installs fine. Briefly, the existing ebuild tries to force the home of java to $JDK_HOME, on gentoo env-update does not set this variable in /etc/profile.env. $JAVA_HOME is this location so I modified the ebuild script to reference this instead. It may be more correct to append JDK_HOME to /etc/profiles.env if it's a variable that is normally set as part of the java development environment.
ok, added your patch the php ebuilds, enjoy ;)
Did anybody bother to notice how many other bugs were marked as duplicates of this one, but had absolutely nothing to do with Java!? For example, my bug was about readline and ncurses. Now I'll check and see if this Java patch fixes those, since it is the resolution, per se, but better watch out or this one's getting re-opened :-P
actually, i'd bet money that every single bug (except yours :D) was this bug
Well wouldn't ya know, it *IS* Java related! Here, check this out from config.log: configure:40511: checking for ldap_parse_reference configure:40539: distcc gcc -o conftest -O2 -mcpu=i686 -pipe -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib -Wl,-rpath,/opt/blackdown-jdk-1.3.1/ jre/lib/i386/classic -L/opt/blackdown-jdk-1.3.1/jre/lib/i386/classic -Wl,-rpath,/opt/blackdown-jdk-1.3.1/jre/lib/i386/server -L/opt/blackdown- jdk-1.3.1/jre/lib/i386/server -Wl,-rpath,/opt/blackdown-jdk-1.3.1/jre/lib/i386/native_threads -L/opt/blackdown-jdk-1.3.1/jre/lib/i386/native_t hreads -Wl,-rpath,/opt/blackdown-jdk-1.3.1/jre/lib/i386 -L/opt/blackdown-jdk-1.3.1/jre/lib/i386 conftest.c -lldap -llber -lt1 -lttf -lX11 -lXp m -lpng -lz -ljpeg -lz -ldb -lgdbm -lbz2 -lz -lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcrypt -lxml2 -lz -lm 1>&5 /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_sem_post' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_waitpid' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_pthread_sigmask' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `fork1' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_sem_wait' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_sem_init' collect2: ld returned 1 exit status configure: failed program was: #line 40516 "configure" configure:40511: checking for ldap_start_tls_s configure:40539: distcc gcc -o conftest -O2 -mcpu=i686 -pipe -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib -Wl,-rpath,/opt/blackdown-jdk-1.3.1/ jre/lib/i386/classic -L/opt/blackdown-jdk-1.3.1/jre/lib/i386/classic -Wl,-rpath,/opt/blackdown-jdk-1.3.1/jre/lib/i386/server -L/opt/blackdown- jdk-1.3.1/jre/lib/i386/server -Wl,-rpath,/opt/blackdown-jdk-1.3.1/jre/lib/i386/native_threads -L/opt/blackdown-jdk-1.3.1/jre/lib/i386/native_t hreads -Wl,-rpath,/opt/blackdown-jdk-1.3.1/jre/lib/i386 -L/opt/blackdown-jdk-1.3.1/jre/lib/i386 conftest.c -lldap -llber -lt1 -lttf -lX11 -lXp m -lpng -lz -ljpeg -lz -ldb -lgdbm -lbz2 -lz -lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcrypt -lxml2 -lz -lm 1>&5 /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_sem_post' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_waitpid' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_pthread_sigmask' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `fork1' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_sem_wait' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_sem_init' collect2: ld returned 1 exit status configure: failed program was: #line 40516 "configure" #include "confdefs.h" configure:47097: checking size of char configure:47116: distcc gcc -o conftest -O2 -mcpu=i686 -pipe -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib -Wl,-rpath,/opt/blackdown-jdk-1.3.1/ jre/lib/i386/classic -L/opt/blackdown-jdk-1.3.1/jre/lib/i386/classic -Wl,-rpath,/opt/blackdown-jdk-1.3.1/jre/lib/i386/server -L/opt/blackdown- jdk-1.3.1/jre/lib/i386/server -Wl,-rpath,/opt/blackdown-jdk-1.3.1/jre/lib/i386/native_threads -L/opt/blackdown-jdk-1.3.1/jre/lib/i386/native_t hreads -Wl,-rpath,/opt/blackdown-jdk-1.3.1/jre/lib/i386 -L/opt/blackdown-jdk-1.3.1/jre/lib/i386 conftest.c -lmhash -lldap -llber -lt1 -lttf -l X11 -lXpm -lpng -lz -ljpeg -lz -ldb -lgdbm -lbz2 -lz -lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcrypt -lxml2 -lz -lm 1>&5 /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_sem_post' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_waitpid' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_pthread_sigmask' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `fork1' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_sem_wait' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_sem_init' collect2: ld returned 1 exit status configure: failed program was: #line 47105 "configure"
still seems to need tweaking ...
*** Bug 17136 has been marked as a duplicate of this bug. ***
*** Bug 17815 has been marked as a duplicate of this bug. ***
*** Bug 17904 has been marked as a duplicate of this bug. ***
*** Bug 17939 has been marked as a duplicate of this bug. ***
*** Bug 18202 has been marked as a duplicate of this bug. ***
I've used : env USE="-java" emerge --update dev-php/php and the install was completed successfully
I've just looked at this briefly, but the "Unable to locate /opt/blackdown-jdk-1.4.1/bin" problem was solved for me with an update to php 4.3.1's configure script. Line 37500 reads ``if test "$PHP_JAVA" = "yes"; then''; it should read ``else if test "$PHP_JAVA" = "yes"; then'', since otherwise it is only executed if $PHP_JAVA is already equal to "no", which is obviously bogus. Fixing the ebuild to use JAVA_HOME probably avoids this by getting the configure script to go straight to the last else statement in that section (line 37511), which tests -x $PHP_JAVA/bin/jar directly.
*** Bug 18082 has been marked as a duplicate of this bug. ***
If nobody else has picked this up by wednesday, I'll resolve it then. (That's the 1 day break in my finals).
this has to be fixed before 1.4 feel free to fix it
I think the main problem here is that it's several bugs (although java related) that's been slapped together here. I can only speak of the problem I've seen; namely that ./configure fails when it tries to check for 'Java Jar': checking Java Jar location... configure: error: Unable to locate /opt/blackdown-jre-1.3.1/bin While, obviously the directory '/opt/blackdown-jre-1.3.1/bin' exists: mystique:fredde:/opt/blackdown-jre-1.3.1/bin>ls JavaPluginControlPanel* i386/ java@ [...] The /problem/ is that the configure, as it actually says, checks for the 'jar' binary here. The 'jar' program is not part of the JRE, but actually a part of JDK: mystique:fredde:/opt/blackdown-jdk-1.3.1/bin>ls jar jar@ To fix this, I guess two things needs to be changed: 1) Get the ebuild to use '$JDK_HOME' instead of '$JAVA_HOME'. 2) Get java-config to fill in 'JDK_HOME' in /etc/env.d/20java
Heh, never mind my point #2; '/usr/bin/java-config --set-system-vm=blackdown-jdk-1.3.1' took care of that. Still, the ebuild should check if JDK_HOME is set, and if it isn't; prompt the user to switch system-vm. :)
The next hurdle: checking for fork... no configure: error: pcntl: fork() not supported by this platform (This is the one I reported months ago) Due to blackdown-jdk can't find a couple of references: /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_sem_post' /opt/blackdown-jdk-1.3.1/jre/lib/i386/libjava.so: undefined reference to `jdk_waitpid' [ + a few others ] Could it be a problem with using gcc3 and old version of blackdown java? I'm emerging the latest blackdown-jdk now and see if it behaves the same...
I can confirm success with blackdown-jdk-1.4.1... I did notice that 'java' has disappeared from the IUSE variable for the php-ebuild, though. Intentional?
*** Bug 18985 has been marked as a duplicate of this bug. ***
Using the sun-jdk-1.4.1.02 instead of blackdown fixes this bug for me.
*** Bug 19389 has been marked as a duplicate of this bug. ***
Just got this on a process started this Sunday, on an otherwise up-to-date system (but hadn't installed Apache or mod_ssl or php on it before). Is there a current best work-around for this? I do _not_ have PHP calling any Java - if Java's buggy how about having PHP without it? My impression is people either use one or the other, very rarely both. It stalled with: configure: error: pcntl: fork() not supported by this platform !!! ERROR: dev-php/php-4.3.1 failed. !!! Function econf, Line 273, Exitcode 1 !!! econf failed And farther up I see: checking Java Jar location... /opt/blackdown-jdk-1.3.1/bin/jar cf checking Java C location... /opt/blackdown-jdk-1.3.1/bin/javac checking Checking for libjava... /opt/blackdown-jdk-1.3.1/jre/lib/i386 Hmm ... where's the switch to disable this?
Quick workaround: add "-java" to your USE variables while emerging php.
*** Bug 19781 has been marked as a duplicate of this bug. ***
Follow up from duplicate bug# 19781 based on comments in this bug below accomplished: # emerge blackdown-jdk # env USE="-java" emerge dev-php/php php-4.3.1 appears to have been successfully built as a result php 4.3.1 would not emerge without using the above Additionally, I had to use: # env USE="-java" emerge dev-php/mod_php in order to get an error free emerge for mod_php-4.3.1
Fixed in new PHP eclass to be released very soon. When it is, please test it ASAP.
*** Bug 21999 has been marked as a duplicate of this bug. ***
closing old bugs.
*** Bug 38082 has been marked as a duplicate of this bug. ***
