371538 - OS_TARGET, and thus em:targetPlatform, different when cross-compiling

Status: RESOLVED INCOMPLETE

(Firefox Build System :: General, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I discovered this issue after getting complaints that my leak monitor extension (which has binary components) doesn't work on Ubuntu.  I discovered that Ubuntu's em:targetPlatform (which determines binary compatibility for extensions) is different from what we ship, and therefore no binary extensions work on Ubuntu unless targeted specifically for Debian/Ubuntu.  This is at least partly because Debian/Ubuntu patch configure.in to make the cross-compilation case the default (and get rid of what for us is the normal case).  However, there's an underlying bug in our build system that means that we set em:targetPlatform in a totally different way if we're cross-compiling, at least for Unix-ish platforms.  (At least this didn't affect the Universal builds on Mac.)

(The rest of this bug report is pieced together from various email messages and edited to improve coherence, although it still might be a little garbled.)

The targetPlatform value for extensions:
http://developer.mozilla.org/en/docs/Install_Manifests#targetPlatform
is composed of two parts:  OS_TARGET and TARGET_XPCOM_ABI,
separated by an underscore.  TARGET_XPCOM_ABI is itself composed of
two parts, CPU_ARCH and TARGET_COMPILER_ABI, separated by a hyphen.

Leak Monitor has binaries for the following platforms, which correspond
to what our build system generates when compiling:
  Linux_x86-gcc3
  Linux_x86_64-gcc3
  Darwin_ppc-gcc3
  Darwin_x86-gcc3
  WINNT_x86-msvc

It appears that
Ubuntu is shipping builds compiled with OS_TARGET=linux-gnu instead
of OS_TARGET=Linux, even though "uname -s" shows "Linux".

Debian has a patch in
http://ftp.debian.org/debian/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.7-2.diff.gz
that makes the non-cross-compile case work much more like the
cross-compile case, where we ensure that OS_ARCH is set to Linux,
but don't do the same for OS_TARGET.

It seems like, given the code here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/configure.in&rev=1.1755&mark=890-907#890
we'd be better off using OS_ARCH than OS_TARGET for binary
compatibility indicators on non-Windows platforms, but the code
here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/configure.in&rev=1.1755&mark=932-955#932
suggests that that might not work on Windows where we'd sometimes
end up with Windows_NT (although it would be an improvement since
we'd never end up with WIN95).

Comment 1

[Benjamin Smedberg]

wtc/cls: can you explain why we have separate OS_ARCH and OS_TARGET vars to begin with?

Comment 2

[Wan-Teh Chang]

The original Netscape client build system used gmake on Unix and nmake
on Windows.  The gmake build system (for Unix) only used OS_ARCH.

NSPR used gmake on both Unix and Windows.  This gmake build system also
used only OS_ARCH in the beginning.  NSPR has two implementations for
Windows, called "WINNT" and "WIN95".  In order to allow us to build
either the "WINNT" and "WIN95" implementation on Windows NT, we treated
building the "WIN95" implementation on Windows NT as a cross-compilation
and added the new OS_TARGET variable.  The meanings of OS_ARCH and
OS_TARGET in NSPR's build system are:
  OS_ARCH: the host OS
  OS_TARGET: the target OS

This convention was also adopted by the NSS coreconf build system and
OS_ARCH and OS_TARGET have the same meanings there -- essentially only
used for building the "WIN95" implementation on Windows NT/2000/XP.

I don't know what OS_TARGET means in Mozilla's build system.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The symptom for Linux here was probably fixed by bug 363263, but the bug still exists for other platforms.

Comment 4

[Chris Cooper [:coop] (he/him)]

Mass bug cleanup for Core:Build Config.

If you feel this bug has been closed in error, please re-open with new details.