104541 - Cannot cross-compile NSS

Status: RESOLVED FIXED

(NSS :: Build, defect, P2)

Description

[hacker formerly known as [e-mail]]

We can't even pass a custom CC/CXX to NSS (bug 93206) so there's really no hope
of being able to tweak Mozilla to get a cross-compiled NSS.

Comment 1

[Wan-Teh Chang]

Bob, could you explain how to use the cross-compilation
support in coreconf?

Comment 2

[Robert Relyea]

Specifying CC or CXX isn't sufficient because you also need to specify the
linker, the set of options to build a static library, dynamic library, how to
read the map file for dynamic libraries, build options, defines ect.

To build NSS cross, create a crossplatform ${PLATFORM}.mk, and specify
OS_TARGET=$(PLATFORM} on the command line. You also specify the native_CC and
OS_FLAGS for your host platform (for tools that are built as part of the build
process) Host defines are 'NATIVE_CC' and 'NATIVE_FLAGS' respectively.

bob

Comment 3

[Wan-Teh Chang]

I plan to mark this bug as WORKSFORME or FIXED
because Bob Relyea added cross-compilation support to
coreconf at the same time he added the BUILD_TREE
support.  I don't think the cross-compilation support
in coreconf has been tested though.  Bob?

Chris, do you still have any questions about how to set up
a ${PLATFORM}.mk file in coreconf to cross-compile NSS?

Comment 4

[hacker formerly known as [e-mail]]

What goes in a ${PLATFORM}.mk file?  How is this file supposed to be generated
on the fly as part of the Mozilla build system or do I need to have you guys
check in a ${PLATFORM}.mk for each of the cross-compiling targets that we want
to support?  What about the .mks for our commercial embedding clients (which
obviously cannot go into the tree)?  I'd like to hear that it has at least been
tested before I go off an tell the embedding team that cross-compiling NSS
actually works.

Comment 5

[Robert Relyea]

included in $(platform).mk generally:

Compilier
Linker
Command to build shared libraries
library archiver
OS specific options to compiliers and linkers
instructions on using .def files (how to parse our .def files into something a
particular platform can understand).
Default overrides like various object extenstions.
Additional OS specific library and include paths.
OS specific libraries.
Option overrides between various versions of the os tools (AIX 3.2, or instance,
supports shared libraries differently than AIX 3.1).

The more complicated *.mk files are ones for platforms that are the furthest
from the norm.

Unix-like platforms have the simpliest form. Look at HP-UP.mk for a good
example. If your on a unix-lik platform that's pretty generic, you could
probably pre-generate it, but may be missing some important features (like
symbol restriction in Shared Libraries).

As far as commercial platforms support for commercial packages, I see no problem
checking in the .mk files for those platforms unless their development is still
secret. Then we need to handle it like any other secret development we work on
even though our product is open source. Even in that case if the hardware we are
porting to is public, then it still makes sense to check in the .mk files into
the open source tree. There are lots of platforms there... and the existance of
the platform does not imply the AOL will eventually produce a product on the
platform.

bob

Comment 6

[Mark Crichton]

It doesn't seem to work here.

I'm cross compiling for Linux ARM in Linux x86.  Either nss builds with the
native (x86) gcc, which is bad.  Or, if I set NATIVE_CC to arm-linux-gcc, I
can't build nsinstall (duh).  It appears that the makefiles for nss are using
NATIVE_CC.

Also, I would like some enlightenment on the ${PLATFORM}.mk issue.  For
platforms where we have multiple CPUs (e.g. Linux and NetBSD), how does coreconf
handle this.  Building mozilla on some of these embedded products is doable, but
not the easiest/fastest/practical way of doing things.

Comment 7

[Wan-Teh Chang]

We are revisiting the cross-compilation issue right now.
We selected Windows CE 3.0 (Pocket PC 2002) as our
first target platform, but we are also interested in
cross-compiling for Linux ARM.

