418509 - Build fixes for jemalloc on Linux/ARM

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Jason Evans]

Attachment: Linux/ARM build fixes

The attached patch fixes build failures on Linux/ARM.

Comment 1

[Ilpo Ruotsalainen]

This patch is not necessary for all Linux/ARM platforms. I have succesfully built and ran a --enable-jemalloc build without the patch using CodeSourcery 2007q3-51 toolchain (gcc 4.2.1 and glibc 2.5 -based).

Comment 2

[Doug Turner (:dougt)]

Ilpo, what do we do about the default toolchain for the maemo platform?

Comment 3

[Ilpo Ruotsalainen]

We could either use a configure check for whether the compiler supports __thread keyword (and thus TLS) or key the NO_TLS case on compiler version (which sadly is different for each platform), I suppose.

Comment 4

[Jason Evans]

I don't think keying on compiler version is very safe, since the lack of TLS support is often a linker/loader issue, as is the case for the toolchain being used by Doug Turner.  A configure test that compiles and runs a test program should work, though constructing the test will take a bit of effort.  Keep in mind though that if we are building one binary that uses TLS, then deploying to a diverse set of devices, those without TLS support in their dynamic loaders will fail to execute the resulting binary.

I don't know very much about the development environments being used for Linux/ARM, or what the end goals are, so I'm not in a position to know the importance of this issue.  Can someone who is able to make a policy decision on this please tell me how to proceed?

Comment 5

[timeless]

i think the proper way is to define to abis, eabi and eabi-notls and have configure determine which abi is being used, this should enable people to build and distribute packages that support both.

i suppose this is partially a question as to how people intend to distribute the resulting builds. Assuming dougt's platform is maemo 2008, then the proper way is with debs in per os repositories with dependencies and perhaps an install file that has different repository pointers for different platforms. In this system, a user would never be able (w/o dpkg -i --force or something) to install something that won't work.

I doubt most of your users are going to try to cache the package and install it on a second device.

Comment 6

[Stuart Parmenter]

Jason: I wouldn't worry about it.  Given our settings we don't really use TLS for much of anything so this shouldn't really matter.

We'd like to get our maemo platform off of gcc 3.4 (uh??), so I wouldn't worry about it.

Comment 7

[Stuart Parmenter]

there does seem to be some compiler bug with -O2 with the ancient gcc.

This patch was checked in a while ago -- I would mark the bug fixed.