[03:14] <ryo> hi, i'm trying to install SDK 1.4.2 in my hoary on a macintosh (G3 ppc). I have followed the instructions on the web, but i got this error launching any command:
[03:15] <ryo> JVMXM005: Unable to initialize threads
[03:15] <ryo> Exception  Could not create JVM.
[03:15] <ryo> can someone help me?
[03:22] <jbailey> ryo: It might be expecting the old LinuxThreads library.
[03:22] <jbailey> Your best bet is to use one of the Free VMs and hope that it will do everything you need.
[03:25] <ryo> jbailey: ok, but that sounds really strange, isn't it? i mean, i have found lot of howto explaining how to run eclipse using this VM, but i can't run the compiler at least ;)
[03:25] <jbailey> Oh wiat, you said Hoary.
[03:25] <ryo> (no, it's not my final purpouse, i have to run tomcat with an application)
[03:25] <jbailey> So that's not going to be the problem, we did it for Breezy.
[03:26] <ryo> can I paste 5 lines from strace? I grepped "threads" from the output
[03:26] <jbailey> Yeah, running tomcat could be problematic since we don't have the security manager bits in place yet.
[03:26] <jbailey> Sure, but I may not be able to do much with it even if I see the problem.
[03:27] <ryo>  strace -e open java 2>&1|grep -i thread
[03:27] <ryo> open("/lib/libpthread.so.0", O_RDONLY)  = 3
[03:27] <ryo> open("/opt/IBMJava2-ppc-142/bin/../jre/bin/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
[03:27] <ryo> open("/opt/IBMJava2-ppc-142/jre/bin/classic/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
[03:27] <ryo> open("/opt/IBMJava2-ppc-142/jre/bin/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
[03:27] <ryo> open("/lib/libpthread.so.0", O_RDONLY)  = 3
[03:27] <ryo> JVMXM005: Unable to initialize threads
[03:27] <jbailey> Right, so the final one succeeds.
[03:27] <ryo> yes, it doesn't look for a particular release
[03:28] <jbailey> So without doing thread traces and whatnot, there's not much I can offer you.
[03:29] <jbailey> And those would only serve to let you file bugs against the IBM jvm.
[03:29] <jbailey> Have they published a 1.5 that you can try instead?
[03:29] <ryo> no, this is their last one :/
[03:31] <ryo> jbailey: thank you very much for your support, i'm gonna try my last hope: switch back to 1.3.1 :|
[03:31] <ryo> thanks! bye
[05:40] <wasabi> I need a shell script wizard.
[05:40] <wasabi> jbailey, ? :)
[06:20] <jbailey> Can't right now, need food.
[11:37] <wasabi> jbailey, ping
[11:37] <wasabi> oh maybe n/m
[11:38] <jbailey> wasabi: I'm here now.
[11:38] <wasabi> I'm thinking about the gcj classmap thing.
[11:38] <jbailey> Thinking of going and playing video games, anything I can help with?
[11:38] <wasabi> Just wanted to bounce some ideas off you
[11:38] <wasabi> for cdbs
[11:38] <jbailey> 'sho nuff
[11:38] <wasabi> okay... right now I have as an example package:
[11:38] <wasabi> eclipse-rcp.
[11:39] <wasabi> eclipse-rcp-common and eclipse-rcp-gcj also
[11:39] <jbailey> rcp?
[11:39] <wasabi> rich client platform, just one of the eclipse pieces
[11:39] <wasabi> I
[11:39] <wasabi> I'm thinking about how to hand that information to a dh_* tool to take eclipse-rcp, eclipse-rcp-common and make the mapping with the .so's in eclipse-rcp-gcj
[11:39] <wasabi> Also need to specify directories to use for all of those
[11:40] <wasabi> I'm thinking it may be a debian/packagename.gcj file or something, like .install and .dirs, etc.
[11:40] <jbailey> What doe sthe code that goes into the postinst look like?
[11:41] <wasabi> the postinst is very simple. It's the building of the classmaps that is hard.
[11:41] <wasabi> postisnt just runs /usr/sbin/update-gcj-classpamsp
[11:41] <wasabi> maps
[11:41] <wasabi> classmaps are in /usr/share/gcj-4.0/classmap.d, one per package
[11:41] <jbailey> We figured out that /usr/share is alright, even with jni stuff?
[11:42] <wasabi> THe eclipse thing has .jars in /usr/lib/eclipse/plugins in packages eclipse-rcp and eclipse-rcp-common, and .so's in /usr/lib/eclipse/plugins in eclipse-rcp-gcj
[11:42] <wasabi> Yeah, it's fine.
[11:43] <wasabi> So there's 1 or more files in one or more packages which are mapped to 1 or more files in another package
[11:43] <jbailey> Aren't the names 1:1 ?
[11:44] <wasabi> No.
[11:44] <wasabi> Well, the names are.
[11:44] <wasabi> THe paths aren't.
[11:44] <jbailey> Right.
[11:44] <wasabi> There are .jars in /usr/share and /usr/lib, which map to .so's which are all in /usr/lib
[11:44] <jbailey> Is there any risk of conflicts?
[11:44] <wasabi> such as?
[11:44] <jbailey> Like a version being in /usr/share and another being in /usr/lib?
[11:45] <jbailey> (for jars)
[11:45] <wasabi> Oh, yeah. But that won't hurt anything.
[11:45] <wasabi> Not within the same source package.
[11:45] <jbailey> 'k
[11:45] <wasabi> So let's imagine eclipse-rcp-gcj.gcj
[11:45] <wasabi> it has something like
[11:46] <wasabi> eclipse-rcp:usr/share/eclipse/plugins:usr/lib/eclipse/plugins
[11:46] <wasabi> or equally crazy
[11:46] <wasabi> made up random syntax there.
[11:46] <wasabi> and eclipse-rcp-common:usr/share/eclipse/plugins:usr/lib/eclipse/plugins
[11:47] <wasabi> or maybe \t instead of : to keep inline with other dh files.
[11:47] <jbailey> Well, whitespace, but yeah.
[11:47] <jbailey> So thats BASE:jar:so ?
[11:47] <wasabi> yeah
[11:48] <jbailey> Is the only variant acceptable generally s/share/lib/ ?
[11:48] <wasabi> No.
[11:48] <wasabi> I can imagine some various situations. Some .jar's are platform independent. Some are platform dependent.
[11:48] <wasabi> Somebody might want to package them so the path isn't exactly the same s/share/lib
[11:49] <jbailey> Are 90% of the cases like that?
[11:49] <jbailey> Or do you imagine lots of variation in common cases/
[11:49] <wasabi> yeah
[11:49] <wasabi> 90% would be similar
[11:49] <jbailey> I would do then something like this:
[11:50] <jbailey> usr/share/eclipse/plugins/eclipse-rcp.jar
[11:50] <jbailey> And have it assume it
[11:50] <jbailey> and for the other cases:
[11:50] <wasabi> Hmm?
[11:50] <wasabi> No...
[11:50] <jbailey> usr/share/eclipse/plugins/eclipse-rcp.jar usr/shitbox/foo/eclipse-rcp.so
[11:50] <wasabi> eclipse-rcp is a PACKAGE
[11:50] <wasabi> containing, oh, 10 jars
[11:51] <jbailey> Oh, I see.
[11:51] <jbailey> Does the .so file compile all the jars from one package together?
[11:51] <wasabi> I can see the need for packages which contain both jars and .so files
[11:51] <wasabi> no, seperate .so per jar
[11:52] <wasabi> packages which contain only .so files, and packages which contain .so files which would have mapped to two other packages with jar files.
[11:52] <wasabi> In eclipses case I have every feature broken down into three packages
[11:52] <wasabi> eclipse-name, eclipse-name-common and eclipse-name-gcj
[11:52] <wasabi> eclipse-name is platform-dependent files in /usr/lib/eclipse and symlinks to indep files in /usr/share, eclipse-name-common contains /usr/share/eclipse files which are platform indep.
[11:53] <wasabi> eclipse-name-gcj contain the .so files in /usr/lib/eclipse which may map to either one of hte other packages
[11:53] <jbailey> I think I'd have to play with an example in hand to get it.  Might be just trying to think through the headache I have, though.
[11:53] <wasabi> =)
[11:53] <wasabi> Well,go play games.
[11:54] <jbailey> The idea is that packages might be spread across multiple packages besed on arch:all and arch specific?
[11:54] <jbailey> debian packages, that is.
[11:54] <jbailey> (Feh, overloaded term)
[11:55] <wasabi> yeah
[11:57] <jbailey> Could you do something like:
[11:58] <jbailey> Hmm, lemme think through through.
[11:58] <jbailey> Because all the packages will exist in debian/tmp/usr/share/eclipse/plugins/eclipse-rcp
[11:58] <wasabi> Yeah, you see though.
[11:58] <wasabi> No, this is going to have to be done post install
[11:58] <wasabi> I've already figured that out
[11:59] <jbailey> Generating the classmap?
[11:59] <wasabi> that way the proper jars and .sos have already moved to debian/foo
[11:59] <wasabi> There are like, 100 Jars and .so files all in debian/tmp
[11:59] <wasabi> but some go to one package, some go to another
[11:59] <wasabi> dh_install does that
[11:59] <jbailey> Yeah, but aren't they already broken out by package?
[11:59] <wasabi> No.
[11:59] <jbailey> Oh.
[11:59] <wasabi> THey are all spewed in plugins
[12:00] <wasabi> /usr/lib/ecipse/plugins has every plugin... every Har.
[12:00] <wasabi> Jar
[12:00] <wasabi> Allare associated with a different Eclipse feature.
[12:01] <wasabi> Either the logic about which Jar and .so file exists in which package has to be duplicated for this new routine, or it has to be done after dh_install has taken care of it.
[12:02] <jbailey> make a dh_installjar to handle it in one step?
[12:02] <wasabi> Sure, but it will have to  duplicate everything dh_install does.
[12:02] <wasabi> ANd it'll be a bit confusing to know to put Jars in it
[12:02] <jbailey> Nah, we already have that with things like dh_installman
[12:02] <wasabi> ahh.
[12:03] <jbailey> $ ls dh_install*
[12:03] <jbailey> dh_install            dh_installemacsen    dh_installmime
[12:03] <jbailey> dh_installcatalogs    dh_installexamples   dh_installmodules
[12:03] <jbailey> dh_installchangelogs  dh_installinfo       dh_installpam
[12:03] <jbailey> dh_installcron        dh_installinit       dh_installppp
[12:03] <jbailey> dh_installdeb         dh_installlogcheck   dh_installwm
[12:03] <jbailey> dh_installdebconf     dh_installlogrotate  dh_installxfonts
[12:03] <jbailey> dh_installdefoma      dh_installman        dh_installxmlcatalogs
[12:03] <jbailey> dh_installdirs        dh_installmanpages
[12:03] <jbailey> dh_installdocs        dh_installmenu
[12:04] <wasabi> that's fine then, as long as it supports globs and everything else