integrit-devel

[Integrit-devel] Fixing security/integrit build errors on sparc64

[Jos B. <jo...@ca...>]

I am the port maintainer for security/integrit. A new release is about to be
made and perhaps the issues with building this port on sparc64 can be
addressed if I have some way of knowing what they are. Thanks.

-- 
Jos Backus
jos at catnook.com

[Integrit-devel] Re: Fixing security/integrit build errors on sparc64

[Kris K. <kr...@ob...>]

On Tue, Sep 13, 2005 at 10:41:02AM -0700, Jos Backus wrote:
> I am the port maintainer for security/integrit. A new release is about to be
> made and perhaps the issues with building this port on sparc64 can be
> addressed if I have some way of knowing what they are. Thanks.

Start with http://pointyhat.freebsd.org for all your error reporting
needs.

Kris

[Integrit-devel] Re: Fixing security/integrit build errors on sparc64

[Jos B. <jo...@ca...>]

On Tue, Sep 13, 2005 at 02:00:40PM -0400, Kris Kennaway wrote:
> On Tue, Sep 13, 2005 at 10:41:02AM -0700, Jos Backus wrote:
> > I am the port maintainer for security/integrit. A new release is about to be
> > made and perhaps the issues with building this port on sparc64 can be
> > addressed if I have some way of knowing what they are. Thanks.
> 
> Start with http://pointyhat.freebsd.org for all your error reporting
> needs.
 
Thanks Kris.

> Kris

-- 
Jos Backus
jos at catnook.com

Re: [Integrit-devel] Fixing security/integrit build errors on sparc64

[Jos B. <jo...@ca...>]

See http://pointyhat.freebsd.org/errorlogs/sparc64-errorlogs/e.6.2005060522/integrit-3.02.00.log

gnupg/md5.c has:

    p = hd->buf;
  #ifdef BIG_ENDIAN_HOST
    #define X(a) do { *p++ = hd->a      ; *p++ = hd->a >> 8;      \
                      *p++ = hd->a >> 16; *p++ = hd->a >> 24; } while(0)
  #else /* little endian */
    /*#define X(a) do { *(u32*)p = hd->##a ; p += 4; } while(0)*/
    /* Unixware's cpp doesn't like the above construct so we do it his way:
     * (reported by Allan Clark) */
    #define X(a) do { *(u32*)p = (*hd).a ; p += 4; } while(0)
  #endif
    X(A);
    X(B);
    X(C);
    X(D);
  #undef X

I could be wrong but it looks like the BIG_ENDIAN_HOST case is broken (sparc64
is big endian); there, each occurrence of `hd->a' needs to be replaced with
`hd->##a' (i.e. use the paste operator). But I have no way of testing this.

-- 
Jos Backus
jos at catnook.com

Re: [Integrit-devel] Fixing security/integrit build errors on sparc64

[Jos B. <jo...@ca...>]

On Tue, Sep 13, 2005 at 11:24:26AM -0700, Jos Backus wrote:
> See http://pointyhat.freebsd.org/errorlogs/sparc64-errorlogs/e.6.2005060522/integrit-3.02.00.log
> 
> gnupg/md5.c has:
> 
>     p = hd->buf;
>   #ifdef BIG_ENDIAN_HOST
>     #define X(a) do { *p++ = hd->a      ; *p++ = hd->a >> 8;      \
>                       *p++ = hd->a >> 16; *p++ = hd->a >> 24; } while(0)
>   #else /* little endian */
>     /*#define X(a) do { *(u32*)p = hd->##a ; p += 4; } while(0)*/
>     /* Unixware's cpp doesn't like the above construct so we do it his way:
>      * (reported by Allan Clark) */
>     #define X(a) do { *(u32*)p = (*hd).a ; p += 4; } while(0)
>   #endif
>     X(A);
>     X(B);
>     X(C);
>     X(D);
>   #undef X
> 
> I could be wrong but it looks like the BIG_ENDIAN_HOST case is broken (sparc64
> is big endian); there, each occurrence of `hd->a' needs to be replaced with
> `hd->##a' (i.e. use the paste operator). But I have no way of testing this.
 
Oops, I was looking at the 3.0.4 sources where this has been fixed and thus
was drawing the wrong conclusion; the error message was complaining about the
_presence_ of the paste operators. Hence the paste operators need to go
instead (they are in the 3.0.2 sources) as is now the case. So I would expect
this version to build on sparc64.

Sorry for the confusion.

-- 
Jos Backus
jos at catnook.com

Re: [Integrit-devel] Fixing security/integrit build errors on sparc64

[Ed L. C. <ec...@gm...>]

On 9/13/05, Jos Backus <jo...@ca...> wrote:
...
> Oops, I was looking at the 3.0.4 sources where this has been fixed and th=
us
> was drawing the wrong conclusion; the error message was complaining about=
 the
> _presence_ of the paste operators. Hence the paste operators need to go
> instead (they are in the 3.0.2 sources) as is now the case. So I would ex=
pect
> this version to build on sparc64.

Yes, I saw that Yuri made that change and guessed it
was for that reason.  My systems seem happy with it
too, so that's good.

--=20
  Ed L. Cashin <ec...@no...>