New os.arch namespace Architecture
icedtea and icedtea-web provide java, javaws and plugin support to many new OS architecture and ABI combinations. This calls for the need of a redesigned os.arch namespace Architecture to support loading of native JNI in Java code JNLP and Applets.
1 JDK 8 optional build instruction
Please note that https://bugs.openjdk.java.net/browse/JDK-8009195 Description Certain build time changes are required in order to populate sun.arch.abi Java Property (introduced with JDK-8005545):
a) JDK_ARCH_ABI_PROP_NAME=foo is either passed as a make variable, or set in the environment; and b) --with-extra-cflags is used to pass -DJDK_ARCH_ABI_PROP_NAME=foo
Those instructions need to be documented in JDK8 README-build.html
2 2013-02-27 Resolved Date
There is a new system property called sun.arch.abi in Java 8: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005545
Solution I propose adding a new JDK specific System property that can be used to provide ABI specific information beyond the basic os.arch values for ARM as well as other processor architectures. This property will be optional.
This property, if set, will contain the industry standard toolchain ABI substring that defines the ABI that the current running Java process is using for its native binaries.
Here are some ARM specific examples:
gnueabi GNU softfp EABI gnueabihf GNU hard float EABI androideabi Android EABI
This sun.arch.abi property, if available, will also be added to the "release" file located in the top level JRE directory as SUN_ARCH_ABI.
In addition to the addition of sun.arch.abi, I'd like to see our Linux support for all platforms modified to set the already existing property sun.cpu.isalist to the cpu features found in /proc/cpuinfo. This will allow developers to understand more specifics about the CPU their application is running on. This property is currently NULL for all Linux platforms.
3 2013-02-08 Rasberry pi forum - workaround/solutions for jdk 6 & 7 - how to determine armel vs armhf
4 2013-01-08 porters-dev Email discussion
http://mail.openjdk.java.net/pipermail/porters-dev/2013-January/000415.html - New CPU & OS Platform System Properties
5 2012-03-28 IRC discussion
#openjdk irc.oftc.net 2012-03-28 (14:32:28) xranby: aph: i have a hard problem. on arm i would like to know which abi my system are using from java armel or armhf so that i can load the correct jni lib (14:32:41) xranby: the problem are that os.arch contains too little information (14:33:21) aph: xranby: isn't the default library path different? (14:33:43) xranby: it does not matter if i run a javaws jnlp file (14:34:07) xranby: then i wil not load from the default library paths, the jni code gets loaded from a jar (14:34:14) aph: xranby: ah, where are you running this from? (14:34:33) aph: ok, so java calls jni, right? (14:34:35) xranby: signed jars from http://jogamp.org/ (14:34:48) aph: ok, so let's back up a little bit (14:34:52) aph: need more info (14:34:52) xranby: we are trying to update jogamp to support armhf (14:35:04) aph: so, the signed jar contains jni code? (14:35:15) xranby: yes the signed jar contains jni code (14:35:20) xranby: one armel version and one armhf version (14:35:33) xranby: i have to determine at runtime which one to load (14:35:34) aph: how are they distinguished? (14:35:39) xranby: if i load the wrong one java crash (14:35:46) xranby: usually (14:35:48) aph: different names? different dirs? (14:35:53) aph: ok (14:36:10) xranby: the system looks ar the os.arch property to find out if i am running on a arm x86 x86_64 ppc system (14:36:20) xranby: and loads the correct jni lib (14:36:21) xranby: but on arm (14:36:25) aph: so, the java code calls loadlibrary("name"), right ? (14:36:26) xranby: we have two arm variants (14:36:32) xranby: yes (14:37:12) xranby: the java code sets the name string and loads the lib (14:37:26) xranby: each precompiled lib have a different name (14:37:43) aph: so, where's the problem? you just ask the loadlibrary to load the correct one (14:37:58) xranby: here lies the problem. how can i find out if i am running on a armhf system? (14:38:00) aph: or are you telling me there is no command to tell you which ABI this program is using? (14:38:32) xranby: how can i tell from inside java which abi my system are using? softfp or hard? (14:38:33) aph: there must be surely. unless this is another debian screwup (14:38:48) xranby: uname -a looks the same (14:38:53) xranby: the linux kernel aer the same (14:39:05) xranby: its only the userspace binarys that are different (14:39:10) xranby: this code have to work on fedora as well (14:40:24) xranby: if hotspot got extended to have a os.arch.abi property then i would be able to look at that (14:40:36) xranby: but that would need a JEP i think (14:40:53) aph: xranby: hmmm, I see. This is a property of userspace (14:41:27) aph: xranby: I think there's nothing for it except to look at the elf header (14:42:48) aph: xranby: here's an experiment (14:43:00) doko: indeed, and the glibc patches from Linaro are not yet submitted upstream :/ (14:43:04) aph: xranby: do "readelf -h file" on both of the jni libs (14:43:36) aph: xranby: and? (14:44:02) aph: he's gone to sleep :-( (14:44:18) xranby: i am here (14:44:26) xranby: i am cross chatting with sgothel in jogamp (14:44:31) aph: ok, so are they different? (14:44:38) aph: nevr mind him, talk to me :-) (14:45:00) doko: xranby: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/eglibc/precise/view/head:/debian/patches/arm/unsubmitted-ldconfig-cache-abi.diff (14:45:14) doko: and http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/eglibc/precise/view/head:/debian/patches/arm/unsubmitted-ldso-abi-check.diff (14:45:52) aph: doko: ok, but what does all that stuff do? (14:46:16) aph: doko: ah, complains if it's the wrong abi (14:46:17) mjw: I think in theory a ClassLoader can implement/override ClassLoader.findLibrary() to provide the correct path (14:46:29) aph: mjw: that's not the problem (14:46:32) aph: xranby: please! (14:46:39) doko: + section headers looking for the ARM attributes section, then (14:46:39) doko: + check the VFP_ARGS attribute. */ (14:46:47) doko: /* Check consistency of ABI in the ARM attributes. Search through the (14:46:53) mjw: That together with System.mapLibraryName() should be all there is on the java side to get the right arch/abi variant (14:47:27) aph: mjw: System.mapLibraryName() checks the ABI? (14:47:53) xranby: aph: please patient i do not have the binarys on my machine they exist on the jogamp buildbot right now sgothel tried your test but he claim "nothing that jumps out in my face they look the same" (14:48:06) aph: I assume he's diffed them (14:48:12) mjw: aph, it could... "The manner in which a library name is mapped to the actual system library is system dependent." (14:48:17) mjw: so it depends on the implementation (14:48:24) mjw: that is why I said in theory :) (14:48:27) aph: mjw: ok, so "should" is wishful thinking on your part# (14:48:39) aph: "it would be nice if" (14:49:00) aph: xranby: this line should differ: (14:49:01) aph: Flags: 0x5000002, has entry point, Version5 EABI (14:49:02) mjw: But since we do hack on core classes, we could provide one that does correct (for some definition of correct) mapping for different ARM ABIs (14:49:33) aph: mjw: well, yes, we could, but it's be nice to be able to do it now (14:49:43) doko: aph: which flag is this? (14:50:25) xranby: http://paste.ubuntu.com/903831/ (14:51:05) aph: xranby: OK, that's your answer. use proc/self/exe and look at the flag (14:51:25) aph: xranby: until someone has a better idea (14:51:59) xranby: ok will try (14:52:05) xranby: doko: thanks for the heads up (14:52:18) aph: the header bits should have been different, but the ELF maintainers seem not to have done that . I remember noticing this a while back and thinking Uh?" (14:52:21) xranby: that glibc will stop crashing if i load the wrong lib (14:54:24) aph: xranby: anyway, I don't think you'll find an easier way to do it than "readelf -A /proc/self/exe | grep Tag_ABI_VFP_args" (14:54:33) aph: it's just a one-liner (14:55:35) xranby: aph: thank you to fix this properly java must be redesigned to be able to detect multiple abi on one arch (14:56:23) xranby: right now all jni users are forced to inspect the system ;. not ideal (14:56:33) aph: xranby: I guess. It's rather horrible having to put JNI code for every arch into an archive (14:56:34) xranby: but i agree i have no better idea how to fix it (14:56:56) aph: it's a losing situation whichever way you look at it (14:57:09) xranby: can gcc generate fat binarys? (14:57:14) xranby: with both armhf and armel? (14:57:16) aph: xranby: hell, no! (14:57:20) xranby: softfp and hard (14:57:23) xranby: heh :) (14:57:35) xranby: it would solve this jni problem for javaws users (14:57:36) aph: xranby: it's not /proc/self/exe, it's /proc/<pid>exe (14:57:49) aph: you have to get the pid of the running java implementation (14:58:07) aph: not the subshell (14:58:44) aph: xranby: actually, java doesn't need to do it at all; if the shared library loader does the right thing, it should just find the correct one (14:59:05) aph: xranby: that's the right way to do it (14:59:12) aph: java doesn't need to know (15:00:24) xranby: i dont understand, in the end you still have to compile n jni libs one for each arch.os.abi combination (15:00:30) xranby: and name the different libs somehow (15:00:36) xranby: place them in a jar (15:01:00) xranby: and have System.loadLIbrary load the correct one automagically (15:01:30) aph: sure, so you give it a path and it'll find the one that works (15:01:47) aph: the laoder should be able to do that already (15:01:48) xranby: hum.. i cant put 5 libs under the same name (15:01:58) aph: exactly; it's a design problem (15:02:07) aph: but you can load them until one works (15:02:26) sgothel [~email@example.com] kom in i rummet. (15:02:27) xranby: right now its not possible since glibc crash (15:02:32) xranby: if i load the wrong one (15:02:37) aph: correct: it's a bug in ld.so (15:02:44) aph: so you have to work around it (15:03:24) sgothel: joining the armhf discussion - IMHO 'os.arch' is broken (unusable) on armhf anyways, so why not adding 'hf' suffix to it. This would enable it for JNLP and all others ? (15:03:40) sgothel: Plus it would not have a name collision with 'arm' (15:03:52) sgothel: The latter already implied ARMEL .. (15:04:14) doko: sgothel, which one, old ABI, or EABI? :) (15:04:23) sgothel: good question :) (15:04:39) aph: sgothel: are you saying we need a time machine? it'd be nice... (15:05:07) sgothel: so it's at least true that 'os.arch' shall be fixed somehow to be usefull - maybe expose the whole tripple or something ? (15:05:07) xranby: sgothel: hi and welcome (15:05:25) sgothel: hi .. thx (15:06:03) xranby: doko: since upstram java only supports armel (15:06:12) xranby: and java only pass the TCk on armel (15:06:19) sgothel: than 'arm' in os.arch is ARMEL by definition (15:06:21) xranby: i would be assuming arm means amrel (15:06:22) xranby: armel (15:06:27) sgothel: yup (15:06:33) sgothel: so 'armhf' .. duh :) (15:07:00) sgothel: guess this would require a os.arch spec .. some documentation about its real meaning (15:07:06) xranby: armel = softfp (15:07:42) xranby: doko: so i think arm means EABI softfp (15:07:50) aph: sgothel: it's very complex because there's a combination of attributes. there are many combinations. it's not just hf and non-hf (15:07:57) sgothel: what I can say is, it's not a solution to query the system at 'runtime' from a Java Applet/Webstart .. to figure out which JNI lib to load (15:08:08) sgothel: understood (15:08:10) aph: there's v5, v7, v7 with vfp, etc, etc (15:08:15) sgothel: yup yup (15:08:34) aph: so the only sane way to do this is to get ld.so do the searching (15:08:39) sgothel: I know, we gather through them in GlueGen/JogAmp .. to figure that out .. assuming those are ARMEL (15:08:41) xranby: doko: will these ldsoabi check patched make it into precise? (15:09:26) sgothel: I disagree here .. the openjdk build itself knows what it is and can eg expose it at runtime, either enhancing os.arch or adding os.arch.abi (15:09:59) doko: xranby, they are (15:10:30) sgothel: you cannot query anything native at Java runtime really w/o having a JNI lib loaded (15:11:00) aph: sgothel: so what would the abi be? nothing but a list of the elf flags, IMO (15:11:04) sgothel: in JNLP you define your JNI libs by the 'arch' tag .. (15:11:11) xranby: on x86 and ppc we have this funny 32 bit 64 bit property (15:11:13) aph: and does a native packager need to put every combination int oa jar? (15:11:21) sgothel: as long we can differ it .. identify it (15:11:23) peteb-away [~firstname.lastname@example.org] kom in i rummet. (15:11:38) sgothel: in JNLP world .. you already have to do so ! (15:11:48) sgothel: example: (15:12:21) sgothel: <resources os="Linux" arch="amd64"> (15:12:21) sgothel: <nativelib href = "jar/jogl-all-natives-linux-amd64.jar" /> (15:12:21) sgothel: </resources> (15:12:21) sgothel: <resources os="Linux" arch="x86_64"> (15:12:21) sgothel: <nativelib href = "jar/jogl-all-natives-linux-amd64.jar" /> (15:12:22) sgothel: </resources> (15:12:41) sgothel: arch is 'os.arch' here .. (15:12:51) sgothel: and the JNLP loader does this decision .. (15:13:13) sgothel: In JogAmp we have our own loader now, based on a similar mechanism .. (15:13:14) aph: is this proprietary code? (15:13:24) sgothel: the above is std JNLP :) (15:13:25) aph: it looks like free sftware, but I can't tell (15:13:31) xranby: aph: there exist in implementation in icedtea-web to handle this (15:13:37) sgothel: JogAmp is free software .. (15:13:44) xranby: icedtea-web parse jnlp (15:13:52) aph: so, why not just package it correctly? I really don't get it now (15:13:56) sgothel: JNLP spec is a 'std' (15:14:03) sgothel: ok .. situation .. (15:14:18) sgothel: you package it all a.jar a-native-<os.and.arch>.jar (15:14:29) sgothel: you have multiple native jars for JNLP (15:14:39) sgothel: your JNLP file tells the loader what to load .. (15:14:52) sgothel: so you have a thing running on all systems .. (15:15:04) sgothel: loading the appropriate native jar (15:15:21) sgothel: this is defined w/ Applets and Webstart (15:15:26) aph: sure, I get the idea. seems unspeakably evil, and that's why elluminate failed to work last time I tried to run it on a 64-bit system (15:15:30) sgothel: used for many years right now .. (15:15:38) aph: because it loaded 32-bit libs (15:15:43) aph: probably fixed now :-) (15:16:17) sgothel: ok .. so we understand that a unique 'os.arch' itself or in combination with a new 'os.arch.abi' is required (15:16:25) aph: we don't (15:16:43) xranby: how do jnlp differentiate 32bit and 64bit x86 and ppc binarys? (15:16:48) aph: I still say it makes more sense simply to search for a library that works (15:16:51) sgothel: w/o such a thing .. neither Applets, JNLP .. or others can do it .. (15:16:59) sgothel: read my example above .. (15:17:05) sgothel: ok .. (15:17:18) sgothel: <resources os="Linux" arch="x86"> (15:17:18) sgothel: <nativelib href = "jar/jogl-all-natives-linux-i586.jar" /> (15:17:18) sgothel: </resources> (15:17:18) sgothel: <resources os="Linux" arch="amd64"> (15:17:18) sgothel: <nativelib href = "jar/jogl-all-natives-linux-amd64.jar" /> (15:17:20) sgothel: </resources> (15:17:28) sgothel: it's all in the 'os.arch' (15:17:42) sgothel: without the ARMHF .. it's unique today (15:17:43) xranby: obviously this was not enough since it loaded a 32bit jar on aph's system :) (15:17:58) sgothel: then it's a bug in their JNLP .. or something (15:18:02) aph: sure (15:18:27) aph: but it would require an enumeration of the ARM ABIs (15:18:34) aph: and the situation is much worse (15:18:50) sgothel: more complex reflecting the real world .. which is complex (15:19:15) sgothel: lets say .. os.arch has a use-case, to load the JNI lib .. in this regard, it's broken (15:19:39) aph: true enough. however, it's a matter of controlling the complexity rather than multiplying it... (15:20:05) sgothel: in the end .. you need to know it (15:20:19) aph: I don't think you do (15:20:19) sgothel: sure you could say 'lets use fat binaries' .. but I don't know :) (15:20:31) aph: no, just iterate through all the libs until one is accepted. (15:20:39) aph: that way you don't need all this crud (15:20:50) sgothel: nobody iterates through the libs (15:21:00) sgothel: you just read os.arch and pick the right lib (15:21:06) sgothel: load it .. done (15:21:19) sgothel: don't understand the hesitation quite right (15:21:28) aph: and every time a new arch comes along you have to manually edit that xml (15:21:32) aph: it's broken (15:21:39) sgothel: yes .. you need to do that (15:21:48) sgothel: you need to provide a build for it (15:21:54) sgothel: etc (15:22:13) aph: yeah, I do get it. It's just horribly badly engineered; fragil, high maintanance, etc (15:22:25) sgothel: I am not discussing the pro/con of os.arch itself .. and how to provide native libs for all the platforms .. (15:22:32) aph: sure, I know (15:22:39) sgothel: you propose to have it on the fly ? (15:22:54) sgothel: an ABI converter ? (15:23:59) aph: there is no nice solution, given the approach taken by jnlp (15:24:19) aph: but it can't be used today (15:24:24) sgothel: so I am here to just merely make os.arch unique again .. to be able to use it on armhf .. (15:24:49) sgothel: right now, we query some properties and guess whether it's armhf .. very bad :) (15:24:55) aph: but that's *hard* (15:25:05) aph: what should the format be? (15:25:20) aph: simply adding armhf just delays the next time (15:25:25) sgothel: the simplest thing IMHO would be to add 'hf' to what we have now (15:25:30) sgothel: maybe (15:25:31) aph: and it's not just armhf (15:25:40) sgothel: armv7hf (15:25:50) sgothel: next time it might be armv7lala (15:25:51) omajid_away är nu känd som omajid (15:25:53) aph: how many vfp registers? etc. (15:26:00) aph: there are many many variants (15:26:08) aph: each manuf makes a different version (15:26:13) doko: why encode v7? it's not part of the abi (15:26:20) sgothel: well .. sure, we need to boil it down to compatible builds (15:26:29) aph: doko: not officially, no (15:26:30) sgothel: just an example .. (15:26:57) aph: sgothel: right, so we have a design problem to design a namespace (15:27:06) sgothel: yup (15:27:12) aph: that somehow encompasses all these, er, features (15:27:26) sgothel: which shall fit in the current os.arch scheme .. or create a new one (15:27:30) xranby: its kind of fun.. sun did not release a plugin with 64bit suport untill 2008 (15:27:52) aph: which may or may not be easier than doing the right thing,which is giving the system a bunch of files and letting it choose one that works (15:28:01) xranby: i will take a look if they left any idea hhow to redesign it to handle all the new architectures (15:28:05) sgothel: os.arch.new .. for example, if exists .. use that w/ new namespace .. (15:28:15) sgothel: cool (15:28:43) aph: I've had an idea (15:28:51) aph: how about a trampoline (15:28:52) sgothel: for me it's like 'babysteps' .. to do the right thing - so maybe a short term solution, and a long term one w/ new namespace (15:29:13) dbhole_ [~email@example.com] kom in i rummet. dbhole dbhole_ (15:29:27) xranby: dbhole_: hi we are discussing jnlp namespace design (15:29:30) aph: sgothel: that's rather like the famous bug in "make" that never got fixed because it would break makefiles, and make already had "about 20 users" (15:29:31) aph: :-) (15:29:38) aph: so it's still there (15:29:55) aph: sgothel: ok, here's my idea (15:30:05) aph: have a very thin library that expoerts no symbols (15:30:15) aph: and loids the appropriate one for the running system (15:30:20) aph: that wouldn't be so hard dbhole dbhole_ (15:30:35) dbhole_: xranby: hi.. sure, whats happening with it? (15:30:38) sgothel: well .. it's not suitable in a networking environment (15:30:39) xranby: dbhole: todays back-log http://paste.ubuntu.com/903876/ (15:30:39) aph: ah, would only fix today's problem, not long term forget that dbhole dbhole_ (15:30:57) sgothel: assume all native JARs must be loaded from the network (15:31:15) sgothel: we really should have the information accessible from the Java side .. (15:31:31) xranby: dbhole_: in a nutshell os.arch in jnlp do not contain enough information to be able to load the right jni lib on different architectures (15:31:33) sgothel: for example, we need to tell 'ant' now it's armhf as well (15:31:41) sgothel: yup (15:31:51) sgothel: and 'ant' and whoever is using 'os.arch' (15:32:13) dbhole_: xranby: thanks dbhole dbhole_ (15:33:07) sgothel: xranby explained the tripplets and quad.. to me a bit, why not using them as a new namespace ? (15:33:12) xranby: dbhole_: sgothel here are maintining the new JogAmp JOGL OpenGL bindings and we want to support armv7+hard armv5+ softfp armv7 + softfp etc (15:33:34) xranby: sgothel: those quads only exist in debian armhf inside its package manager at the moment (15:33:48) xranby: a bit secretly buried (15:33:55) sgothel: well, but they fit the purpose .. don't they ? (15:34:10) xranby: well yes.. they got created to solve the multiarch issue (15:34:15) sgothel: just as a boilerplate for the new namespace (15:34:22) xranby: but its not picked up by the linux foundation (15:34:34) xranby: so its nothing you can use on all linux distributions (15:34:37) sgothel: and we have the same problem .. multiarch to be solved with os.arch or whatever (15:35:02) sgothel: ofc I mean that the openjdk build itself will expose such a string (15:35:32) aph: I'm trying to get my head around the idea that a jnpl jar will contain every jni library for every arch in existence (15:35:43) aph: and that has ever existed (15:35:46) sgothel: thats what we have today (15:35:52) aph: can no-one tell these people "no!" ? (15:35:53) sgothel: yup (15:35:58) aph: this does not scale. stop it. (15:36:00) sgothel: solution ? (15:36:18) aph: 1. proper OS packageing (15:36:19) sgothel: and you have to consider download time as well .. (15:36:23) aph: you do (15:36:30) sgothel: but you have 'ant' as well (15:36:31) aph: 2. download the correct jni file (15:36:42) sgothel: you need information for that (15:36:54) aph: sgothel: ant is another issue, surely (15:36:59) sgothel: you have a generic platform independent jar file (15:37:10) sgothel: which loads the native stuff (15:37:16) sgothel: directly or from network (15:37:16) aph: yes (15:37:53) aph: we've only been able to get away with it because there are only about 2 or 3 processors that people use for jnlp anyway (15:38:02) sgothel: it might sounds scary .. and all of that, but practically it works (15:38:06) aph: in the longer term, it's a doomed idea (15:38:22) sgothel: sure, I have a room of test machines here connected to jenkins :) (15:38:42) sgothel: reality also means that you already have such a scenario w/ real machines (or virtual ones) (15:38:52) aph: sure, I know (15:39:09) aph: just like the "make" example above... (15:39:11) sgothel: so 'os.arch' just reflects this (15:39:36) aph: I guess the real place this needs fixing is at the JCP spec (15:39:43) sgothel: it's short-term / and long-term solution (15:39:57) sgothel: short-term: make 'os.arch' useful again on armhf (15:40:04) sgothel: long-term: make a proper namespace (15:40:08) xranby: so can we create a new JEP (15:40:12) xranby: to fix this? (15:40:13) sgothel: JCP and all of that .. (15:40:26) sgothel: but we all know .. this takes time, looong time :) (15:41:18) aph: It's really important we don't just make something up. we need an enumeration of what the ABIs we're going to come across in the next year or two are going to be called (15:41:22) xranby: it would be really cool if icedtea-web implemented a sane solution to ease deployment if you use icedtea-web (15:42:12) sgothel: aph: it's evolutionary steps .. vs .. a new schema .. sure, I like a proper solution where everything is well defined (15:42:31) aph: so, we have (15:42:39) aph: arm, which is armv5, no fp (15:43:00) xranby: armv4+ (debian) (15:43:12) aph: v4? gosh (15:43:28) aph: ok, so arm is armv4 (15:43:44) aph: what does gcc say it is on those boxes? (15:43:59) sgothel: arm, armv5l, armv6l, armv7l .. afaik (15:44:09) aph: right. mine says armv7hl (15:44:18) xranby: Target: arm-linux-gnueabi (15:44:41) aph: xranby: ok, as we have "arm" and "armv7hl" (15:44:59) sgothel: the os.arch strings ? or uname ? (15:45:13) xranby: i used gcc -E -v (15:45:21) aph: sgothel: theis is the configury for binutils, etc (15:45:27) aph: sgothel: uname doesn't help (15:45:38) sgothel: mine above were from our os.arch 'experience' .. (whatever that means) (15:45:42) aph: since this is all userspace AFAIK (15:45:46) sgothel: aph: thx (15:46:09) aph: don't want a new namespace (15:46:25) gnu_andrew lämnade rummet (quit: Remote host closed the connection). (15:47:06) aph: "armv7hl" covers it AFAICS. version, hard fp, little-endian. at least I think that's what the "l" stands for (15:47:21) sgothel: our current interpretation: http://jogamp.org/git/?p=gluegen.git;a=blob;f=src/java/com/jogamp/common/os/Platform.java;h=461ed2a7fbbc126dc536e98ff6e5f9606a7e6d59;hb=HEAD#l257 (15:47:52) sgothel: aph: great (15:47:53) xranby: i agree it would be nice to use the gcc namespace (15:48:05) xranby: since its gcc after all that produce all these variants (15:48:21) sgothel: kudos (15:48:40) sgothel: looking fwd to use those new names (15:48:54) aph: I'm not. :-) (15:49:08) sgothel: well .. it's a practical solution for the current mess (15:49:44) aph: I think it changed at some point, too. There was all this "gnueabihf" stuff (15:50:26) aph: and debian and fedora did something different, but I think it's settled down now (15:50:47) xranby: an i think android are covered as well (15:50:48) sgothel: sounds good (15:51:00) aph: the only way to be sure it to do a very detailed analysis of the binutils + gcc sources to determine what's out there (15:51:16) aph: and hope no distro is using patched gcc with its own variant! (15:51:22) sgothel: yup (15:51:24) xranby: fail on them :) (15:51:27) xranby: if they do (15:51:47) sgothel: that also reflects on the current os.arch situation, which is not really documented at all :) (15:52:03) sgothel: so using those gcc names, is better than today (15:52:14) aph: I think Sun just made stuff up (15:52:22) sgothel: sure :) (15:52:32) sgothel: it was a small world back then (15:52:34) aph: (So do we, but, well, y'know) (15:52:56) sgothel: :) (15:55:07) sgothel: so what are the next steps ? ie. impl. this for os.arch ? (15:55:33) sgothel: setting up a documentation / table of os.arch ? (15:55:41) aph: sgothel: we could do this without oracle, but we should not (15:55:46) aph: sgothel: start with that (15:55:54) aph: then raise a proposal on hotspot-dev (15:55:55) sgothel: I was afraid about those words :) (15:56:14) aph: well, we can just tell them we're going to do it (15:56:24) aph: but it's not a good idea not to tell them (15:56:52) sgothel: cool .. like 'we fix os.arch' for the new world of platforms .. they can't not like it :) (15:57:16) sgothel: maybe they do .. since embedded .. well, sorry to have started this :) (15:57:28) sgothel: so you do it aph ? (15:57:35) sgothel: communication and all of that ? (15:57:42) xranby: their java se for arm only support softfp so they have not faced the problem (15:57:56) sgothel: ofc they are slow (15:58:00) aph: sgothel: sorry, not anytime very soon. I'm deep in method handles for the arm port (15:58:17) sgothel: so shall xranby or I do it ? (15:58:20) aph: sgothel: they usually reply in a few days (15:58:33) aph: sgothel: why not? at least get the discussion started (15:58:34) xranby: what i can do are pasting this discussion on the icedtea wiki (15:58:52) aph: xranby: all the random crap in there too? :-) oh well (15:59:30) sgothel: and send the message to hotspot-dev then ? or which is the right channel ? (16:00:26) sgothel: sure, copy/paste this discussion, since it includes everything .. (16:00:47) sgothel: looks like a plan (16:01:00) aph: sgothel: we can discuss the proposal in distro-package-dev first (16:01:12) aph: but I guess it's really just a list of names (16:01:19) sgothel: and where can we make a patch to impl. this for os.arch (as a proposal) ? (16:01:48) xddadacha är nu känd som ddadacha (16:01:59) sgothel: sorry .. me newbie in the openjdk world (16:03:00) xranby: sgothel: i think it have to go into hotspot (16:03:22) xranby: os.arch are currently handled there (16:03:32) sgothel: very good .. and the proposed gnu string is available there / MACRO ? (16:04:47) sgothel: 'gcc -E -v ..' sure we cann make it available (16:05:14) xranby: i dont know what the macro are called for use inside c/c++ code , i need to look it up