Closed Bug 511227 Opened 15 years ago Closed 15 years ago

Firefox 3.0.13 fails to compile on FreeBSD/powerpc


(NSS :: Build, defect, P1)



(Not tracked)



(Reporter: chmeeedalf, Assigned: chmeeedalf)


(Keywords: regression)


(1 file, 1 obsolete file)

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: 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/ 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'
Should this go live in NSS:Build or Core:Build Config ?
From a cursory look at the Makefile and 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
Keywords: regression
Priority: -- → P1
Target Milestone: --- → 3.12.5
Version: unspecified → 3.12.4
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,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 )
Did some research.  The GNU config.guess script uses
"uname -m" for FreeBSD and maps

  pc98 -> i386
  amd64 -> x86_64
  everything else -> self;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

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;
/cvsroot/mozilla/security/coreconf/,v  <--
new revision: 1.12; previous revision: 1.11
Attachment #395153 - Attachment is obsolete: true
Closed: 15 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:,288#277
Your patch v2 worked.

There is a patch in ports that fixes NSPR for powerpc.  It can be found at;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.
You need to log in before you can comment on or make changes to this bug.