Building WebKit natives with debug symbols on 32 bit Linux
David.Hill at Oracle.com
Wed May 28 15:17:45 UTC 2014
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 guess...
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:
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.Hill at 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"
More information about the openjfx-dev