Thanks a lot Mike !!! for detailed look at nightly issue. Tried another 
build machine like you suggested and it worked :) ...

~ Pradhap.D

Mike.Sullivan at sun.com wrote:
> >From sfwnv-discuss-bounces at opensolaris.org Wed May 21 08:29:56 2008
>
> Since I seem to have found your workspace:
>   
>>>> /export4/pd155743/librsync/proto/root_sparc/usr/apache2/2.2/build/libtool 
>>>>         
>>>>> /usr/bin/uname
>>>>> SunOS rankine 5.11 snv_87 sun4u sparc SUNW,Sun-Fire
>>>>>           
>
> I poked a bit. First, though I haven't looked at your changes I see
> this:
>
> mkdir /export4/pd155743/librsync/proto/root_sparc/usr/bin
> mkdir: Failed to make directory 
> "/export4/pd155743/librsync/proto/root_sparc/usr
> /bin"; File exists
> *** Error code 2 (ignored)
> mkdir /export4/pd155743/librsync/proto/root_sparc/usr/bin
> mkdir: Failed to make directory 
> "/export4/pd155743/librsync/proto/root_sparc/usr
> /bin"; File exists
> *** Error code 2 (ignored)
>
> which is not your build problem but it almost looks like you're trying to 
> make $ROOT/usr/bin instead of letting Targetdirs do it. It could
> be you're running librsync's 'make install' and it's doing that,
> but please make sure you aren't doing that yourself.
>
> 2nd note this:
>
>
>   
>>>>> Things that may affect the build.
>>>>>     /opt/sfw/bin
>>>>>     /opt/sfw/lib
>>>>>     /opt/sfw/include
>>>>>           
>
> it could be something in /opt/sfw is breaking you.
> It's certainly the case that apache's configure finds
> gsed there as usual:
>
> checking for a sed that does not truncate output... /opt/sfw/bin/gsed
>
> but I didn't think that caused this kind of problem.
>
> It also looks like the compile line for apache2/re_operators.c
> has -I/usr/include before -I$(ROOT)/usr/include so it _could_ be
> that rankine has an older libxml2 on it, though it seems to be
> dated April 1 so it's not that old. As far as I can tell that
> compile line matches the gates.
>
> your esp-gs failure seems to be because it doesn't link against X,
> but rankine does have recent X bits (should be about the same
> as on the gate). And certainly in its configure I see:
>
> checking for IceConnectionNumber in -lICE... no
> checking for XOpenDisplay in -lX11... no
> checking for XdbeQueryExtension in -lXext... no
> checking for XtAppCreateShell in -lXt... no
>
> which are all 'yes's in the gate. I don't know if that means something
> in your environment caused that or if the X upgrade on rankine
> failed and I missed it, and I can't check because there seems to
> have been a clobber in your workspace so there's no config.log to
> look at.
>
> you certainly do have extra environment variables too.
>
> At this point, since you said you tried norm's env -i suggestion,
> I'd move to another machine. rankine is an ON build machine and so
> has only built ON ever, has been bfu'd, and mostly only bfu'd,
> for a long long time.  While I started updating bunches of non-ON bits
> when it transferred to me (and I started watching SFW), it's entirely
> possible that the various upgrade scripts don't account for things like
> leaping over multiple releases at a time :)
>
>       Mike
>
>   

Reply via email to