More regarding question #1

You are right the  patch felt adventurous.
I've tried an other :
---------------------------------------------------------------------------
--- nsprpub/pr/src/io/prprf.c.orig      2003-02-27 00:53:42.000000000 +0100
+++ nsprpub/pr/src/io/prprf.c   2004-05-28 18:59:32.000000000 +0200
@@ -55,6 +55,7 @@
     (defined(LINUX) && defined(__s390__)) || \
     (defined(LINUX) && defined(__s390x__)) || \
     defined(WIN16) || defined(QNX) || \
+    (defined(__NetBSD__) && defined(__x86_64__))||\
     (defined(__NetBSD__) && defined(__powerpc__) && \
     __NetBSD_Version__ < 105000000)
 #define VARARGS_ASSIGN(foo, bar) foo[0] = bar[0]

----------------------------------------------------------------------------
It worked ;)


Begin forwarded message:

Date: Fri, 28 May 2004 18:17:17 +0200
From: Ole Hellqvist <ole.hellqvist@spray.se>
To: "Shin'ichiro TAYA" <taya@NetBSD.org>
Subject: Re: pkg/25736: firefox pkg don't build on amd64


Thank you for reviewing the patches!

Regarding your second question:
> Is ntohl() and htonl() of NetBSD really buggy?
It doesn't seem like that.
I think this patch is missplaced.
Actually my problem with craches when executing buggy html code disapeared.
This patch should be removed.

Regarding your 1st question:
> If this *REALLY* needless for amd64?
I still don't know I have not have time to dig into that yet.
But I can try to do some investigation.

Thanks /Ole


On Fri, 28 May 2004 23:57:26 +0900 (JST)
"Shin'ichiro TAYA" <taya@NetBSD.org> wrote:

> From: ole.hellqvist@spray.se
> Subject: pkg/25736: firefox pkg don't build on amd64
> Date: Fri, 28 May 2004 05:49:52 +0000 (UTC)
>
> > --- nsprpub/pr/src/io/prprf.c.orig      2003-02-27 00:53:42.000000000 +0100
> > +++ nsprpub/pr/src/io/prprf.c   2004-05-26 22:43:12.000000000 +0200
> > @@ -616,8 +616,9 @@
> >             cn++;
> >             continue;
> >         }
> > -
> > +#ifndef __x86_64__
> >         VARARGS_ASSIGN(nas[cn].ap, ap);
> > +#endif
> >
> >         switch( nas[cn].type ){
> >         case TYPE_INT16:
> >
>
> If this *REALLY* needless for amd64?
>
> > --- directory/c-sdk/ldap/libraries/liblber/lber-int.h.orig      2004-05-27 18:00:30.000000000 +0200
> > +++ directory/c-sdk/ldap/libraries/liblber/lber-int.h   2004-05-27 18:08:07.000000000 +0200
> > @@ -236,12 +236,13 @@
> >              (((_l)&0xff0000)>>8) + (((_l)&0xff000000)>>24))
> >  #define LBER_NTOHL(_l) LBER_HTONL(_l)
> >
> > -#elif !defined(__alpha) || defined(VMS)
> > +#elif (!defined(__alpha) || defined(VMS)) && !defined(__x86_64__)
> >
> >  #define LBER_HTONL( l )        htonl( l )
> >  #define LBER_NTOHL( l )        ntohl( l )
> >
> > -#else /* __alpha */
> > +#else /* __alpha || __x86_64__  */
> > +
> >  /*
> >   * htonl and ntohl on the DEC Alpha under OSF 1 seem to only swap the
> >   * lower-order 32-bits of a (64-bit) long, so we define correct versions
> > @@ -252,8 +253,7 @@
> >
> >  #define LBER_NTOHL( l )        (((long)ntohl( (l) & 0x00000000FFFFFFFF )) << 32 \
> >                         | ntohl( ( (l) & 0xFFFFFFFF00000000 ) >> 32 ))
> > -#endif /* __alpha */
> > -
> > +#endif /* __alpha || __x86_64__  */
> >
> >  /* function prototypes */
> >  #ifdef LDAP_DEBUG
>
> Is this patch really required?
> The comment says "htonl and ntohl doesn't work well. so use original
> function."
> Is ntohl() and htonl() of NetBSD really buggy?
>
>