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.