Hopefully we will know soon how good the current NSS
build system's support for cross-compilation is.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Reassigning to myself.  Patch forthcoming.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Makefiles use OS_TARGET instead of OS_ARCH

This patch does several things:
1. It changes nearly all places that referenced OS_ARCH to reference OS_TARGET
instead.  This helps with cross compilation because OS_TARGET can be overridden

with an environment variable, but OS_ARCH cannot be.

2. It removes a lot of platform-dependent ifdefs from the coreconf .mk files
that are supposed to be platform independent, and moves the platform
dependent settings into the platform dependent makefiles.  

I plan to make more changes after this, such as 
a) removing the suffix "32" from certain files produced for Win32, 
b) (maybe) collapsing many platform-independent .mk files that
presently are included by config.mk into config.mk itself.

Comment 10

[Julien Pierre]

Nelson,

Your change broke the OS/2 build with a LIB_PREFIX problem.
That was set to "lib" instead of blank as it should have been.

I think the order in which you are doing things is wrong. In config.mk you check
for LIB_PREFIX to be defined, and if not, you set it to "lib" . 
I think you should first set the thing to lib and then include the
platform-specific file, which would override it.

As it is, the LIB_PREFIX needs to be defined in the OS2.mk file as $(NULL) to
get  past the check.
It would be clearer IMHO to just have a line like :
LIB_PREFIX=
And have that work.

Comment 11

[Wan-Teh Chang]

I agree with Julien.  It is strange to see a line like
LIB_PREFIX = $(NULL)

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Setting priority and target milesstone.

The patch above was checked into NSS for the 3.4 release, IIRC.
NSS 3.4 can be cross-compiled on Windows for various WinCE platforms
that may or may not use Intel x86 family CPUs.  

Chris Seawood and Mark Crichton haven't commented on it since 3.4 was released.

So, is this bug fixed now?  
If not, what specific issues remain to be fixed?

Comment 13

[Wan-Teh Chang]

I suggest that we mark this bug fixed in NSS 3.4
and open new bugs for any remaining issues.

I think we still have difficulty cross-compiling
for a different CPU architecture on the same OS,
in particular, cross-compiling for Linux ARM in
Linux x86 as Mark Crichton pointed out in comment
#6.

OS_TARGET specifies the target OS, which is the
same (Linux) in this case.  We need a make
variable for specifying the target CPU
architecture.  It seems that we can just use
the existing CPU_ARCH for this purpose, that is,
specifically define CPU_ARCH to mean the target,
not the host, CPU architecture, and allow CPU_ARCH
to be overridden for cross-compilation.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Per Wan-Teh's suggestion, I am marking this bug fixed, and have opened a
new NSS bug about cross compiling for a different CPU type on the same OS.
I have not added all the cc recipients of this bug to is Bug 172651 so 
interested parties should add themselves to that bug's cc list.

Comment 15

[cls]

Attachment: Brute force method

With this patch, I can cross compile NSS from i386-linux to i386-mingw32. 
YMMV.  timeless reported that the build runs (I'm out of win32 partitions atm)
& https works.	Since coreconf doesn't appear to have a HOST_CC or equivalent,
none of the tools which would require the build host's compiler are built. 
This includes nsinstall & shlibgen.

Comment 16

[Wan-Teh Chang]

cls:

Regarding HOST_CC, please see relyea's comment 2.

Comment 17

[cls]

I noticed that after I hit submit.  Those vars are only setup for nsinstall. 
shlibgen & mangle would need them as well, though I'm still not certain about
running a native shlibgen on the cross-compiled libraries.

Comment 18

[Wan-Teh Chang]

You are right.  That'll only solve the problem with nsinstall.

shlibgen is a totally different problem.  shlibgen must be
built with the compiler for the target platform.  We will
need to think of a solution for generating the softoken's
.chk file when cross-compiling.