Bison @2.4.3 configure test for gcj can take excessive time and memory

[chicagotripp (Altoine Barker)]

I have attempted to upgrade bison on my system and find myself failing/stalling in the config phase after checking for java on my system. The exact message shows:

checking how to link with libintl... -lintl -liconv -lc  -Wl,-framework -Wl,CoreFoundation
checking for valgrind... no
checking whether we are using the GNU C++ compiler... yes
checking whether /usr/bin/g++-4.0 accepts -g... yes
checking dependency style of /usr/bin/g++-4.0... gcc3
checking whether /usr/bin/g++-4.0 builds executables that work... yes
checking for Java virtual machine... java

I have cleaned the port and then attempted to upgrade the port from bison 2.4.2 to bison 2.4.3 with the same result. I had let this issue sit for over 24 hour periods, twice! And still the same result.

My system is a PowerPC G5 Dual running Mac OSX 10.5.8 using MacPorts 1.9.2.

[jmroot (Joshua Root)]

I can't reproduce on the same hardware and OS. Attach the log files generated by both macports (look under /opt/local/var/macports/logs) and autoconf (look for config.log under the directory given by port work bison).

[chicagotripp (Altoine Barker)]

bison config file

[chicagotripp (Altoine Barker)]

bison logs file

[chicagotripp (Altoine Barker)]

Replying to jmr@…:

I can't reproduce on the same hardware and OS. Attach the log files generated by both macports (look under /opt/local/var/macports/logs) and autoconf (look for config.log under the directory given by port work bison).

I did some different actions to find a resolution:

My first solution attempt was to deactivate bison-2.4.2, clean the bison port, and then choose to install bison-2.4.3 but that produced the same result which is no success.

My second solution attempt was to choose gcc42 from gcc_select and then do all the steps listed above. That worked. I wish there was a way to tell what gcc I had selected before I did the change. The files listed above are the files before I attempted to do the second solution. My steps:

sudo gcc_select gcc42
sudo port -d deactivate bison
sudo port -d clean --work bison
sudo port -d install bison

These are the gcc version I have installed on my system:

gcc_select -l
Available versions:
gcc40 gcc42 llvm-gcc42 mp-gcc42 mp-gcc45

In conclusion my problem is solved. Thank you for your editing and quick response.

[jmroot (Joshua Root)]

So this was the problem:

configure:21491: checking for Java compiler
configure:21697: found /opt/local/bin/gcj
configure:21731: found /usr/bin/javac
configure:21784: gcj -C -d . conftestlib.java
GC Warning: Repeated allocation of very large block (appr. size 1048576000):
	May lead to memory leak and poor performance.
GC Warning: Out of Memory!  Returning NIL!

It would be best to tell the configure script not to use gcj at all, since there's no dependency declared.

[ilia_2s@…]

I got same problems not for bison only but for other different ports and sources. I fixed this bu changing default compiler throught gcc_select.

[reeskm (Rees Machtemes)]

Update: it seems that bison is very sensitive to how your gcc_select is set.

I recently compiled mp-gcc-4.7 on my system for fun. I made it the default using "port select gcc set mp-gcc-4.7". It works great until now, when I needed to update bison.

This bug kept occuring despite me setting the portfile to use gcc-4.2 explicitly or using a command line switch of -configure.compiler=apple-gcc-4.2! I was surprised to find that if I set my "port select gcc" back to apple-gcc-4.2 the problem went away.

Oh, my system is a Quad G5 powerpc, for info, running 10.5.8 and the latest macports.

[larryv (Lawrence Velázquez)]

Replying to reeskm@…:

This bug kept occuring despite me setting the portfile to use gcc-4.2 explicitly or using a command line switch of -configure.compiler=apple-gcc-4.2! I was surprised to find that if I set my "port select gcc" back to apple-gcc-4.2 the problem went away.

Then bison should be fixed so it uses the right compiler.

[larryv (Lawrence Velázquez)]

I updated bison to 3.0.4 in r134201. Is this still an issue?

[larryv (Lawrence Velázquez)]

I’m going to assume that this is no longer an issue. Feel free to re-open if necessary.