On 5/28/14, May 28, 9:47 AM, Peter Levart wrote:
Hi Again,

The idea that comes to my mind is the following: would it be possible to 
cross-compile the openjfx on the 64 bit Linux using 64 bit tools, but targeted 
at 32 bit Linux? What would have to be changed in build environment to 
accomplish that? I imagine the environment would have to have access to headers 
and development libraries of the 32 bit Linux system - that's no problem - I 
would just mount the root of a 32 bit Ubuntu to some directory, but then I 
would have to force all tools to use that path instead of the running system 
one. And the gcc would have to be given some cross-compiling options too, I 

In theory this is easy :-)

We already have a cross compile mechanism in gradle, used for the Linux arm and 
Android builds. (see buildSrc/armv* for example).

You would start with one of the build files as a template - linux.gradle, 
sed/copy it to linux32.gradle  with something like:

cd buildSrc
sed -s 's/LINUX/LINUX32/' linux.gradle > linux32.gradle

After that, it would be a matter of tweaking the cc and ld flags contained in 
the file, to tell gcc to be 32bit and to use the right libraries. Looks like 
adding -m32 to commonFlags is all it should need:

// A set of common parameters to use for both compiling and linking
def commonFlags = [
        "-m32",  // <<<<< 32 bit output
        "-fno-strict-aliasing", "-fPIC", "-fno-omit-frame-pointer", // 
optimization flags
        "-W", "-Wall", "-Wno-unused", "-Wno-parentheses", 
"-Werror=implicit-function-declaration"] // warning flags

and tweak where the libraries are installed:

// Libraries end up in the sdk/rt/lib/$OS_ARCH directory for Linux
LINUX32.libDest = "lib/i386"
LINUX32.arch = "i386"  # << this is an addition not needed in linux.gradle

You specify the crossbuild like this:
    gradle  -PUSE_DEPEND=false -PBUILD_NATIVES=true -PCOMPILE_TARGETS=linux32

   looks like we need to disable
        LINUX32.compileFXPackager = false;
because build.gradle has some stuff hardcoded in it (would need a jira for that 
if people care).

And - you need the i386 development packages installed. I had already added 
this to get my cross compilers to work,
    apt-get install libstdc++6:i386
but needed to add other to get more of the build to complete and ran into 
apt-get telling me all my i386 deps were broken. Perhaps it would work better 
if I was on a newer distro (I am on 12.04)
has the list of packages, in theory, you just need to add :i386 to each one.

Since I can't get the i386 packages, at this point you are on your own :-)



On 05/28/2014 03:39 PM, Peter Levart wrote:

I'm new to this list and I have searched the archives, but haven't found a 
discussion about this. If I have missed it, please just direct me to the 
archived thread.

I'm trying to debug a crash in a native part of WebKit-JavaFX bindings 
(https://javafx-jira.kenai.com/browse/RT-33599). I have only been able to reproduce it on 
32 bit platforms (Windows and Linux so far). I'm trying to build the WebKit natives with 
debugging symbols, so that I can pin-point the location of the crash in code using gdb. I 
have managed to do this successfully on 64 bit Linux, producing 1.7 GB large 
libjfxwebkit.so. But on 32 bit Linux, where only I can reproduce the crash, the build 
fails with linker error: "memory exhausted" when trying to assemble the 
libjfxwebkit.so from object files. So far I have not been successful in my attempts to 
circumvent this build error. I fave tried the following:

- added '--no-keep-memory' to linker options. The man page says about it:
           ld normally optimizes for speed over memory usage by caching the 
symbol tables of input files in memory.  This option tells ld to instead 
optimize for memory usage, by
           rereading the symbol tables as necessary.  This may be required if 
ld runs out of memory space while linking a large executable.

- booted the 64bit Ubuntu system and chrooted into a 32 bit environment. Some 
say that with 64 bit kernel, each 32 bit user-space process has more address 
space than with 32 bit kernel.

- both of the above

My question to the list is: How do you guys produce 32 bit libjfxwebkit.so with 
debugging symbols? Have you been able to? Do you have any special tricks in 
your sleeves?



David Hill <david.h...@oracle.com>
Java Embedded Development

"A computer lets you make more mistakes faster than any invention in human history - 
with the possible exceptions of handguns and tequila"

Reply via email to