bison @3.2.4 does not build on PPC Mac OS X 10.5.8, Leopard, because the Java compiler, /opt/local/libexec/gcc/ppc-apple-darwin9/5.5.0/ecj1, does not find an end and compiles and compiles and compiles and compiles, using some swap space

[ballapete (Peter "Pete" Dyballa)]

  PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
23423 ecj1         0.0%  7:24:32   1    14+   116 1603M+  704K+ 1604M+ 3218M+

-+= 00001 root /sbin/launchd
 \-+- 00431 pete /bin/sh /opt/local/bin/startx
   \-+- 00489 pete xinit /Users/pete/.xinitrc -- /opt/local/bin/X :0 -listen tcp -iglx -dpi 96 -auth /Users/pete/.serverauth.431
     \-+= 00616 pete /opt/local/bin/fluxbox
       \-+- 00656 pete /usr/local/bin/emacs-24.5 -geometry 100x55+696+145 -T 24.5 -fn Lucida Sans Typewriter-7 --debug-init
         \-+= 00666 pete -bin/tcsh -i
           \-+= 00983 root /usr/local/bin/emacs-24.5 -xrm Emacs*iconName: Live-Kastel -xrm Emacs.FontBackend: xft,ftx,x -T Live-Kastel 2013 -geometry 102x53+375+25 -fn Lucida Sans Typewriter-7
             \-+= 01091 root -bin/tcsh -c time port -vd upgrade perl5.26 python37 py27-asn1 py37-lxml apr bison bison-runtime boehmgc git glib2 graphite2 libarchive libgsf libnetpbm libraw libxslt netpbm openldap parallel wget zstd
               \-+- 01100 macports /opt/local/libexec/macports/bin/tclsh8.5 /opt/local/bin/port -vd upgrade perl5.26 python37 py27-asn1 py37-lxml apr bison bison-runtime boehmgc git glib2 graphite2 libarchive libgsf libnetpbm libraw libxslt netpbm openldap parallel wget zstd
                 \-+- 17569 macports sh -c  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_devel_bison/bison-runtime/work/bison-3.2.4" && ./configure --prefix=/opt/local --disable-silent-rules 
                   \-+- 17570 macports /bin/sh ./configure --prefix=/opt/local --disable-silent-rules
                     \-+- 23422 macports gcj -C -d . conftestlib.java
                       \--- 23423 macports /opt/local/libexec/gcc/ppc-apple-darwin9/5.5.0/ecj1 conftestlib.java -g1 -fbootclasspath=./:/opt/local/share/gcc-5/java/libgcj-5.5.0.jar -foutput-class-dir=. -g1 -fsource=1.5 -ftarget=1.5 -fzip-dependency /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_devel_bison/bison-runtime/work/.tmp/ccCmqQQG.zip

pete 234 /\ port select --summary
Name       Selected       Options
====       ========       =======
clang      mp-clang-3.4   mp-clang-3.3 mp-clang-3.4 none
cython     cython27       cython27 none
db         db48           none
gcc        mp-gcc5        apple-gcc42 gcc40 gcc42 llvm-gcc42 mp-gcc49 mp-gcc5 mp-gcc6 none
llvm       mp-llvm-3.4    mp-llvm-3.3 mp-llvm-3.4 none
nosetests  nosetests27    nosetests27 none
pygments   py36-pygments  py37-pygments none
python     python27       python25-apple python27 python37 none
python2    python27       python25-apple python27 none
python3    python37       python37 none

The Portfile does not seem to prescribe a particular compiler, so I am trying to switch to GCC6 and see whether bisoncan be configured.

[ballapete (Peter "Pete" Dyballa)]

Main.log from PPC Leopard with GCC5

[ballapete (Peter "Pete" Dyballa)]

With GCC6 I get at least in a short time

checking for valgrind... no
checking Valgrind suppression file... 
checking for Java compiler... no
checking for Java virtual machine... java
checking that generated files are newer than configure... done

[kencu (Ken)]

I think we just dumped the java compiler in gcc6+ as being useless. so it doesn't even try (there isn't one).

If I understand what you're explaining, this command just hangs, and never returns? :

/opt/local/libexec/gcc/ppc-apple-darwin9/5.5.0/ecj1 conftestlib.java -g1 -fbootclasspath=./:/opt/local/share/gcc-5/java/libgcj-5.5.0.jar -foutput-class-dir=. -g1 -fsource=1.5 -ftarget=1.5 -fzip-dependency /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_devel_bison/bison-runtime/work/.tmp/ccCmqQQG.zip

first thing I would do is try running that command manually in the proper directory and see if it tells you anything useful...

[kencu (Ken)]

You probably sorted this out already, but for a workaround, I found that deactivating gcc5 fixed the build of bison (by getting gcj out of the path). This should be properly sorted out by forcing it not to look for gcj in the first place, but that's for another day...

