andrewbachmann at gmail.com
Mon Mar 29 14:07:49 PDT 2010
Thanks for trying to get things building. I did run into those
crashes that you're talking about. (we all have, afaik) Here's some
things I've tried:
1. modify the optimization level: sometimes this helped, and sometimes
it didn't (inconsistently)
2. reboot haiku: sometimes helps, and sometimes it didn't (inconsistently)
3. run on real hardware vs. emulation: sometimes helps, and sometimes
it didn't (inconsistently)
4. recompile gcc or try different gcc version: seemed to help (I ended
up using a 4.4.2 build from Joe Protsko)
After I got through at least one build of the libjvm.so and friends, I
turned my attention to the "jdk" side. I put in all the java files
that we had and the C++ files for them, so those are in the
repository. They may not be in exactly the right place. I haven't
modified the makefiles at all so that is an outstanding issue.
I switched gears to try to get the java files compiled on haiku. I
tried to get the latest version of jikes which doesn't have enough
java 5 construct support to help. I was able to modify some of the
java files to remove the java 5-isms and then compile them with jikes.
I didn't feel like modifying all of them by hand so I also looked
into some old-ish java 5-ish compilers like the pizza one and another
Michael Franz suggested using gcj, so I tried my hand at compiling a
gcc that would work for that purpose. I tried to compile gcc with
--enable-threads=posix to help out, but the resulting gcj kept
crashing in the garbage collector. Building gcc is of course no fun,
and I tried to do it "the right way" with bootstrapping, etc., and
that all failed. I ended up trying this:
LIBS=-lnetwork ../configure --prefix=<prefix>
--enable-languages=c,c++,java --disable-nls --disable-shared
--target=i586-pc-haiku --enable-threads=posix --disable-bootstrap
I'd prefer to do the bootstrap because if gcc can't bootstrap, well I
don't have too much confidence in what I just built. Also I'm not
clear on why the precompiled header stuff doesn't work.
I reported a bug against gcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42474 relating to the
linemap_lookup I didn't spend much time characterizing the behavior,
but I somewhat do believe that this is related to haiku library
loading and initialization. It may be possible to come up with a
small test case that would exercise the behavior, if that is the case.
In that case I would guess it has something do with ensuring that the
static variables for a .o are initialized when the .o is loaded into
memory, but this is not really anywhere near my area of expertise.
Looking at the code, it seems difficult to understand how the variable
could not be initialized when you get to linemap_lookup. (and it
seems like it is unitialized, not just NULL) This might be related to
signals too, so there's more fun there.
I haven't worked on the "jdk" compilation much for the past few
months. Last I checked Mike tried to building remote + nfs mounting
but couldn't get the nfs mount to work well enough. Options I still
haven't checked include using remote + ssh file access on my macbook.
I also wanted to try doing some syntax transforms on the java in the
openjdk to make it jikes compatible. I downloaded but haven't tried
some of the following:
I'm something of a purist when it comes to bootstrapping, so I'm
trying to get it all going native. However, my level of optimism is
declining, so I am approaching the "try to build someplace else". I
don't have a linux machine handy any longer and the last time I tried
to build on windows I didn't even manage to get the right software.
(compiler version, etc.) I think that situation (windows) is improved
but I didn't want to spend my effort there. Aside from the class
files for the shared code, we probably also have to get class files
for some of the haiku specific stuff. On the positive side, we can
probably build that part native. So, if anyone is inclined to doing
that, I will try to assist.
More information about the haiku-port-dev