Re: libjfxmedia.so on armv6hf?
Thank you, David, for explaining all that is involved to us desktop-types. :-) Neil From: David Hill david.h...@oracle.com To: openjfx-dev@openjdk.java.net, Date: 03/17/2015 02:40 PM Subject:Re: libjfxmedia.so on armv6hf? Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net On 3/17/15, 8:04 AM, Erik De Rijcke wrote: Why are there limitations on the embedded port of javafx to begin with? Are there technical reasons for it? Quite a few actually The embedded platforms have quite a few features that make them difficult. (and I have the bruises to prove it :-) To start with, an embedded application is usually a single purpose instead of a general purpose computing device. Think a kiosk for example. When I say general purpose devices - I mean classic desktops and now the mobile platforms, where the expectation is that the machine will be used for a number of application. Several of you will say that I am wrong, that a Raspberry Pi for example behaves just like a pokey desktop machine. This is a case where the lines have blurred and will continue to get more blurry. The Pi was one of a new generation of ARM platforms that have a community around them - a place where you can both buy a cheap board and get an OS and drivers without an NDA. So just as you can make a kiosk using a desktop machine, you can also use the PI with XMBC as a media center. As part of the embedded FX team, our design center was less the Pi running with X11, but rather a direct to framebuffer (without the overhead and limitations of X11). And the Pi was an after thought for us, a way to help out the community. We were targeting a more modern platforms liek the i.MX6. The problem with the direct to framebuffer, and to some extent with the rest of the ARM platforms - the platforms are really fractured and it is hard to build a working distro. I personally spend many a frustrating day trying to get some ARM platform to do something we take for granted on the desktop. Starting with OpenGLES drivers, especially ones that would talk to the framebuffer (and not X11). The Pi is one of the few examples out there of a port that has an easy download that contains most of the needed drivers already integrated (and documented). I spent almost a week fighting the Beagle Bone Black before getting up. Oh yes - and add on top of this all that GL initialization direct to framebuffer is non-standard API, so we ended up with 3 code paths for the platforms we were able to build. So in summary it is easy to download a Linux distro. The hardpart is right after you do that, and you want the proprietary hardware accelerated drivers. There are very few platforms that make this easy. And the Pi (version 1) is really too slow. The i.MX6 has enough power for a real application. The ODROID U3 and XU are also pretty spiffy, but I could not get direct to framebuffer working for either of those. If you want to use X11 - OpenJFX will probably work for you, and it might even have graphical acceleration if the drivers are present and integrated. Our Embedded team had ARM media as the next big thing to do, but ... So now we have all of the gstreamer code in the OpenJFX repo. I really expect that media on the Pi (1) will probably not work well due to the speed of the CPU and the memory bus. Maybe the Pi 2. Again, you really need the right drivers in place to take advantage of hardware accelerated decoding of the media stream. With the right gstreamer libraries and drivers, I expect the media port would not take that long for someone that understands gstreamer. There might need to be some changes in Monocle to take the video stream hand off. I really would not expect that media would work without some debugging, and that after getting the build issues worked out. If you think about it, It's arm, so it's embedded. It's x86 so it's desktop doesn't make much sense... (atom is embedded, and there are arm windows netbooks that are not). Anyway, as a workaround, can't openjfx simply be compiled on an arm host (so no cross compilation is required) and as such generate the missing libraries? Qemu with an arm vm can be used to do that on an x86 host for example. On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick felix.bembr...@gmail.com wrote: I really admire guys like this and wish that my own personal circumstances enabled me to get involved in a similar way but my main concern is that the community required to make JavaFX truly viable on iOS, Android and ARM needs to be about 50-100 times bigger than it currently is. Without an It's my concern too. At this point we're at 20 years of Java, and I lived them from the very beginning. The idea the community will fix it is a déjà vu that, unfortunately, says that in the past the thing didn't work many times
Re: libjfxmedia.so on armv6hf?
On 3/17/15, 8:04 AM, Erik De Rijcke wrote: Why are there limitations on the embedded port of javafx to begin with? Are there technical reasons for it? Quite a few actually The embedded platforms have quite a few features that make them difficult. (and I have the bruises to prove it :-) To start with, an embedded application is usually a single purpose instead of a general purpose computing device. Think a kiosk for example. When I say general purpose devices - I mean classic desktops and now the mobile platforms, where the expectation is that the machine will be used for a number of application. Several of you will say that I am wrong, that a Raspberry Pi for example behaves just like a pokey desktop machine. This is a case where the lines have blurred and will continue to get more blurry. The Pi was one of a new generation of ARM platforms that have a community around them - a place where you can both buy a cheap board and get an OS and drivers without an NDA. So just as you can make a kiosk using a desktop machine, you can also use the PI with XMBC as a media center. As part of the embedded FX team, our design center was less the Pi running with X11, but rather a direct to framebuffer (without the overhead and limitations of X11). And the Pi was an after thought for us, a way to help out the community. We were targeting a more modern platforms liek the i.MX6. The problem with the direct to framebuffer, and to some extent with the rest of the ARM platforms - the platforms are really fractured and it is hard to build a working distro. I personally spend many a frustrating day trying to get some ARM platform to do something we take for granted on the desktop. Starting with OpenGLES drivers, especially ones that would talk to the framebuffer (and not X11). The Pi is one of the few examples out there of a port that has an easy download that contains most of the needed drivers already integrated (and documented). I spent almost a week fighting the Beagle Bone Black before getting up. Oh yes - and add on top of this all that GL initialization direct to framebuffer is non-standard API, so we ended up with 3 code paths for the platforms we were able to build. So in summary it is easy to download a Linux distro. The hardpart is right after you do that, and you want the proprietary hardware accelerated drivers. There are very few platforms that make this easy. And the Pi (version 1) is really too slow. The i.MX6 has enough power for a real application. The ODROID U3 and XU are also pretty spiffy, but I could not get direct to framebuffer working for either of those. If you want to use X11 - OpenJFX will probably work for you, and it might even have graphical acceleration if the drivers are present and integrated. Our Embedded team had ARM media as the next big thing to do, but ... So now we have all of the gstreamer code in the OpenJFX repo. I really expect that media on the Pi (1) will probably not work well due to the speed of the CPU and the memory bus. Maybe the Pi 2. Again, you really need the right drivers in place to take advantage of hardware accelerated decoding of the media stream. With the right gstreamer libraries and drivers, I expect the media port would not take that long for someone that understands gstreamer. There might need to be some changes in Monocle to take the video stream hand off. I really would not expect that media would work without some debugging, and that after getting the build issues worked out. If you think about it, It's arm, so it's embedded. It's x86 so it's desktop doesn't make much sense... (atom is embedded, and there are arm windows netbooks that are not). Anyway, as a workaround, can't openjfx simply be compiled on an arm host (so no cross compilation is required) and as such generate the missing libraries? Qemu with an arm vm can be used to do that on an x86 host for example. On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick felix.bembr...@gmail.com wrote: I really admire guys like this and wish that my own personal circumstances enabled me to get involved in a similar way but my main concern is that the community required to make JavaFX truly viable on iOS, Android and ARM needs to be about 50-100 times bigger than it currently is. Without an It's my concern too. At this point we're at 20 years of Java, and I lived them from the very beginning. The idea the community will fix it is a déjà vu that, unfortunately, says that in the past the thing didn't work many times. This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2 arrives, I'll try the option you and others suggested. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it -- David Hilldavid.h...@oracle.com Java Embedded Development
Re: libjfxmedia.so on armv6hf?
Sorry, I'm a bit confused: On Mon, March 16, 2015 23:14, Kevin Rushforth wrote: Media and web have not ever been supported or delivered on linux-arm. So it is possible to build libjfxmedia.so for Linux armv6hf using just what's in the rt repo? Thanks, Chris On Tue, March 17, 2015 14:46, Kevin Rushforth wrote: Not sure what missing stuff you are referring to. All of the JavaFX sources for embedded are in the rt repo on openjfx. -- Kevin Chris Newland wrote: Hi Kevin, Is there any chance Oracle can release all the missing ARM32 stuff and let the community have a go at getting it to work or are there IP / licensing issues here? I understand that a decision was made to reassign resources but I think there's enough brainpower out here in userland to finish the job if all the sources were made available. Thanks, Chris @chriswhocodes On Mon, March 16, 2015 23:14, Kevin Rushforth wrote: Media and web have not ever been supported or delivered on linux-arm. Seems that libjfxmedia.so should be excluded by the openZips target. David can response further. -- Kevin Chris Newland wrote: In reference to http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=72026 7#p7 20267 When cross-compiling to armv6hf on an x86-64 Linux system using: gradle clean openZip -PCOMPILE_TARGETS=armv6hf Some of the binaries are compiled as x86-64: file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped Is this a simple gradle error or is it not currently possible to build some of the JavaFX libraries for ARM? Thanks, Chris
Re: libjfxmedia.so on armv6hf?
Why didn't you target drm/kms gl approach? I realise not all platforms support this, but it would greatly extend the number of supported (embedded) platforms in a generic way. A quick google search seems to indicate that the sgx530 (BBB) has a kms driver as does the vivante (imx6). An RPi drm/kms driver also seems to be in the works and a lot of upcoming arm gpu's seem to be supported as well. By targeting kms/drm you'd be supporting a lot of platforms with a single codepath now and in the future. Unrelated, embedded jfx should use http://wayland.freedesktop.org/libinput/doc/latest/ instead of it's own bug-risky evdev/raw kernel input implementation. ;) Now if just somebody would sponser me so I can work fulltime to implement these things ;) On Tue, Mar 17, 2015 at 7:39 PM, David Hill david.h...@oracle.com wrote: On 3/17/15, 8:04 AM, Erik De Rijcke wrote: Why are there limitations on the embedded port of javafx to begin with? Are there technical reasons for it? Quite a few actually The embedded platforms have quite a few features that make them difficult. (and I have the bruises to prove it :-) To start with, an embedded application is usually a single purpose instead of a general purpose computing device. Think a kiosk for example. When I say general purpose devices - I mean classic desktops and now the mobile platforms, where the expectation is that the machine will be used for a number of application. Several of you will say that I am wrong, that a Raspberry Pi for example behaves just like a pokey desktop machine. This is a case where the lines have blurred and will continue to get more blurry. The Pi was one of a new generation of ARM platforms that have a community around them - a place where you can both buy a cheap board and get an OS and drivers without an NDA. So just as you can make a kiosk using a desktop machine, you can also use the PI with XMBC as a media center. As part of the embedded FX team, our design center was less the Pi running with X11, but rather a direct to framebuffer (without the overhead and limitations of X11). And the Pi was an after thought for us, a way to help out the community. We were targeting a more modern platforms liek the i.MX6. The problem with the direct to framebuffer, and to some extent with the rest of the ARM platforms - the platforms are really fractured and it is hard to build a working distro. I personally spend many a frustrating day trying to get some ARM platform to do something we take for granted on the desktop. Starting with OpenGLES drivers, especially ones that would talk to the framebuffer (and not X11). The Pi is one of the few examples out there of a port that has an easy download that contains most of the needed drivers already integrated (and documented). I spent almost a week fighting the Beagle Bone Black before getting up. Oh yes - and add on top of this all that GL initialization direct to framebuffer is non-standard API, so we ended up with 3 code paths for the platforms we were able to build. So in summary it is easy to download a Linux distro. The hardpart is right after you do that, and you want the proprietary hardware accelerated drivers. There are very few platforms that make this easy. And the Pi (version 1) is really too slow. The i.MX6 has enough power for a real application. The ODROID U3 and XU are also pretty spiffy, but I could not get direct to framebuffer working for either of those. If you want to use X11 - OpenJFX will probably work for you, and it might even have graphical acceleration if the drivers are present and integrated. Our Embedded team had ARM media as the next big thing to do, but ... So now we have all of the gstreamer code in the OpenJFX repo. I really expect that media on the Pi (1) will probably not work well due to the speed of the CPU and the memory bus. Maybe the Pi 2. Again, you really need the right drivers in place to take advantage of hardware accelerated decoding of the media stream. With the right gstreamer libraries and drivers, I expect the media port would not take that long for someone that understands gstreamer. There might need to be some changes in Monocle to take the video stream hand off. I really would not expect that media would work without some debugging, and that after getting the build issues worked out. If you think about it, It's arm, so it's embedded. It's x86 so it's desktop doesn't make much sense... (atom is embedded, and there are arm windows netbooks that are not). Anyway, as a workaround, can't openjfx simply be compiled on an arm host (so no cross compilation is required) and as such generate the missing libraries? Qemu with an arm vm can be used to do that on an x86 host for example. On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick felix.bembr...@gmail.com wrote: I really
Re: libjfxmedia.so on armv6hf?
Why are there limitations on the embedded port of javafx to begin with? Are there technical reasons for it? If you think about it, It's arm, so it's embedded. It's x86 so it's desktop doesn't make much sense... (atom is embedded, and there are arm windows netbooks that are not). Anyway, as a workaround, can't openjfx simply be compiled on an arm host (so no cross compilation is required) and as such generate the missing libraries? Qemu with an arm vm can be used to do that on an x86 host for example. On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick felix.bembr...@gmail.com wrote: I really admire guys like this and wish that my own personal circumstances enabled me to get involved in a similar way but my main concern is that the community required to make JavaFX truly viable on iOS, Android and ARM needs to be about 50-100 times bigger than it currently is. Without an It's my concern too. At this point we're at 20 years of Java, and I lived them from the very beginning. The idea the community will fix it is a déjà vu that, unfortunately, says that in the past the thing didn't work many times. This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2 arrives, I'll try the option you and others suggested. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: libjfxmedia.so on armv6hf?
Not sure what missing stuff you are referring to. All of the JavaFX sources for embedded are in the rt repo on openjfx. -- Kevin Chris Newland wrote: Hi Kevin, Is there any chance Oracle can release all the missing ARM32 stuff and let the community have a go at getting it to work or are there IP / licensing issues here? I understand that a decision was made to reassign resources but I think there's enough brainpower out here in userland to finish the job if all the sources were made available. Thanks, Chris @chriswhocodes On Mon, March 16, 2015 23:14, Kevin Rushforth wrote: Media and web have not ever been supported or delivered on linux-arm. Seems that libjfxmedia.so should be excluded by the openZips target. David can response further. -- Kevin Chris Newland wrote: In reference to http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p7 20267 When cross-compiling to armv6hf on an x86-64 Linux system using: gradle clean openZip -PCOMPILE_TARGETS=armv6hf Some of the binaries are compiled as x86-64: file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped Is this a simple gradle error or is it not currently possible to build some of the JavaFX libraries for ARM? Thanks, Chris
Re: libjfxmedia.so on armv6hf?
Media and web have not ever been supported or delivered on linux-arm. Seems that libjfxmedia.so should be excluded by the openZips target. David can response further. -- Kevin Chris Newland wrote: In reference to http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p720267 When cross-compiling to armv6hf on an x86-64 Linux system using: gradle clean openZip -PCOMPILE_TARGETS=armv6hf Some of the binaries are compiled as x86-64: file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped Is this a simple gradle error or is it not currently possible to build some of the JavaFX libraries for ARM? Thanks, Chris
Re: libjfxmedia.so on armv6hf?
Hi Kevin, Is there any chance Oracle can release all the missing ARM32 stuff and let the community have a go at getting it to work or are there IP / licensing issues here? I understand that a decision was made to reassign resources but I think there's enough brainpower out here in userland to finish the job if all the sources were made available. Thanks, Chris @chriswhocodes On Mon, March 16, 2015 23:14, Kevin Rushforth wrote: Media and web have not ever been supported or delivered on linux-arm. Seems that libjfxmedia.so should be excluded by the openZips target. David can response further. -- Kevin Chris Newland wrote: In reference to http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p7 20267 When cross-compiling to armv6hf on an x86-64 Linux system using: gradle clean openZip -PCOMPILE_TARGETS=armv6hf Some of the binaries are compiled as x86-64: file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped Is this a simple gradle error or is it not currently possible to build some of the JavaFX libraries for ARM? Thanks, Chris
Re: libjfxmedia.so on armv6hf?
On Tue, 17 Mar 2015 00:27:53 +0100, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Unlikely without help from the community, given that FX itself is no longer supported on linux-arm. We currently have no plan to add such support. Quite annoying stuff. BTW, I've just read http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367 It's quite curious. I've just ordered a Raspberry Pi 2 and was planning about writing a media center prototype with some ideas in mind. In the past years I did lots of stuff with imaging and media, and was with Swing. I struggled with tons of incomplete features in the imaging and movie APIs, lots of additional libraries in order to have a decent modern UI (with animations and such), because Java didn't offer them out of the box. In the end I quit because it was frustrating to always be forced to fix something at the basics level. I mean, I just wanted to focus on the application. Now, fast forward some years and we have that Java FX, with bells and whistles. I supposed I could at last enjoy writing an app on the RPI without worrying about missing, incomplete, partially unsupported stuff, but I was wrong. It seems that no matter Sun or Oracle, there's a sort of curse preventing the Java ecosystem to fully work on the reference rich UI hardware. Sorry for the rant, nothing against people of course, but that's just my feelings at the moment. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: libjfxmedia.so on armv6hf?
Yes Fabrizio, I agree with you. First it was iOS, then Android and now ARM. Oracle the company seem to view JavafX or their support for it as just a fancy Swing replacement to run exclusively on desktop operating systems like Windows, MacOS and Linux. But can we even trust that they will continue to invest in those platforms? The problem seems to be as simple that Oracle makes little or no money directly from JavaFX and being a very profit focused company, why would they care about it? Their attitude now is that is you want JavaFX to actually work on anything other than the desktop (i.e. on all the modern devices that most people are actually using these days) then the community must step-up and make it happen. Thats a very disappointing and concerning attitude to say the least! Fortunately some in the community, notably Johan Vos and his company Gluon and Niklas Therning with RoboVM have stepped-up to try to fill this void but we are talking about a handful of people with shoestring budgets trying to get sophisticated technology working on an enormous range of complex and highly fragmented modern devices. How can they compete with a company like Qt which exists *only* to develop and sell Qt and have at least one hundred developers working on each of the iOS and Android ports and already have viable mobile apps using Qt selling out there in the marketplace. I really admire guys like this and wish that my own personal circumstances enabled me to get involved in a similar way but my main concern is that the community required to make JavaFX truly viable on iOS, Android and ARM needs to be about 50-100 times bigger than it currently is. Without an overall corporation paying the wages of these people, how is that ever going to happen? And by truly viable I mean making JavaFX a technology that can be used for *serious commercial application development *on all those platforms. Pretty gauges and simple square-based games are not enough to sustain or interest software houses to adopt JavaFX to develop their products and until that happens, JavaFX is going to struggle... Felix On 17 March 2015 at 10:53, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: On Tue, 17 Mar 2015 00:27:53 +0100, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Unlikely without help from the community, given that FX itself is no longer supported on linux-arm. We currently have no plan to add such support. Quite annoying stuff. BTW, I've just read http://www.raspberrypi.org/ forums/viewtopic.php?f=81t=97367 It's quite curious. I've just ordered a Raspberry Pi 2 and was planning about writing a media center prototype with some ideas in mind. In the past years I did lots of stuff with imaging and media, and was with Swing. I struggled with tons of incomplete features in the imaging and movie APIs, lots of additional libraries in order to have a decent modern UI (with animations and such), because Java didn't offer them out of the box. In the end I quit because it was frustrating to always be forced to fix something at the basics level. I mean, I just wanted to focus on the application. Now, fast forward some years and we have that Java FX, with bells and whistles. I supposed I could at last enjoy writing an app on the RPI without worrying about missing, incomplete, partially unsupported stuff, but I was wrong. It seems that no matter Sun or Oracle, there's a sort of curse preventing the Java ecosystem to fully work on the reference rich UI hardware. Sorry for the rant, nothing against people of course, but that's just my feelings at the moment. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: libjfxmedia.so on armv6hf?
Unlikely without help from the community, given that FX itself is no longer supported on linux-arm. We currently have no plan to add such support. -- Kevin Felix Bembrick wrote: Will they ever be supported? On 17 March 2015 at 10:14, Kevin Rushforth kevin.rushfo...@oracle.com mailto:kevin.rushfo...@oracle.com wrote: Media and web have not ever been supported or delivered on linux-arm. Seems that libjfxmedia.so should be excluded by the openZips target. David can response further. -- Kevin Chris Newland wrote: In reference to http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p720267 http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p720267 When cross-compiling to armv6hf on an x86-64 Linux system using: gradle clean openZip -PCOMPILE_TARGETS=armv6hf Some of the binaries are compiled as x86-64: file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped Is this a simple gradle error or is it not currently possible to build some of the JavaFX libraries for ARM? Thanks, Chris
Re: libjfxmedia.so on armv6hf?
Will they ever be supported? On 17 March 2015 at 10:14, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Media and web have not ever been supported or delivered on linux-arm. Seems that libjfxmedia.so should be excluded by the openZips target. David can response further. -- Kevin Chris Newland wrote: In reference to http://www.raspberrypi.org/forums/viewtopic.php?f=81t= 97367p=720267#p720267 When cross-compiling to armv6hf on an x86-64 Linux system using: gradle clean openZip -PCOMPILE_TARGETS=armv6hf Some of the binaries are compiled as x86-64: file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped Is this a simple gradle error or is it not currently possible to build some of the JavaFX libraries for ARM? Thanks, Chris