[ryandesign (Ryan Carsten Schmidt)]

In e99a38a7d1946d134d98594dd9523f00c1c7057e/macports-ports (master):

bison: Do not look for java or valgrind

They don't appear to get used anyway.

Closes: #57858

[ballapete (Peter "Pete" Dyballa)]

Actually I think that /opt/local/libexec/gcc/ppc-apple-darwin9/5.5.0/ecj1 does not work at all. All the other executables in directory /opt/local/libexec/gcc/ppc-apple-darwin9/5.5.0 produce some kind of output when invoked with -v --help. Even jc1 outputs a long list of options (and it seems to pass the test when the last option and its argument are omitted). ejc1 is completely silent. This is also the case when I simulate configure on the command line. Obviously ejc1 only can consume memory and CPU time.

BTW, configure seems to produce these three files with the given contents for the Java Compiler test:

--> conftest.java:
class conftest     { void foo () { switch ("A") {} } }

--> conftestfail.java:
class conftestfail { void foo () { Runnable r = () -> {}; } }

--> conftestlib.java:
public class conftestlib {
  public static void main (String[] args) {
  }
}

config.log contains at its end:

onfigure:39765: checking for Java compiler
configure:39977: found /opt/local/bin/gcj
configure:40011: found /usr/bin/javac
configure:40064: gcj -C -d . conftestlib.java

[ryandesign (Ryan Carsten Schmidt)]

I've fixed bison so that it will no longer look for Java, so I consider this ticket closed.

If ecj1 is completely broken, that might need to be filed as a separate ticket against the gcc5 port.

[kencu (Ken)]

I noticed it was running out of memory doing the compiler test in bison (which says it requires a newer version of java now anyway, BTW).

I think we use gcc5 to build pdftk, with java, don't we? This might just be a specific error with java in bison.

[ryandesign (Ryan Carsten Schmidt)]

Last I checked it worked for pdftk.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign:

If ecj1 is completely broken, that might need to be filed as a separate ticket against the gcc5 port.

I think the GCC Java compilers never worked on PPC. GCC 5 and 6 are not supported any more (7.4 and 8.2 are), so it seems useless to report this bug.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign:

Last I checked it worked for pdftk.

It could not have worked with GCC 5.

I reset my GCC setting to GCC 5 and the build of pdftk led within a minute to abusing all existing virtual memory:

             \-+= 62458 root -bin/tcsh -c time port -vd build pdftk
               \-+- 62467 macports /opt/local/libexec/macports/bin/tclsh8.5 /opt/local/bin/port -vd build pdftk
                 \-+- 62523 macports sh -c  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_pdftk/pdftk/work/pdftk-2.02-dist/pdftk" && /usr/bin/make -w all -f Makefile.OSX-10.6 VERSUFF=-mp-5 
                   \-+- 62524 macports /usr/bin/make -w all -f Makefile.OSX-10.6 VERSUFF=-mp-5
                     \-+- 62529 macports /usr/bin/make -f Makefile -iC /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_pdftk/pdftk/work/pdftk-2.02-dist/pdftk/../java all
                       \-+- 62530 macports /opt/local/bin/gcj-mp-5 -Wall -fsource=1.3 -O2 --encoding=UTF-8 --classpath=/opt/local/share/java/libgcj-5.5.0.jar:/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_pdftk/pdftk/work/pdftk-2.02-dist/java:. -C pdftk/com/lowagie/text/Anchor.java
                         \--- 62531 macports /opt/local/libexec/gcc/ppc-apple-darwin9/5.5.0/ecj1 pdftk/com/lowagie/text/Anchor.java -Wall -fbootclasspath=/opt/local/share/java/libgcj-5.5.0.jar:/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_textproc_pdftk/pdftk/work/pdftk-2.02-dist/java/:./:/opt/local/share/gcc-5/java/libgcj-5.5.0.jar -fencoding=UTF-8 -fsource=1.3 -ftarget=1.5 -fzip-dependency /opt/local/var/macports/build/_opt_local_

[ballapete (Peter "Pete" Dyballa)]

The same failure when I have set:

gcc        mp-gcc6        apple-gcc42 gcc40 gcc42 llvm-gcc42 mp-gcc49 mp-gcc5 mp-gcc6 none

becuase the Portfile seems to dictate the use of GCC5. Main.log attached.

[ballapete (Peter "Pete" Dyballa)]

Main.log from PPC Leopard of pdftk @2.02

[ryandesign (Ryan Carsten Schmidt)]

Replying to ballapete:

I think the GCC Java compilers never worked on PPC.

They certainly worked, at least enough to compile pdftk, back in 2004 when the pdftk port was added to MacPorts, before Intel Macs existed. But it certainly could have broken on PowerPC in newer versions of gcc, and I don't know what would be needed to fix it. In any case, this ticket is closed.