Roland Mainz wrote:
> Peter Dennis - Sustaining Engineer wrote:
>> Roland Mainz wrote:
>>> "Peter D. Dennis" wrote:
>>>>> Chris Quenelle wrote:
> [snip]
>>>> As it stands my current work is to get the cw wrapper to understand the
>>>> new SS12
>>>> command flags (-m64 and the associated -xarch= subflag) and clean up the
>>>> lint
>>>> noise.
>>> What is the current status of the project ?
>> The cw work is done and putback to snv_80. Currently working on getting
>> a clean lint build.
>
> Ok...
> ... BTW: Please don't try to cleanup the lint stuff for { libshell,
> libcmd, libpp, libdll, libsum, libast } ... that's what needs to be done
> on our&&AT&T's side...
Nope - I've no intention of doing that part - it is the kernel that has
a bunch of lint complaints that needs to be cleaned.
>
>>> Is there still time to get
>>> something else included (e.g. use "-xstrconst by default") ?
>> I would rather that is done post compiler switch simply because too many
>> changes at once could cause problems (was it the compiler or was it the
>> new flag ?).
>
> 1. Umpf... IMO we then end-up in a catch22 situation (or better: run in
> circles forever - even the "proof of concept"-putback which should only
> cover libc/libnsl/libsocket's DEBUG build is currently stuck in the
> mud). I've tried lobbying for the change in the last couple of _months_
> without any success and the last hope is to get it "in" with the
> compiler update. If we can't hijack that "compiler update"-boat then
> I'll suggest to close the matching RFEs as "WONTFIX" (sorry for this
> depressive conclusion but it seems we won't make any progress in the
> forseeable future and I'm getting depressions... regardless what I try
> nothing moves...).
>
> 2. The change is less dangerous then you think - much work has already
> been done by the "compile OS/Net with gcc"-project and most of the code
> just works out of the box (gcc makes string literals read-only by
> default and requires an explicit option ("-fwriteable-strings") for
> gcc3.x (gcc4.x no longer provides an option for this, e.g. string
> literals are read-only without a way to change it)) and the "error
> condition" is very simple: You either get a SIGSEGV or the code works.
> That reduces IMHO the "risk" down to a minimum.
>
Yes but the problem with a SIGSEGV is was it the compiler change or
was it the new flag ?
Having said that performing the flag change in isolation would be
possible and a way forward - just the normal current sponsorship
request. Ignore the compiler switch bits - that would be my problem.
>> Are you currently building with SS12 ?
>
> I tried it some time ago to check whether there are any problems with
> the ksh93-integration code (actually updating to Studio 12 would be very
> nice since some C99 stuff works better) ...
>
>> If so what issues have you found ?
>
> ... not much... except that the VLA ("variable length array") support is
> still busted (which worked in Sun Studio 10, the switch to Studio 11
> then broke it...)
Do you happen to have a bug id for that ?
Thanks
pete
> ... for the first putback we were able to work around
> the problem but for the ksh93-update1 we have... problems (which will
> delay the putback (either because we have to port stuff or by waiting
> until the situation gets somehow solved) which then causes delays for
> other people... ;-( ) ...
>
> ----
>
> Bye,
> Roland
>
