Closed
Bug 104541
Opened 23 years ago
Closed 22 years ago
Cannot cross-compile NSS
Categories
(NSS :: Build, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
3.4
People
(Reporter: netscape, Assigned: nelson)
References
Details
Attachments
(2 files)
74.07 KB,
patch
|
Details | Diff | Splinter Review | |
4.94 KB,
patch
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
Bob, could you explain how to use the cross-compilation support in coreconf?
Assignee: wtc → relyea
Comment 2•23 years ago
|
||
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•23 years ago
|
||
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?
Reporter | ||
Comment 4•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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.
Assignee | ||
Comment 8•23 years ago
|
||
Reassigning to myself. Patch forthcoming.
Assignee: relyea → nelsonb
Assignee | ||
Comment 9•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
I agree with Julien. It is strange to see a line like LIB_PREFIX = $(NULL)
Assignee | ||
Comment 12•22 years ago
|
||
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?
Priority: -- → P2
Target Milestone: --- → 3.7
Comment 13•22 years ago
|
||
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.
Version: 3.4 → 3.3
Assignee | ||
Comment 14•22 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Target Milestone: 3.7 → 3.4
Comment 15•21 years ago
|
||
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•21 years ago
|
||
cls: Regarding HOST_CC, please see relyea's comment 2.
Comment 17•21 years ago
|
||
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•21 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•