SUMMARY: Problems with a header-file after applying patch cluster - and some new questions, :-)

<Original posting below>
Hi Managers,

sorry for the late summary, the problem was not so easy to figure out. But,
thanks to Casper Dik who pointed us in the right direction!
We had another host, running Solaris 8 with an older patchlevel, so we could
use this to make a diff between the Headers.

Here's what we figured out:

The cause of the problem are changes in the /usr/include/sys/types.h header
between version 1.67 and 1.68.See diff below:

> 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 {


As one can see, the content of the relevant structure pthread_mutexattr_t
itself was not changed,
however its definition *was* changed between the two versions. This change
(giving the struct the name
"_pthread_mutexattr") had inpack on the C function generated from a C++
construtor which had
pthread_mutexattr_t as parameter.

Version 2.67 generated the symbol:
"__16ACE_Thread_MutexPCcP19pthread_mutexattr_t"
while version 2.68 lead to the symbol:
"__16ACE_Thread_MutexPCcP18_pthread_mutexattr"

The used compiler was gcc 2.95.4 (32 Bit). As you can see in the older
version is chooses the typedef
(since the struct has no name), after the patch it chooses the name of the
struct itself.

The consequence is obvious. The compiler generates different symbols for the
same method depending
on the patch installed or not. Objects (objects files, static and shared
libraries) build before installing the patch
do not link against objects build after installing the patch, because of
symbols not found anymore.

This is indeed a *major maintainance problem* for us, requiring full update
of software on production systems
depending on Sun OS patches used on the build system. Suplying partial
patches for customers is not possible
anymore in this situation! Patching the build system requires a full update
of the production software sooner
or later!

So, the following questions have to be cleared: (Maybe one of you has an
idea??)

* 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?

Thanks to all who replied,
keep on hackin',

Harald

============================================
Harald Husemann
Systems Engineer
Teammanager Unix administration and Configuration Management
Materna Gmbh - Vo_kuhle 37 -
D-44141 Dortmund, Germany
Phone:  +49-231-5599-8684
Mobile: +49-179-2300651

-----Urspr|ngliche Nachricht-----
Von: Husemann, Harald
Gesendet: Freitag, 30. Mai 2003 15:38
An: sunmanagers@sunmanagers.org
Cc: Husemann, Harald
Betreff: Problems with a header-file after applying patch cluster


Hi Gurus,

got a strange problem here:

We're running Solaris 8 on one of our build machines, and a few days ago I
applied the latest patch cluster to the machine. After this, we had to
re-build the entire software (including the ACE/TAO-Libraries we're using
for interprocess communication with CORBA).
It seems that one of the headers in /usr/include/sys/types.h has been
changed, the new structure is:

/*
* attributes for mutex, dynamically allocated by library
*/
typedef struct _pthread_mutexattr {
void *__pthread_mutexattrp;
} pthread_mutexattr_t;

My question is:

Anyone saw this before?? Is it a common problem?? And, what patch could have
done it?? Searched the readme's of the patches, but without success...

Thanks for any help,

Harald

============================================
Harald Husemann
Systems Engineer
Teammanager Unix administration and Configuration Management
Materna Gmbh - Vo_kuhle 37 -
D-44141 Dortmund, Germany
Phone:  +49-231-5599-8684
Mobile: +49-179-2300651
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers