Cross-compiling NSPR using Microsoft Services for Unix (SFU/Interix)
Neil <[email protected]> Fri, 07 Nov 2008 11:12:41 +0000
| Newsgroups | gmane.comp.mozilla.devel.nspr |
|---|---|
| Message-ID | <[email protected]> |
I have mostly been able to "cross-compile" SeaMonkey using SFU to drive the build but calling through to VC to do the "cross" compilation (host programs are compiled with gcc) although I have run into a few issues along the way. I had to make some tweaks to various parts of the build system but here I will stick to those that affected NSPR. For some reason, configure wouldn't succeed if I skipped the checks at line 125. I also had to replace them with an AC_EXEEXT to detect the .exe output extension. I had to move cross_compiling=yes from the start to the end of its if block. I had to make it detect an msvc cross-compile target as WINNT in one place that seems to have been overlooked (msvc is accepted in other places in configure). Finally I had to remove the .exe from the definition of RC as I wanted it to run my rc to RC.EXE wrapper script (which fixes the path names à la cygwin-wrapper). NSPR's config/rules.mk copies most of the HOST_ variables to their non-HOST_ equivalents, but it fails to copy HOST_OUTOPTION. (For SFU I also had to add NS_USE_GCC=1 here, again since my host compiler is gcc but my cross-compiler is not. I'm not sure whether there's a better way to achieve that.) NSPR's nsinstall.c doesn't use the GETCWD_CANT_MALLOC optional define, although both Mozilla's and NSS's do. (Naturally SFU's getcwd can't malloc.) In fact I have more problems with nsinstall.c as SFU has a similar problem to VMS in that close updates the timestamp on the file so you have to utime afterwards. (There's some issue on NFS that you have to utime first so that the close tests that it succeeded?) I also tried making nsinstall hard link but that fails to nsinstall nsinstall over itself. (This is a really lame bug in SFU.) I can't use symlinks because they're not supported in XP. (Python doesn't work in SUA Vista so I can't tell whether that would fix the problem.) NSPR uses $(INSTALL) -m 444 (Mozilla uses -m 755) to install shared libraries, unfortunately this is read but don't execute and SFU maps permissions so Windows won't execute the installed libraries. (This is not normally a problem on Windows because the MOZ_TOOLS nsinstall ignores the -m flag.) At this point I'm thinking that I would be better off writing a custom nsinstall; fortunately it seems as if the build system should support this. I have only tested these changes on SFU and MSYS builds so I don't know whether they will affect other platforms, but I would have thought it unlikely. If you are interested, you can file bugs on me and I will submit patches for your consideration, plus I will also try to remember to check the newsgroup occasionally for any comments. -- Warning: May contain traces of nuts.