Since applying on of suns latests os-patches we got many trouble with
our build-platform. Sun replaced the name of on internal structure. In
sight of a developer this change is okay, the modifications are
transparent. But as result the c++ compiler now generates other
symbolnames, so we cannot create patches for our software. INstead of
this we have to build the whole software packet. This is an problem,
when supporting older software...

The patch changes this file:
> diff types.h /usr/include/sys/types.h
9,10c9,10
< * Copyright (c) 1996-2001 by Sun Microsystems, Inc.
< * All rights reserved.
---
> * Copyright 1996-2002 by Sun Microsystems, Inc. All
rights reserved.
> * Use is subject to license terms.
16c16
< #pragma ident "@(#)types.h 1.67 01/07/07 SMI"
---
> #pragma ident "@(#)types.h 1.68 02/06/10 SMI"
397c397
< typedef struct {
---
> typedef struct _pthread_attr {
404c404
< typedef struct {
---
> typedef struct _pthread_mutexattr {
411c411
< typedef struct {
---
> typedef struct _pthread_condattr {
418c418
< typedef struct {
---
> typedef struct _once {
426c426
< typedef struct {
---
> typedef struct _pthread_rwlockattr {
In short words: sun replaced a real structure by a typedef to another
structure. e.g.: struct Foo {} <==> typedef struct Other { ... } Foo;

Some of our third-party libraries use c++ templates like

template<class T>
class Foo {};

with T = Foo (struct Foo)

This leads us to a number of questions to be prepared of future problems:
* Why were these changes made?
* Is Sun aware of this problem?
* Is there a possible workaround or what actions does Sun suggest to
take care of such problems? What procedere does Sun suggest regarding
administration of a build system in respect to this problem and similar
problems that might occure in general?
* Is this a "happened once" case or should we be prepared
that such changed can happen again?
* Is it possibe to correctly and easily identify patches that
could be harmfull?

regards, markus