Public SourceMage Discussion List

[Sukneet Basuta <sukneet AT gmail.com>]

On Thu, Jan 31, 2013 at 12:47 AM, Javier Vasquez
<j.e.vasquez.v AT gmail.com> wrote:
> Hi,
>
> I moved the pentium-m (centrino) laptop from generic i686 to pentium-m arch.
>
> Everything compiled/installed OK except for antlr, ant, rhino and icedtea7.
>
> The alternative I had with jdk7-bin no longer works, it seems it's not
> compatible with the resulting glibc dynamic library (so).  Just doing
> "java -version" with the i586 version from oracle fails, and it does
> it with a similar failure compiling rhino with icedtea7 does...
>
> Any ways, compiling the spells depending upon a jdk such as antlr, ant
> and rhino, with icedtea7 fails.  For example antlr:
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> /usr/bin/make -C ./antlr all
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> make[1]: Entering directory `/usr/src/antlr-2.7.7/antlr'
> *** compiling 216 Java file(s)
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0xb7589e70, pid=14517, tid=3063679808
> #
> # JRE version: 7.0_09-b30
> # Java VM: OpenJDK Client VM (23.2-b09 mixed mode linux-x86 )
> # Problematic frame:
> # C  [libc.so.6+0x87e70]  two_way_long_needle+0x50
> #
> # Failed to write core dump. Core dumps have been disabled. To enable
> core dumping, try "ulimit -c unlimited" before starting Java again
>
> As I said I get a pretty similar failure with "java -version" on the
> oracle binary...
>
> But with icedtea7 I can run "java -version" without that error:
>
> % java -version
> java version "1.7.0_09"
> OpenJDK Runtime Environment (IcedTea7 2.3.3) (Source Mage build 
> 1.7.0_09-b30)
> OpenJDK Client VM (build 23.2-b09, mixed mode)
>
> % which java
> /usr/lib/j2sdk/bin/java
>
> However this icedtea7 is broken, one because I recompiled everything,
> so the dynamic libraries it was compiled against changed, and second,
> cause cleanse says it so, :-)
>
> Any ways, when trying to recompile icedtea7, so I can then recompile
> its dependent spells, to then try recompiling icedtea7 again, the
> "configure" process just hangs forever when trying to discard ecj, and
> there's no ecj whatsoever for sure:
>
> What alternatives are there (seems like compiling doesn't work, and
> the binary oracle version doesn't work.  So once more I'm in the dark,
> and browsing the web doesn't seem to help, :-(

You can try IBM's jdk and see if that works. It's generally pretty
compatible and works better on low mem systems.

> Perhaps someone has a pentium-m binary version of icedtea7 I can
> attempt resurrect on this laptop?
>
> Weird thing I did something similar on a core-i7 (sandy bridge), which
> I configured by suggestion as native x86-64 with 64 bits, and I didn't
> have any problems recompiling icedtea7 there.  So it might be an arch
> issue...
>
> Any ways, here it's where the configure just hangs forever:
>
> checking if /usr/bin/ecj is a valid executable file... checking for ecj... 
> no
> checking for ecj-3.1... no
> checking for ecj-3.2... no
> checking for ecj-3.3... no
> checking for ecj-3.4... no
> checking if we are using ecj as javac...

Is there a --without-ecj configure option? If so try that. However, it
could be that javac is hanging or something, given your error with
java.

> I'm really clueless.  Any hint is helpful.  BTW, I didn't find any
> native x86-32 arch, only x86-64 with whether 64 or 32 bits, but that's
> not x86-32.  So pentium-m is the closer arch to what the CPU is:

native-x86_64-32 is what you want. I'm not sure why its labelled as
such, but I suppose it's because -march=native doesn't work on all
architectures. However, it should work for all x86 architectures, as
stated in the description of the archspec.

> Again, any hint?  This laptop for now is javaless, and it requires
> java for some accounts (even though it has been said dangerous), well
> for that at least the web plugin...  BTW, I'm not like going and
> recompile everything again, this thing has only 512 MB, and it lasts a
> lot on "sorcery -r", and prior to that the safe recompile of
> gcc/gettext/glibc and company...  Also, it seems the rest of spells
> are OK, well, at least according to cleanse...
>
> Thanks,
>
> --
> Javier.