Closed Bug 511227 Opened 12 years ago Closed 12 years ago
.0 .13 fails to compile on Free BSD/powerpc
User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-us) AppleWebKit/532+ (KHTML, like Gecko) Safari/419.3 Midori/0.1.7 Build Identifier: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:22.214.171.124) Gecko/2009081815 Firefox/3.0.13 With the change in bug #431958 the nss library in firefox 3.0.13 does not compile. This was tracked down to the mozilla/security/coreconf/FreeBSD.mk file, and a patch for this is attached. Reproducible: Always Steps to Reproduce: 1. Build the www/freebsd3 port on FreeBSD/powerpc 2. Watch it error in sha_fast.c with assembler error of unknown opcode 'bswap' 3.
Should this go live in NSS:Build or Core:Build Config ?
From a cursory look at the Makefile and FreeBSD.mk files from both nss-3.12.3 and firefox 3.0.13, the bug affects the separate NSS library as well as Firefox, so it's probably best to apply the patch to that library, and include it in the next import to firefox and other projects that import it.
Assignee: nobody → nobody
Component: Build Config → Build
Product: Firefox → NSS
QA Contact: build.config → build
Assignee: nobody → chmeeedalf
Severity: normal → major
Priority: -- → P1
Target Milestone: --- → 3.12.5
Version: unspecified → 3.12.4
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I will commit this patch on the CVS upstream repository.
chmeeedalf: thanks for the patch. Two questions: 1. Would "uname -m" work? If so, we can just use the $(OS_TEST) variable (which equals "uname -m"). $(OS_TEST) is what most other platforms use, such as Linux.mk: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/coreconf/Linux.mk&rev=1.41&mark=55,57,62,6466,69#55 2. Does "uname -p" actually return "amd64"? Or did you test "amd64" simply because I mentioned it in bug 431958 comment 55?
Version: 3.12.4 → 3.12.3
One more question: does "uname -p" (or "uname -m") ever return "i686" on FreeBSD? Re: question 1 in my previous comment, I read the uname(1) man page on FreeBSD, and I think "uname -p" is more appropriate for $(CPU_ARCH) whereas "uname -m" is more portable. (The -p option is not listed in http://www.opengroup.org/onlinepubs/000095399/utilities/uname.html )
Did some research. The GNU config.guess script uses "uname -m" for FreeBSD and maps pc98 -> i386 amd64 -> x86_64 everything else -> self http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob;f=config.guess;hb=HEAD So we should be able to just test $(OS_TEST) (which is "uname -m"). Not sure if we still need to handle pc98.
"uname -m" should be sufficient, yes. I only have i386 and powerpc FreeBSD systems, and "uname -m" and "uname -p" return the same values for both on these systems.
chmeeedalf, could you please test this patch? Thanks. I found the list of supported processors at http://www.freebsd.org/releases/7.1R/hardware.html#PROC Since "pc98" is listed in the FreeBSD 7.1 release notes, I map treat it the same as "i386" as config.guess does. I checked in this patch on the NSS trunk (3.12.5). Checking in FreeBSD.mk; /cvsroot/mozilla/security/coreconf/FreeBSD.mk,v <-- FreeBSD.mk new revision: 1.12; previous revision: 1.11 done
Attachment #395153 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
chmeeedalf, do you have some NSPR patches for FreeBSD/powerpc? NSPR's _freebsd.cfg can't be compiled as is. Compilation will fail here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/include/md/_freebsd.cfg&rev=3.11&mark=286,288#277
Your patch v2 worked. There is a patch in ports that fixes NSPR for powerpc. It can be found at http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/nspr/files/patch-.._pr_include_md__freebsd.cfg?rev=1.3;content-type=text%2Fplain There are a few other patches for the port as well, if you want to cherry pick them as desired.
Thank you for testing my patch v2. I filed bug 512076 to remind myself to look at the NSPR patches in FreeBSD port. Thanks for the link.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.