Building WebKit natives with debug symbols on 32 bit Linux

Kevin Rushforth kevin.rushforth at
Wed May 28 15:40:09 UTC 2014

Note that there is a bug filed on building webkit with debug symbols on 
Windows/32 and Linux/32:

If you have a 64-bit Linux system, then it should work.

-- Kevin

David Hill wrote:
> 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:
> 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 
> But...
>    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 
> :-)
> Dave
>> Peter
>> On 05/28/2014 03:39 PM, Peter Levart wrote:
>>> Hi,
>>> 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 ( 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 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 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 
>>> with debugging symbols? Have you been able to? Do 
>>> you have any special tricks in your sleeves?
>>> Regards,
>>> Peter

More information about the openjfx-dev mailing list