Subject: Re: Crossbuilding -current on alien OSen
To: NetBSD Current Users <current-users@netbsd.org>
From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk>
List: current-users
Date: 09/21/2004 15:54:18
Um, sorry about all the following:
* This is a reply to a reply to a message that I posted waaaay
  back in mid-June
* I'm not on the machine where I saved the reply to me, nor can
  I seem to access the reply quickly at the moment
* And all I have is my saved copy of the message I originally
  sent, so all References: are lost, breaking threading
* That it took me so long to find this, having a slow machine
  and too many things to keep me occupied
* And most of all, that I'm about to be offline for a long time
  so replies to me would be pointless
* And that it's been a few weeks (at least) since I tried doing
  a build where I had this problems, but I had them for a couple
  months after the original posting

Anyway, all that aside, I wrote back in mid-June::

> I just thought I'd let you know that I've done a crossbuild of
> NetBSD-current for i386 under FreeBSD4 i386, and it seems like
> I needed to make a couple hacks to make the compiler happy.

It turns out that the reason I was seeing these build failures
was because I had set CFLAGS in the appropriate mk.conf to be
``-O1 -pipe''.  When I changed this to be just ``-pipe'' the
crossbuild completed without errors.

(This did surprise me because I had seen mention on other BSD
mailing lists where newer GCC and -O2 would lead to such errors.
I had added the -O1 some time back as a test for a performance
issue I had been having and forgot to revert it.)

Notes -- I also did a sparc crossbuild with -O1 and no problems.
Perhaps this is an issue that should be investigated, or am I
at fault for using -O1 in the first place?  Anyway, no wonder
that I was the only one to observe this...

In any case, I'll repeat my hacks below, to avoid the errors
which I never posted here (mostly potentially uninitialized
variables around loops, if I remember).  You may well consider
this a false alarm if this problem has been addressed in the
past weeks (I'm not at all up-to-date) or if the -O1 that I've
done is not supported.

The compiler which generated my problems is that built as part
of the NetBSD crossbuild problems, invoked with full path and
all that.  The fact that I'm sending this from FreeBSD, as well
as crossbuilding on a different machine on the same OS, seems
to me to make a ``send-pr'' submission much more work than a
misplaced post such as this to current-users.

(I've mentioned my woes to one developer, but not checked if
any fixes have been added to the source.  Blame my infrequent
access to snarf updates for this, if I'm not a suitable scapegoat.)

And again, drop me from replies to avoid bounces, for now.  Sorry.
I'll try to catch the archives...


> --- /stand/NetBSD-src/source-hacks/sys/ufs/ext2fs/ext2fs_readwrite.c-ORIG	Mon Mar 22 20:23:08 2004
> +++ /stand/NetBSD-src/source-hacks/sys/ufs/ext2fs/ext2fs_readwrite.c	Thu May 13 14:20:24 2004
> @@ -237,7 +237,8 @@
>  	int blkoffset, error, flags, ioflag, resid, xfersize;
>  	vsize_t bytelen;
>  	void *win;
> -	off_t oldoff;
> +	/* XXX HACK off_t oldoff; */
> +	off_t oldoff=0;
>  	boolean_t async;
>  	int extended=0;
 

> --- /stand/NetBSD-src/source-hacks/sys/dev/i2o/dpti.c-NEW	Thu May 27 04:07:59 2004
> +++ /stand/NetBSD-src/source-hacks/sys/dev/i2o/dpti.c	Fri Jun 11 20:18:54 2004
> @@ -454,7 +454,8 @@
>  	struct dpti_ptbuf bufs[IOP_MAX_MSG_XFERS];
>  	u_int32_t mbtmp[IOP_MAX_MSG_SIZE / sizeof(u_int32_t)];
>  	u_int32_t rbtmp[IOP_MAX_MSG_SIZE / sizeof(u_int32_t)];
> -	int rv, msgsize, repsize, sgoff, i, mapped, nbuf, nfrag, j, sz;
> +	/* XXX FOO.  HACK int rv, msgsize, repsize, sgoff, i, mapped, nbuf, nfrag, j, sz; */
> +	int rv, msgsize, repsize, sgoff, i, mapped=0, nbuf, nfrag, j, sz;
>  	u_int32_t *p, *pmax;
>  
>  	iop = (struct iop_softc *)sc->sc_dv.dv_parent;


> --- /stand/NetBSD-src/source-hacks/sys/dev/ic/icp.c-ORIG	Wed Oct 29 01:48:15 2003
> +++ /stand/NetBSD-src/source-hacks/sys/dev/ic/icp.c	Thu May 13 12:53:45 2004
> @@ -137,7 +137,8 @@
>  	struct icp_binfo binfo;
>  	struct icp_ccb *ic;
>  	u_int16_t cdev_cnt;
> -	int i, j, state, feat, nsegs, rv;
> +	/* XXX FOO. HACK int i, j, state, feat, nsegs, rv; */
> +	int i=0, j, state, feat, nsegs, rv;
>  
>  	state = 0;
 
thanks,
barry bouwsma