742033 - autoconf: fix nspr cross-compile

Status: NEW

(NSPR :: NSPR, defect)

Description

[Robert]

Attachment: nspr-cross-compile-use-build.patch

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120313130407

Steps to reproduce:

trying to cross-compile nspr on Linux for win32


Actual results:

- nsinstall path in autoconf.mk is 'nsinstall'
- config/now reports "Architecture not supported" because neither _WIN32 nor XP_UNIX is defined


Expected results:

- nsinstall should be $(MOD_DEPTH)/config/$(OBJDIR_NAME)/nsinstall.
- HOST_CFLAGS should contain -DXP_UNIX

The problem is that configure uses $host (where the code will run) instead of $build (where the code is being built.

Patch attached, agains mozilla-central as of 3/29 (aproximately)

Comment 1

[Robert]

Just noticed another similar issue causing the -DDEBUG_user to not work. Switching to $build_os works for me..

diff --git a/nsprpub/configure.in b/nsprpub/configure.in
index f7d0055..b44a80c 100644
--- a/nsprpub/configure.in
+++ b/nsprpub/configure.in
@@ -545,7 +545,7 @@ if test -n "$MOZ_DEBUG"; then
     AC_DEFINE(DEBUG)
     DEFINES="$DEFINES -UNDEBUG"
 
-    case "${target_os}" in
+    case "${build_os}" in
     beos*)
         DEFINES="$DEFINES -DDEBUG_${USER}"
         ;;

Comment 2

[Wan-Teh Chang]

Robert: thanks for the bug report and the patches.

Ted: could you take a look at this bug?  Thanks.

Comment 3

[(not currently active) Ted Mielczarek]

Robert: the Mozilla (and thus NSPR) autoconf systems use conflicting definitions of "host" and "target" from the now-canonical autoconf definitions. I'm not sure if this is historical accident or what, but we're loathe to change it since we have lots of people that use the current definitions. Can you try configuring with --target instead of --host and see if that works?

Comment 4

[Robert]

hmm.. that does fix the now.c/nsinstall issues for the cross-compile, but user debug is still -DDEBUG_ (see Comment 1 above), since it's trying to use $USERNAME, when the build environment (Linux) only has $USER.

$ egrep "@(host|target|build)@" config.status 
s%@host@%x86_64-unknown-linux-gnu%g
s%@target@%i386-pc-mingw32%g
s%@build@%x86_64-unknown-linux-gnu%g

Comment 5

[Robert]

I think I'm spending too much time chasing my tail with testing various Windows configurations. What are the 'official' methods supported for NSPR? I've tried:

- cygwin shell on XP (gnu toolchain)
- MinGW shell on XP (gnu toolchain)
- MinGW cross compile on Linux

I've found https://developer.mozilla.org/En/Developer_Guide/Build_Instructions/Windows_Prerequisites#MozillaBuild, which describes building on Windows using MSVC. There is also https://developer.mozilla.org/en/Compiling_Mozilla_With_Mingw, for building on Windows *without* MSVC.

I don't want chase down/fix build issues if there's no chance of them being accepted. And when I submit future patches, I want know which WIN32 build environment(s) I need to be able to say I've tested.

Thanks!

Comment 6

[(not currently active) Ted Mielczarek]

The only build configuration that Mozilla builds NSPR for Windows in is on Win32 with MozillaBuild's MSYS shell using Visual C++ as the compiler. The MinGW port is community-maintained, but generally works.

Comment 7

[Wan-Teh Chang]

Robert: Jacek Caban <[e-mail]> is the only person
I know of who builds NSPR and NSS regularly with MinGW.  I believe
he uses the "MinGW cross compile on Linux" method.  You can send
him email to compare notes.

The official supported method of building NSPR uses MSVC, as Ted
said.