Hi!
----
[CC:'ing David.Marker at sun.com - the OS/Net gatekeeper for the issue
below...]
Mike.Sullivan at sun.com wrote:
>
> (this reply is a bit faked-up because I was going to let
> others look then I got worried since I just pushed
> 88 out today :)
Erm... I don't understand why this reply is "faked" then... ?!
> >Is anyone else seeing the following build failure in SFWNV trunk
> >(20080417):
>
> I am not. However...
>
> >==== Build errors (non-DEBUG) ====
> >
> >dmake: Warning: Target `install' not remade because of errors
> >The following command caused the error:
> >dmake: Warning: Command failed for target `postgres/postgresql-8.1'
> >dmake: Warning: Target `install' not remade because of errors
> >The following command caused the error:
> >dmake: Warning: Command failed for target `postgres/postgresql-8.2'
> >dmake: Warning: Target `install' not remade because of errors
> >The following command caused the error:
> >dmake: Warning: Command failed for target `postgres/postgresql-8.3'
> >dmake: Warning: Target `install' not remade because of errors
> >The following command caused the error:
> >dmake: Warning: Target `install' not remade because of errors
> >-- snip --
>
> The nightly mail message tells you make failed but you have to look
> at the nightly.log file to figure out why (or find the smaller
> usr/src/install*.out if you like).
>
> Since I'm nosy and found out you were bringing over a child from
> the clone on ion I found it and found these errors.
> Searching for 'make:' didn't help but when looking for 'Error code',
> and going back a few pages, I found this:
>
> lssl -lcrypto -lkrb5 -lz -ledit -ltermcap -lresolv -lgen -lsocket -lnsl -ldl
> -lm
> -o postgres
> ld: fatal: file /usr/dist/pkgs/cue/env/std/Profile: open failed: No such file
> or
> directory
> ld: fatal: File processing errors. No output written to postgres
> gmake[5]: *** [postgres] Error 1
> gmake[5]: Target `all' not remade because of errors.
> gmake[5]: Leaving directory
> `/builds1/gisburn/cr_6680716_sfw_breaks_with_ksh/sfw
> nv/usr/src/cmd/postgres/postgresql-8.1/postgresql-8.1.11/src/backend'
> gmake[4]: *** [all] Error 2
> gmake[4]: Leaving directory
> `/builds1/gisburn/cr_6680716_sfw_breaks_with_ksh/sfw
> nv/usr/src/cmd/postgres/postgresql-8.1/postgresql-8.1.11/src'
> gmake[3]: *** [all] Error 2
> gmake[3]: Leaving directory
> `/builds1/gisburn/cr_6680716_sfw_breaks_with_ksh/sfw
> nv/usr/src/cmd/postgres/postgresql-8.1/postgresql-8.1.11'
> *** Error code 2
>
> I seem to remember that's related to having PROFILE set in your
> environment, and that's one that nightly doesn't unset (sadly), but
> appears to be used by postgres Makefiles (well I checked 8.1). Anyway
> that might be all your problems but I didn't search deeply.
Ok... thanks for the investigation... :-)
... which leads to a question: Shouldn't "bldenv"&co. clear the
environment except those env variables which are "known to be good" ?
For my OS/Net development I am always using $ env - HOME=$HOME
SHELL=$SHELL DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY TERM=$TERM
LOGNAME=$LOGNAME LANG=C LC_ALL=C PAGER=less MANPATH=$MANPATH
/opt/onbld/bin/bldenv ./opensolaris.sh # ... but IMO the clearing of the
environment should be done within "bldenv.sh" and not by an external
utilty...
... question to the gatekeepers: Should I file a RFE to let "bldenv"&co.
clear the environment ? I would add to new options: --acceptenvvars and
--rejectenvvars which accept patterns (shell patter, grep pattern, egrep
pattern, fgrep pattern or perl pattern) to filter out environment
variables by name. Any variable name which does _not_ match the pattern
for "acceptenvvars" will be removed and any variable name which matches
the pattern for "rejectenvvars" will be removed, too (e.g. a traditional
accept/reject filter chain).
Default for --acceptenvvars would be
"~(Elr)(HOME|SHELL|DISPLAY|XAUTHORITY|TERM|LOGNAME|MANPATH)" ("~(Elr)"
means egrep pattern with left and right anchors) and "--rejectenvvars"
would contain
"~(Elr)(LD_.*|CONFIG|GROUP|OWNER|REMOTE|ENV|ARCH|CLASSPATH|PROFILE)".
I already have a contribution for "bldenv" queued (CR #6600149
("bldenv_cleanup")) and could easily integrate the functionality into
it... "nightly" would follow with a seperate CR# and putback once we
have positive feedback from that putback that the change worked...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
