--pgp-sign-Multipart_Tue_Oct_25_12:10:42_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "jc" == Joel CARNAT <joel@carnat.net> writes:

    jc> it seems to be commonly known that firefox on sparc64 isn't
    jc> useable (yet).

IIRC someone reported success building regular native sparc64 firefox,
but using libpth instead of NetBSD's builtin -pthread.  I could be
misremembering, but if you want to try there is maybe a pkgsrc option
to force use of devel/pth for everything.  maybe try
PREFER_NATIVE_PTHREADS=no, but I've never tried it myself.

I think it often gets confused on this list whether problems are LP64
problems, big-endian-only LP64 problems, or pthread problems.

 LP64     affects amd64 and alpha.  bug is in package.
 BE LP64  only affects sparc64.  bug is in package.
 pthread  probably sparc64 but could be MI(*).  bug is in NetBSD.

 (*) maybe one or two pthread-fix emails I saw go by, were about
     changing our pthreads to work around some common misuse of the
     API by packages, and there is that PTHREAD_DIAGASSERT variable.

I guess it's not that important, but people will get the impression,
``man, so many packages *still* have 64-bit bugs after all these
years,'' but why do all these packages work fine on Linux/amd64?  The
answer is because amd64 is little-endian, and has fewer pthread
problems.

Solaris and OSF/1, otoh, I'd bet money they just cheat and use their
toolchain to build everything 32-bit. :)

--pgp-sign-Multipart_Tue_Oct_25_12:10:42_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iQCVAwUAQ15ZDInCBbTaW/4dAQLOFwQAgtXssqdmw//3BsMt2/c/3YHep53y9072
qeRR9jbyPwoaBiODPZyqg8e9AlyGfz96lPMvHr5XUcCpgPiLcDznD+PyV3gFEoMK
1WgumAWzKhRGqrm4d/FmU3jCYktMD+tnkGBw6KytXSh2cc3gjOpaIjcVZOBWfjP2
rEbtxfLKPlg=
=Ks53
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Tue_Oct_25_12:10:42_2005-1--