Very Computer

by **Carlos Moren** » Mon, 24 Mar 2003 02:04:56

Possibly dumb question (or dumb me, depending on the
answer):

Are cout and cerr thread-safe? (on Linux, RedHat 7.3
with its default g++ 2.96 compiler)

In other words, can I freely place cout and cerr
statements from multiple threads without proper
synchronization?

Thanks,

Carlos
--

by **M?ns Rullg?** » Mon, 24 Mar 2003 06:11:04

> Possibly dumb question (or dumb me, depending on the
> answer):

> Are cout and cerr thread-safe? (on Linux, RedHat 7.3
> with its default g++ 2.96 compiler)

Don't use that compiler. It's known to be buggy. Use gcc 3.2.2
instead.

Quote:> In other words, can I freely place cout and cerr
> statements from multiple threads without proper
> synchronization?

They should be, AFAIK. They most likely use printf internally, and
printf does all necessary locking.

--
M?ns Rullg?rd

by **Norm Dresne** » Mon, 24 Mar 2003 08:18:59

> > Possibly dumb question (or dumb me, depending on the
> > answer):

> > Are cout and cerr thread-safe? (on Linux, RedHat 7.3
> > with its default g++ 2.96 compiler)

> Don't use that compiler. It's known to be buggy. Use gcc 3.2.2
> instead.

If you feel you "have to" use a 2.9x compiler, 2.95.3 has served me reliably
for at least two years

Norm

by **Carlos Moren** » Mon, 24 Mar 2003 09:41:22

> > [... talking about g++ 2.96 ...]

> Don't use that compiler. It's known to be buggy. Use gcc 3.2.2
> instead.

I must confess that yes, I would *really* like to upgrade to
gcc 3.2.2, but first, I'll present a full disclosure of my
complete incompetence :-)

Can someone explain to me, or point me to some literature or
online documents where it is explained (in terms understandable
by us, common mortals) how to upgrade or downgrade compilers,
binary back and forward compatibility, etc.?

You know, I'm normally *extremely* scared about installing
or upgrading anything that is not originally packed with
the installation CD... But when talking about the compiler
and/or runtime libraries, then make that, absolutely
terrified.

From what I understand, if I replace the compiler, the runtime
libraries are also replaced, and all of the existing binaries
are broken. If I leave the original libraries (which to be
honest, I have no clue if and how I can do it), then the
programs compiled with the new compiler will not run properly,
since the executable is not binary-compatible with the runtime
libraries.

I wonder if I can install gcc 3.2.2 in addition to 2.96 (say,
put it in /usr/local/bin) and explicitly choose it to compile
my programs with it. What about my own shared libraries?
(some portions of my applications are installed as shared
libraries, and are used by many applications -- some of which
are already compiled with the older compiler...)

One of the reasons why I'm so terrified about doing this is
because the application I'm talking about is up and running,
on a server actually connected to the Internet; I wouldn't
want to start breaking existing software, binaries, services,
etc. I originally asked our providers to install RedHat 8
(among other reasons, because it comes with gcc 3.* -- I think
it's 3.2), and they refused, since they argued the kernel
is incompatible with dual-Athlon processors... I don't
want to imagine the possibility that I install something
that happens to be incompatible with the kernel... :-(

So, to summarize... My head is already hurting, even though
I have been merely *thinking* about it. Go figure when I
try to actually do it... :-(

Any advice? Any documents or some kind soul that would help
me understand this obscure and mysterious area of the
development process on Linux?

Thanks!

Carlos
--

by **M?ns Rullg?** » Tue, 25 Mar 2003 04:36:20

> > > [... talking about g++ 2.96 ...]

> > Don't use that compiler. It's known to be buggy. Use gcc 3.2.2
> > instead.

> I must confess that yes, I would *really* like to upgrade to
> gcc 3.2.2, but first, I'll present a full disclosure of my
> complete incompetence :-)

> Can someone explain to me, or point me to some literature or
> online documents where it is explained (in terms understandable
> by us, common mortals) how to upgrade or downgrade compilers,
> binary back and forward compatibility, etc.?

> From what I understand, if I replace the compiler, the runtime
> libraries are also replaced, and all of the existing binaries
> are broken. If I leave the original libraries (which to be
> honest, I have no clue if and how I can do it), then the
> programs compiled with the new compiler will not run properly,
> since the executable is not binary-compatible with the runtime
> libraries.

GCC includes the c++ runtime libraries, but libc is separate. The c++
libraries are incompatible between versions, but if you install a new
version the old ones can safely be left in place. Old programs will
use the old libraries.

Quote:> I wonder if I can install gcc 3.2.2 in addition to 2.96 (say,
> put it in /usr/local/bin) and explicitly choose it to compile
> my programs with it. What about my own shared libraries?
> (some portions of my applications are installed as shared
> libraries, and are used by many applications -- some of which
> are already compiled with the older compiler...)

Anything that's already compiled will continue to work. However, if
you install a new C++ compiler you won't be able to link new programs
against old C++ libraries. Recompiling all C++ libraries with the new
compiler will fix that, except that then the old programs will break.
In short, it can be a * business to upgrade a C++ compiler. Plain
C doesn't have any of these problems.

Quote:> One of the reasons why I'm so terrified about doing this is
> because the application I'm talking about is up and running,
> on a server actually connected to the Internet; I wouldn't
> want to start breaking existing software, binaries, services,

That seems wise.

Quote:> etc. I originally asked our providers to install RedHat 8
> (among other reasons, because it comes with gcc 3.* -- I think
> it's 3.2), and they refused, since they argued the kernel
> is incompatible with dual-Athlon processors...

So far, support for old hardware has never been dropped from the Linux
kernel, AFAIK. The newer kernel you get, the better it should work
with new stuff.

Quote:> So, to summarize... My head is already hurting, even though
> I have been merely *thinking* about it. Go figure when I
> try to actually do it... :-(

> Any advice? Any documents or some kind soul that would help
> me understand this obscure and mysterious area of the
> development process on Linux?

Try it on a non-critical machine and see what happens. It can't get
more than wrong. The best way to learn the proper way to do it is to
make a few mistakes and fix them. You're unlikely to make the same
mistake more than twice.

--
M?ns Rullg?rd

Very Computer

A question on thread-safety

A question on thread-safety

A question on thread-safety

A question on thread-safety

A question on thread-safety

A question on thread-safety