This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Apple gcc 3.1 and OpenOffice.org


Hi Stan,

Just a quick note: 

A. first to say "Thanks" to everyone doing gcc work in support of the Apple 
gcc 3.1  gcc 3.1 on OSX 10.2 was a huge improvement in fixing issues in 
the OpenOffice.org build over gcc 2.95.  With it we have been able to 
remove most of the hacks and workarounds we had to add to begin the port.


B.  We seem to have run into two issues with OOo and gcc 3.1 in OSX 10.2.  

1. The first is that local static objects in methods (and templates) seem 
to create common symbols that prevent a dynlib from being created by the 
linker.  The best example of this is the classic C++ "singleton" often 
used by C++ programmers.  The use of -fno-common does not seem to help in 
this case.  The only workaround is to add a local static pointer to that 
object intiialized to null and a mutex (for thread safelty) and then 
intialize the object off the heap with new  just once.

2. We have run into a seeming bug in pthread_detach that generates a lot of 
memory corruption.  Preventing the call to pthread_detach seems to be the 
only workaround we have found so far.  This bug seems to be new in 10.2.  
I have no idea if this a compiler miscompilation issue for kernel code or 
a real kernel pthreads bug.  It is interesting to note that a very similar 
bug existed in the FreeBSD kernel (not properly deal with pthread 
attributes when detaching) until quite recently.

Does anyone know if upgrading to the latest gcc version will in any way 
help solve problem 1.  If needed, I think we can build a simple test case 
to submit if need anyone here would like it.

Also, if anyone has any info about pthread_detach any other related kernel 
fixes mentioned in an earlier post:

 http://gcc.gnu.org/ml/gcc/2002-10/msg00596.html

Can they tell us the right mailing list to join to track such issues?

Thanks,

Kevin





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]