[Insight-developers] RE: SGI builds and libCio.a
Lorensen, William E (Research)
lorensen@crd.ge.com
Wed, 12 Mar 2003 13:22:07 -0500
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C2E8C4.40A5EA89
Content-Type: text/plain
Did you run on a multi cpu sgi?
-----Original Message-----
From: Bill Hoffman [mailto:bill.hoffman@kitware.com]
Sent: Wednesday, March 12, 2003 1:20 PM
To: Lorensen, William E (Research); Insight-Developers
Cc: James V. Miller
Subject: SGI builds and libCio.a
The SGI builds are now failing. It seems to be some conflict between the new vnl and the libCio.a
that we provide. I think it might be time to try and remove this library.
SGI does not recommend that the _PTHREADS options be defined,
you can see that here:
http://www.sgi.com/tech/stl/thread_safety.html <http://www.sgi.com/tech/stl/thread_safety.html>
Alloc.h uses three different locking primitives depending on the environment. In addition, it can be
forced to perform no locking by defining _NOTHREADS. The three styles of locking are:
* Pthread mutexes. These are used if _PTHREADS is defined by the user. This may be done on SGI
machines, but is not recommended in performance critical code with the currently (March 1997)
released versions of the SGI Pthreads libraries.
* Win32 critical sections. These are used by default for win32 compilations with compiler
options that request multi-threaded code.
* An SGI specific spin-lock implementation that is usable with both pthread and sproc threads.
This could serve as a prototype implementation for other platforms. This is the default on SGI/MIPS
platforms.
I was able to build ITK without this library and the new vnl, and everything works.
I belive the problem may have come from a poorly configured gcc on a sun machine.
I really do not think it is a good idea for user code to add the -D_PTHREADS option on the command
line.
-Bill
------_=_NextPart_001_01C2E8C4.40A5EA89
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META content="MSHTML 5.50.4919.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=811402118-12032003><FONT face=Arial color=#0000ff size=2>Did
you run on a multi cpu sgi?</FONT></SPAN></DIV>
<BLOCKQUOTE>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Bill Hoffman
[mailto:bill.hoffman@kitware.com]<BR><B>Sent:</B> Wednesday, March 12, 2003
1:20 PM<BR><B>To:</B> Lorensen, William E (Research);
Insight-Developers<BR><B>Cc:</B> James V. Miller<BR><B>Subject:</B> SGI builds
and libCio.a<BR><BR></FONT></DIV>The SGI builds are now failing.
It seems to be some conflict between the new vnl and the libCio.a that we
provide. I think it might be time to try and remove this
library. <BR><BR>SGI does not recommend that the _PTHREADS options
be defined,<BR>you can see that here:<BR><BR><A
href="http://www.sgi.com/tech/stl/thread_safety.html"
eudora="autourl">http://www.sgi.com/tech/stl/thread_safety.html</A><BR><BR>Alloc.h
uses three different locking primitives depending on the environment. In
addition, it can be forced to perform no locking by defining
<TT>_NOTHREADS</TT>. The three styles of locking are:
<UL>
<LI>Pthread mutexes. These are used if <TT>_PTHREADS</TT> is defined by the
user. This may be done on SGI machines, but is not recommended in
performance critical code with the currently (March 1997) released versions
of the SGI Pthreads libraries.
<LI>Win32 critical sections. These are used by default for win32
compilations with compiler options that request multi-threaded code.
<LI>An SGI specific spin-lock implementation that is usable with both
pthread and sproc threads. This could serve as a prototype implementation
for other platforms. This is the default on SGI/MIPS platforms.
</LI></UL><BR>I was able to build ITK without this library and the new vnl,
and everything works.<BR><BR>I belive the problem may have come from a poorly
configured gcc on a sun machine.<BR>I really do not think it is a good idea
for user code to add the -D_PTHREADS option on the command
line.<BR><BR>-Bill<BR></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C2E8C4.40A5EA89--