| Summary: | dev-java/icedtea-bin: convert to multilib | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Christoph Junghans (RETIRED) <junghans> |
| Component: | [OLD] Java | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mmokrejs, multilib+disabled, nicolasbock, z23 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=474910 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 510180 | ||
| Attachments: | patch against gx86 | ||
|
Description
Christoph Junghans (RETIRED)
2015-02-12 20:36:31 UTC
I suppose it would, yes. But don't hold your breath, there's a lot that needs doing right now. Feel free to attempt it yourself. I need a oracle 32-bit run-time for my 32-bit firefox-bin (bug #474910). Should I give the porting of dev-java/oracle-jre-bin to multilib a go? I actually forgot about this bug when I masked emul-linux-x86-java, sorry about that. I really don't want to take this step unless we really need to and if it's about the Juniper VPN stuff, somebody else already contacted me about that. I pointed him to OpenConnect, which very recently gained Juniper support. I've yet to hear if he was successful in trying it but I hope you'll agree that this is a much nicer solution. http://www.infradead.org/openconnect/ Oh and the latest version is already in the tree. The version of Juniper I am using is modified and I am not sure how easy it is to be ported to OpenConnect. I'm not sure what you mean by modified but I'd appreciate if you could contact upstream about it. Maybe it could benefit others? (In reply to James Le Cuirot from comment #6) > I'm not sure what you mean by modified but I'd appreciate if you could > contact upstream about it. Maybe it could benefit others? No, my version is company-branded and changing it is out of question! (In reply to Christoph Junghans from comment #7) > (In reply to James Le Cuirot from comment #6) > > I'm not sure what you mean by modified but I'd appreciate if you could > > contact upstream about it. Maybe it could benefit others? > No, my version is company-branded and changing it is out of question! I didn't say you should change it but even if it is branded, I doubt that fundamentally changes how it works. You're probably not the only ones that have it branded either. Maybe OpenConnect could be adjusted to accommodate that somehow. I don't mean to create trouble for you and if you still want to give multilib a go then be my guest. I was actually thinking that it would be icedtea rather than Oracle that we would apply this to but I guess Oracle would be easier. Created attachment 401492 [details, diff] patch against gx86 (In reply to James Le Cuirot from comment #8) > I don't mean to create trouble for you and if you still want to give > multilib a go then be my guest. I was actually thinking that it would be > icedtea rather than Oracle that we would apply this to but I guess Oracle > would be easier. Here is my 1st attempt, things to improve: - localizing VMHANDLE is a bit hackish, but it is used inside many if not all java-vm functions - using VMHANDLE=emul-linux-x86*, is a hack to work around an some hard-coding multilib detection inside java-nsplugin.eselect of app-eselect/eselect-java. - in oracle-jre-bin-1.[78].env JAVA_HOME is hard-coded to be /opt/@P@, and @P@ always gets replaced by ${P}, hence a temporary sed was need to work around that. ping @ chewi! Don't panic, I won't be removing emul-linux-x86-java until this is sorted. Currently busy getting icedtea in shape because people are complaining about Oracle fetch restrictions. (In reply to James Le Cuirot from comment #11) > Don't panic, I won't be removing emul-linux-x86-java until this is sorted. > Currently busy getting icedtea in shape because people are complaining about > Oracle fetch restrictions. No problem, I was testing this with my juniper vpn last week and it works. I think we should come up with a new naming scheme for the multilib version (e.g. ${PN}-multilib or ${PN}-${ABI}) and bump app-eselect/eselect-java first to use these as 32-bit version instead of emul-linux-x86*. Just touching base. First off, I agree with the above so I'll make any necessary changes. I've now got the new icedtea and icedtea-bin in the tree. Working with icedtea made me wonder whether I should still apply this to icedtea-bin rather than Oracle's. I'll do a little experiment when I bump icedtea-web. Unfortunately mgorny got a little overenthusiastic with his tree-cleaning and removed emul-linux-x86-java before I had a chance to deal with this. Hopefully this won't inconvenience you in the short term. Just don't unmerge it! ;) (In reply to James Le Cuirot from comment #14) > Unfortunately mgorny got a little overenthusiastic with his tree-cleaning > and removed emul-linux-x86-java before I had a chance to deal with this. > Hopefully this won't inconvenience you in the short term. Just don't unmerge > it! ;) Hi, I also need a 32-bit java for an application (jMRUI). Please don't forget completely about it! ;) Ingo (In reply to is from comment #15) > I also need a 32-bit java for an application (jMRUI). Please don't forget > completely about it! ;) I haven't, just struggling to get to it. Believe it or not, I've made a little progress on this. I've done a lot of experimentation and found that a 64-bit icedtea-web plugin can launch a 32-bit VM. You can ditch your 32-bit browsers now! For this reason, and also in the name of simplification, I have killed eselect java-nsplugin. I just need to apply the multilib logic to icedtea-bin and all you'll need to do then is select the 32-bit variant through itweb-settings. You could also select it with eselect of the GENTOO_VM environment variable but this is not recommended. Sorry if it ends up taking a bit longer yet. In the meanwhile, we got migrated to junos pulse, so I don't really need this anymore. Feel free to close. (In reply to Christoph Junghans from comment #18) > In the meanwhile, we got migrated to junos pulse, so I don't really need > this anymore. Feel free to close. You weren't the only one asking so I'll keep it open. Sorry it didn't happen sooner. I'm surprised by the ever-increasing number of people asking for this. The earlier icedtea-web changes have now been stabilised so I feel even more compelled to close this out. I discovered a while back that OpenJDK and derivatives support the idea of mixing platform-specific binaries within the same tree. You normally have a directory like jre/lib/amd64 and this can live alongside jre/lib/i386. But what about the executables? As well as jre/bin, it will also look in jre/bin/i386, for example. This would have been ideal except that my own testing found that rt.jar isn't as cross-platform as it should be. If you try to do anything AWT-related, it segfaults. I had been under the impression that this would be fixed in Java 8 but it wasn't. Perhaps it was Java 9, where rt.jar doesn't even exist any more. I have managed to come up with a workaround though. Converting the icedtea-bin ebuild to multilib in a way that doesn't make it hellishly ugly is harder than you might think. At the moment, the above mixed tree approach may end up being less hassle than putting the 32-bit stuff in an entirely different directory. It'll certainly use less disk space anyway. I'll see how it plays out. This is finally done! Both in icedtea-bin:7 and icedtea-bin:8. In the end, I put things in a separate directory because I realised that putting them in the same directory would break a manually-configured icedtea-web and anything else using JAVA_HOME. Most of the content is symlinked though. Hope this helps. Sorry for the stupidly long wait. |