threads-list Mailing List for C++ Threads

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> void MyThread::stop(){
>         this->stop();
> }

I'm a jerk. Have fixed my problem...
This looks like an endless recursion to me which crushes the system...

Steve 

Hi,
today i first try out the c++ threads library,
and i get a complete system crash when the function Pthread::stop() is called.

Is this a bug or did i use the wrong function???
Here is my Implematation, which is quit simple:

MyThread::MyThread():Pthread(){}

void MyThread::start(){
        this->run();
}   
void MyThread::stop(){
        this->stop();
}    
int MyThread::thread(void *){
        while(true){
                cout << "Never stop running until stop!" << endl;
                sleep(1);
        }
}

My threads library version is 3.6.2 on a Suse 8.2 Linux Distribution

Thanx for your help and time.

Steve
_________________________________________________________
Mit WEB.DE FreePhone? mit hochster Qualitat ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201

I came across some old code source that used a class
called cpp_threads::Pthread as basis for inheritance
of a  thread class:

eg: class x : public cpp_threads::Pthread

However I can't seem to find any documentation, much
less any include files that seem to use it.

In the source file there is reference to 
#include <thread.h>

However i don't seem to have this header file on my
system (or at least the one i am expecting

I did find one here:
./usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/thread.h

However, there is no mention of a namespace called
cpp_threads or a class called Pthread.

I'm using g++ (rh linux 3.2.2-5)

What do I need to do so that I can get this to work on
my system?

Thanks in advance

Dave

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what youre looking for faster
http://search.yahoo.com

Hi Everyone,

I just downloaded the threads package version 3.6 for the first time and I
have run a make install on it, however I can't figure out what the compiler
flags and linker options for KDevelop is. Is anyone using KDevelop or know
what the flags are?

Thanks in advance,
Julie.

 To compile with a bleeding edge, automake and friends.  The following will=
=20
work, as tested.

 Remove aclocal.m4 and acinclude.m4
 Copy (or link) the following from your libtool distribution:
   config.guess, config.sub, ltmain.sh

 Rename configure.in to configure.ac, and replace the AC_INIT macro with th=
e=20
folowing definition:

AC_INIT([C++Threads],[4.0a],[http://sourceforge.net/tracker/?group_id=3D357=
5&atid=3D103575])

  You may need to run 'automake -f' separately, but otherwise running=20
autogen.sh and then configureing and compiling will compile, with some=20
messages that can be ignored so far.

=D6rn

  If you use the newest version of automake and autoconf utilities, you wil=
l=20
get a message stating that AM_INIT_AUTOMAKE is from a different version,
and that aclocal.m4 files need to be regenerated.  This means, that the two
files aclocal.m4 and acinclude.m4 need to be erased, and their creation
forced, with aclocal and automake -f (force creation of missing files).  I=
=20
don't recommend doing this, because there appears to be a difference betwee=
n=20
the GNU utilities, and the utilities as they are distributed by the differe=
nt=20
linux distributors.  An example, here, the AC_PROG_LIBTOOL macro doesn't=20
work, and a more sophisticated aclocal file is needed, than just the one=20
autogenerated with the aclocal program.  Using one from a development suite=
,=20
should work, it should have most of the components included.

  I'll update the acinclude.m4 file as soon as possible, meanwhile if you f=
ind=20
a way to do this, neatly.  Any contribution is welcome.

=D6rn

>   The problem is that threads uses an outdated version of the m4 files, for
> compiling.  I'm aware of this, and have changed this in the CVS repository
> which should compile now under newer versions of automake.

Thanks for your answer. I updated threads via CVS, but it seems the 
version I got still depends on and old version of automake, and I have 
automake 1.7.2 installed on my system. It complains on the config.in 
file. What to do now? Below is the output from my compile attempt.

/ Martin Magnusson

=================================================================

/home/martin/threads> aclocal

/home/martin/threads> autogen.sh
WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
WARNING: and `config.h.top', to define templates for `config.h.in'
WARNING: is deprecated and discouraged.

WARNING: Using the third argument of `AC_DEFINE' and
WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
WARNING: `acconfig.h':

WARNING:   AC_DEFINE([NEED_MAIN], 1,
WARNING:             [Define if a function `main' is needed.])

WARNING: More sophisticated templates can also be produced, see the
WARNING: documentation.
configure.in:51: version mismatch.  This is Automake 1.7.2,
configure.in:51: but the definition used by this AM_INIT_AUTOMAKE
configure.in:51: comes from Automake 1.6.3.  You should recreate
configure.in:51: aclocal.m4 with aclocal and run automake again.
examples/Makefile.am: required file `./depcomp' not found
/usr/autotool/devel/share/automake-1.7/am/depend2.am: am__fastdepCXX 
does not appear in AM_CONDITIONAL
threads/Makefile.am: object `cloning.lo' created both with libtool and 
without
threads/Makefile.am: object `thread.lo' created both with libtool and 
without
threads/Makefile.am: object `mutex.lo' created both with libtool and without
threads/Makefile.am: object `cond.lo' created both with libtool and without
threads/Makefile.am: object `semaphore.lo' created both with libtool and 
without

threads/Makefile.am: object `attributes.lo' created both with libtool 
and without
threads/Makefile.am: object `spinlock.lo' created both with libtool and 
without
threads/Makefile.am: object `thread_lists.lo' created both with libtool 
and without
threads/Makefile.am: object `wait_queue.lo' created both with libtool 
and without
threads/Makefile.am: object `shared.lo' created both with libtool and 
without
threads/Makefile.am: object `io.lo' created both with libtool and without
threads/Makefile.am: object `exception.lo' created both with libtool and 
without

threads/Makefile.am: object `socket.lo' created both with libtool and 
without
threads/Makefile.am: object `buffer.lo' created both with libtool and 
without
threads/Makefile.am: object `stack.lo' created both with libtool and without
threads/Makefile.am: object `sock_buffer.lo' created both with libtool 
and without
threads/Makefile.am: object `async_io.lo' created both with libtool and 
without
threads/Makefile.am: object `descriptors.lo' created both with libtool 
and without
threads/Makefile.am: object `systemlib.lo' created both with libtool and 
without

threads/Makefile.am: object `linked_list.lo' created both with libtool 
and without
/usr/autotool/devel/share/automake-1.7/am/depend2.am: am__fastdepCXX 
does not appear in AM_CONDITIONAL
/usr/autotool/devel/share/automake-1.7/am/depend2.am: am__fastdepCC does 
not appear in AM_CONDITIONAL

/home/martin/threads> configure
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking for gcc... gcc
checking for C compiler default output... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking dependency style of g++... none
checking for ld used by GCC... /usr/i686-pc-cygwin/bin/ld.exe
checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes
checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object 
files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependant libraries... file_magic file format 
pei*-i3
6(.*architecture: i386)?
checking command to parse /usr/bin/nm -B output... ok
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -DDLL_EXPORT
checking if gcc PIC flag -DDLL_EXPORT works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/i686-pc-cygwin/bin/ld.exe) supports 
shared li
raries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
creating libtool
configure: creating ./config.status
config.status: creating Makefile
config.status: creating threads/Makefile
config.status: creating doc/Makefile
config.status: creating man/Makefile
config.status: creating examples/Makefile
config.status: creating config.h
config.status: executing depfiles commands

/home/martin/threads> make
cd . && /bin/bash /home/martin/threads/missing --run autoheader
WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
WARNING: and `config.h.top', to define templates for `config.h.in'
WARNING: is deprecated and discouraged.

WARNING: Using the third argument of `AC_DEFINE' and
WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
WARNING: `acconfig.h':

WARNING:   AC_DEFINE([NEED_MAIN], 1,
WARNING:             [Define if a function `main' is needed.])

WARNING: More sophisticated templates can also be produced, see the
WARNING: documentation.
touch ./config.h.in
cd . && /bin/bash ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
make  all-recursive
make[1]: Entering directory `/home/martin/threads'
Making all in threads
make[2]: Entering directory `/home/martin/threads/threads'
Makefile:346: *** missing separator.  Stop.
make[2]: Leaving directory `/home/martin/threads/threads'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/martin/threads'
make: *** [all] Error 2

/home/martin/threads>

On Tuesday 25 February 2003 17:23, Martin Magnusson wrote:
> Hello! I'm trying to compile threads-3.6 under Cygwin, with no luck. I'm
> using a recent (a couple of weeks old) version of the Cygwin utilities.
> I've included my output from autogen.sh below. Seems automake is
> complaining about aclocal.m4. I've tried running aclocal in the threads
> directory, but that didn't help. I should say that I've never used
> automake before, so I might be missing something there.
>
> Help, anybody?
>
  The problem is that threads uses an outdated version of the m4 files, for
compiling.  I'm aware of this, and have changed this in the CVS repository
which should compile now under newer versions of automake.

=D6rn

> / Martin Magnusson
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> /home/martin/threads-3.6> autogen.sh
> WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
> WARNING: and `config.h.top', to define templates for `config.h.in'
> WARNING: is deprecated and discouraged.
>
> WARNING: Using the third argument of `AC_DEFINE' and
> WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
> WARNING: `acconfig.h':
>
> WARNING:   AC_DEFINE([NEED_MAIN], 1,
> WARNING:             [Define if a function `main' is needed.])
>
> WARNING: More sophisticated templates can also be produced, see the
> WARNING: documentation.
> aclocal.m4:1704: error: m4_defn: undefined macro: _m4_divert_diversion
> autoconf/functions.m4:1277: AM_FUNC_OBSTACK is expanded from...
> aclocal.m4:1704: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
> autoheader: /usr/autotool/devel/bin/autom4te failed with exit status: 1
> aclocal.m4:1704: error: m4_defn: undefined macro: _m4_divert_diversion
> autoconf/functions.m4:1277: AM_FUNC_OBSTACK is expanded from...
> aclocal.m4:1704: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
> configure.in: `AM_INIT_AUTOMAKE' must be used
> automake: your implementation of AM_INIT_AUTOMAKE comes from an
> automake: old Automake version.  You should recreate aclocal.m4
> automake: with aclocal and run automake again.
> automake: no `Makefile.am' found or specified
> aclocal.m4:1704: error: m4_defn: undefined macro: _m4_divert_diversion
> autoconf/functions.m4:1277: AM_FUNC_OBSTACK is expanded from...
> aclocal.m4:1704: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Threads-list mailing list
> Thr...@li...
> https://lists.sourceforge.net/lists/listinfo/threads-list

Hello! I'm trying to compile threads-3.6 under Cygwin, with no luck. I'm 
using a recent (a couple of weeks old) version of the Cygwin utilities. 
I've included my output from autogen.sh below. Seems automake is 
complaining about aclocal.m4. I've tried running aclocal in the threads 
directory, but that didn't help. I should say that I've never used 
automake before, so I might be missing something there.

Help, anybody?

/ Martin Magnusson

=================================================================

/home/martin/threads-3.6> autogen.sh
WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
WARNING: and `config.h.top', to define templates for `config.h.in'
WARNING: is deprecated and discouraged.

WARNING: Using the third argument of `AC_DEFINE' and
WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
WARNING: `acconfig.h':

WARNING:   AC_DEFINE([NEED_MAIN], 1,
WARNING:             [Define if a function `main' is needed.])

WARNING: More sophisticated templates can also be produced, see the
WARNING: documentation.
aclocal.m4:1704: error: m4_defn: undefined macro: _m4_divert_diversion
autoconf/functions.m4:1277: AM_FUNC_OBSTACK is expanded from...
aclocal.m4:1704: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
autoheader: /usr/autotool/devel/bin/autom4te failed with exit status: 1
aclocal.m4:1704: error: m4_defn: undefined macro: _m4_divert_diversion
autoconf/functions.m4:1277: AM_FUNC_OBSTACK is expanded from...
aclocal.m4:1704: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
configure.in: `AM_INIT_AUTOMAKE' must be used
automake: your implementation of AM_INIT_AUTOMAKE comes from an
automake: old Automake version.  You should recreate aclocal.m4
automake: with aclocal and run automake again.
automake: no `Makefile.am' found or specified
aclocal.m4:1704: error: m4_defn: undefined macro: _m4_divert_diversion
autoconf/functions.m4:1277: AM_FUNC_OBSTACK is expanded from...
aclocal.m4:1704: the top level
autom4te: /usr/bin/m4 failed with exit status: 1

Hi,

I found this little project shortly and I played around with the library.=
 I=20
like it very much, but I have a question regarding the debugging.

It's possible to get the thread information of a program inside the gdb=20
debugger? How much effort takes needs it to get it done or is it simply n=
ot=20
possible.

Bye,
Stefan

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dipl. Phys.
Stefan Knorr

LTT GmbH
R&D-Department
Friedrich-Bergius-Ring 15
D-97076 Wuerzburg
Germany
T: +49.931.35961-20
F: +49.931.35961-50
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Hello,

I'm using C++ threads in my program running under Linux and I've the =
following problem.

In the context of thread 2 (a new thread spawned using a C++ library =
class) I create a new C++ object and put it in a list. Then, that thread =
2 dies. In a second moment I want to retrieve that previous object from =
a the main program thread. The object seems to be retrived, but when I I =
wish to destry that object and I invoke a=20

delete MyObject

the program stops and I get a segmentation fault error.

How can this be fixed ?

Thanks Alot Everybody
Matteo=20

1.  Bug in install?  I did a ./autogen, configure, make, make install.
Programs compile fine, but can't execute b/c the can't find the libthreads.so.
So I copied everything in the threads-3.5/src/.libs dir to /usr/lib.  Now
everything will execute.  This is on Debian 3.0b.

Now for the real problem.
==================
This code compiles fine.  It even executes fine with one thread.  But if I try
to create two threads, and then call each of their thread() methods, the two
methods run sequentially.   The two threads should be competing for the stdout,
no?

Thanks
~S

#include <string>
#include <iostream>

#include <thread.h>

using namespace std;
using namespace cpp_threads;

class Nums: public pthread
{
 public:
  Nums(int id);
  int thread(void *);
};

Nums::Nums(int id)
 :pthread(id)
{
 cout <<"in constructor\n";
}

int Nums::thread(void *)
{
 for(int i=0; i < 100; i++)
 {
  cout <<"\n["<< id() <<"]->"<< i << endl;
 }
}

int main()
{
 Nums num(5);
 Nums num2(99);

 cout <<"before starting the thread\n";
 num.thread(NULL);                            <-----|--these should compete for
the stdout
 num2.thread(NULL);                         <-----+
 cout <<"after starting the thread\n";
 cout <<"after starting the thread\n";
 cout <<"after starting the thread\n";
 cout <<"DONE\n";

 return 0;
}

I am relatively new to g++. I am trying to build a simple test program using
C++Threads, and the pthreads class.

I am pretty sure I have the implementation correct, but I keep getting this
compiler output.

username#  g++ test.cpp
/tmp/ccuC6dDp.o: In function `numbers::numbers(int)':
/tmp/ccuC6dDp.o(.text+0x13): undefined reference to
`cpp_threads::pthread::pthread(int)'
/tmp/ccuC6dDp.o(.text+0x37): undefined reference to
`cpp_threads::pthread::~pthread(void)'
/tmp/ccuC6dDp.o: In function `numbers::~numbers(void)':
/tmp/ccuC6dDp.o(.text+0x76): undefined reference to
`cpp_threads::pthread::~pthread(void)'
/tmp/ccuC6dDp.o: In function `numbers type_info function':
/tmp/ccuC6dDp.o(.gnu.linkonce.t.__tf7numbers+0x10): undefined reference to
`cpp_threads::pthread type_info function'
/tmp/ccuC6dDp.o(.gnu.linkonce.t.__tf7numbers+0x1a): undefined reference to
`cpp_threads::pthread type_info node'
collect2: ld returned 1 exit status

It looks to me like a linking issue.  I am guessing that I need another option
in my build command "g++ test.cpp".

Below is my code:
#include <iostream>
#include <string>
#include <thread.h>
using namespace std;
using namespace cpp_threads;

class numbers : public pthread
{
 public:
  numbers(int id);
  ~numbers();
  int thread(void *ptr);
};

/*
numbers::numbers(void *ptr)
 : pthread(ptr)
{}
*/

numbers::numbers(int id)
 :pthread(id)
{

}

numbers::~numbers()
{}

int numbers::thread(void *ptr)
{
 int i;
 for(i=0; i<1000; i++)
 {
  cout <<"->"<< i << endl;
 }

 return 0;
}

int main()
{
 cout <<"before calling thread.\n";
 //this is where I want my test thread() to start.
 cout <<"AFTER calling the thread\n";

 return 0;
}

I am relatively new to g++. I am trying to build a simple test program using
C++Threads, and the pthreads class.

I am pretty sure I have the implementation correct, but I keep getting this
compiler output.

username#  g++ test.cpp
/tmp/ccuC6dDp.o: In function `numbers::numbers(int)':
/tmp/ccuC6dDp.o(.text+0x13): undefined reference to
`cpp_threads::pthread::pthread(int)'
/tmp/ccuC6dDp.o(.text+0x37): undefined reference to
`cpp_threads::pthread::~pthread(void)'
/tmp/ccuC6dDp.o: In function `numbers::~numbers(void)':
/tmp/ccuC6dDp.o(.text+0x76): undefined reference to
`cpp_threads::pthread::~pthread(void)'
/tmp/ccuC6dDp.o: In function `numbers type_info function':
/tmp/ccuC6dDp.o(.gnu.linkonce.t.__tf7numbers+0x10): undefined reference to
`cpp_threads::pthread type_info function'
/tmp/ccuC6dDp.o(.gnu.linkonce.t.__tf7numbers+0x1a): undefined reference to
`cpp_threads::pthread type_info node'
collect2: ld returned 1 exit status

It looks to me like a linking issue.  I am guessing that I need another option
in my build command "g++ test.cpp".

Below is my code:
#include <iostream>
#include <string>
#include <thread.h>
using namespace std;
using namespace cpp_threads;

class numbers : public pthread
{
 public:
  numbers(int id);
  ~numbers();
  int thread(void *ptr);
};

/*
numbers::numbers(void *ptr)
 : pthread(ptr)
{}
*/

numbers::numbers(int id)
 :pthread(id)
{

}

numbers::~numbers()
{}

int numbers::thread(void *ptr)
{
 int i;
 for(i=0; i<1000; i++)
 {
  cout <<"->"<< i << endl;
 }

 return 0;
}

int main()
{
 cout <<"before calling thread.\n";
 //this is where I want my test thread() to start.
 cout <<"AFTER calling the thread\n";

 return 0;
}

Hy, I'm a beginner in C++, and I would like a server with multi-thread.

But, I can't Install your Library: pb with "host system type"

On Sun, Oct 28, 2001 at 11:38:49AM +0100, Alexander Grutsch wrote:
> 
> hi
> 
> i can't compile the threads library. it's complaining about a missing
> __sched_yield function. can you help me please? i'm using the latest
> threads library (v 2.1)

Considering the wonderful information you provided, I have to following
advise:

- try upgrading your libc, if that doesn't help
- try upgrading your binutils, if that doesn't help
- try upgrading your gcc/g++, if that doesn't help
- try getting a matching libstdc++, if that doesn't help
- try (re)installing your Operating System, if that doesn't help
- try a different Operating System.

It works here,

-- 
Carlo Wood <ca...@al...>

hi

i can't compile the threads library. it's complaining about a missing
__sched_yield function. can you help me please? i'm using the latest
threads library (v 2.1)

regards

trag

oh... and i am using gcc 3.0.2 btw

On Fri, 26 Oct 2001, Christof Damian wrote:
> Hi,
> i just started using the threads classes (used my own class before),
> but i now have a problem. i have to link to pthreads too, because
> gtk++ needs it (and some of my functions need it it too). but whenever
> you link a threads-programm to libpthread it stops working. you can
> reproduce that with one of the examples:
> 
> > g++  -O2 -Wall -s  -o consumer  consumer.o ../threads/libthreads.a
> > echo test | ./consumer
> Enter text for consumer: got 'test'
> Consumed: 'test'
> return value 0
> > g++  -O2 -Wall -s  -o consumer  consumer.o ../threads/libthreads.a -lpthread
> > echo test | ./consumer
> [hangs until ctrl-c]
> 
> is there a way to make this work ?
> 
> thanks,
> damian

-- 
Christof Damian         
Technical Director, guideguide ltd.	            

Hi,
i just started using the threads classes (used my own class before),
but i now have a problem. i have to link to pthreads too, because
gtk++ needs it (and some of my functions need it it too). but whenever
you link a threads-programm to libpthread it stops working. you can
reproduce that with one of the examples:

> g++  -O2 -Wall -s  -o consumer  consumer.o ../threads/libthreads.a
> echo test | ./consumer
Enter text for consumer: got 'test'
Consumed: 'test'
return value 0
> g++  -O2 -Wall -s  -o consumer  consumer.o ../threads/libthreads.a -lpthread
> echo test | ./consumer
[hangs until ctrl-c]

is there a way to make this work ?

thanks,
damian
-- 
Christof Damian         
Technical Director, guideguide ltd.	            

  The CVS has taken a lot of changes, lately.

  First, the code that has limited the threads library to i386 platforms has 
been removed.  Second, there has been installed code for other kinds of CPU 
types, such as alpha, sparc and ppc in the spinlock, but it is here where 
atomic operations are truly needed.

  As a result of these changes, the library has been successfully compiled 
and tested on the above platforms.   Both multi-processor and single-cpu 
systems, running linux 2.2 (sourceforge compile farm).

  Support for other Unix systems is being prepared, these preparations 
include both namespace and package name changes.

Sincerely,
  Orn

Help support the relief efforts for the recent attack against America and get a really cool 
Patriotic T-Shirt! We have the GOD BLESS AMERICA Flag T-shirt you've been looking for, 
along with other commemorative designs and related items, and your purchase will support 
working Americans and help the relief efforts.
Click on this link or copy and paste it in your web browser:

http://www.customdartboards.com

God Bless us all !
Thank you for your interest ! 

This E-mailing has been sent to you as a person interested in the information enclosed. 
We know your time is valuable. This is a one-time mailing. If you want to be forwarded 
to a nation wide remove list click on the link below and put "remove" in the subject line.

Remove link:
mailto:cus...@cu...

This E-mail is not SPAM under the Federal Regulatory laws of the United States. 
This message is being sent to you in compliance with the proposed Federal Legislation for 
commercial e-mail (H.R.4176-SECTION 101 PARAGRAPH (e) (1) (A)) and Bill s.1618 TITLE III 
passed by the 105th US Congress. We sincerely apologize for any inconvenience. 
This message is not intended for residents of WA, NV, CA, & VA. Screening of addresses 
has been done to the best of our technical ability. If you are a California, Nevada, 
Washington, or Virginia resident please follow the instructions above and you will be 
permanently removed from our list immediately.
Thank You

* This advertisement is not endorsed or sanction by any national relief organization. 
Customers may request a donation report by using the customer service link on the web site.

sunnudagur 7. október 2001 16:59, Carlo Wood skrifaði:
>
> These methods are not part of the Standard, and therefore removed.
> Instead of adding a "work-around", I'd prefer it if you didn't use
> these methods but started to use the standard way instead.
>
  It's what I'm looking at now...

> If I can be of any help let me know.
>
  The only place its really needed, is in the thread_io class... it has 
putf(..) method, that allows for formatted data through a socket, streamed.  
Question is how much it would be desired, it would mean I'd need to use C 
vsprintf if a standard wasn't there?

> You should also get rid of the deprecated strstream completely.
> You could do the following:
>
> #if __GNUC__ < 3
> #include <strstream.h>
> struct stringstream : public strstream {
>   typedef streampos pos_type;
> };
> #else
> #include <sstream>
> #endif
>
> Then use stringstream everywhere, and use pubseekoff/pubseekpos
> everywhere instead of seekoff/seekpos.
>
> I think this will catch most problems related with stringstreams.

  Ok, will do that... thanks.

Orn

On Sun, Oct 07, 2001 at 04:25:42PM +0200, Orn E . Hansen wrote:
>   The compilation against 3.0 needs some work-around, as iostream and 
> strstream are missing formatted output methods.

These methods are not part of the Standard, and therefore removed.
Instead of adding a "work-around", I'd prefer it if you didn't use
these methods but started to use the standard way instead.

If I can be of any help let me know.

You should also get rid of the deprecated strstream completely.
You could do the following:

#if __GNUC__ < 3
#include <strstream.h>
struct stringstream : public strstream {
  typedef streampos pos_type;
};
#else
#include <sstream>
#endif

Then use stringstream everywhere, and use pubseekoff/pubseekpos
everywhere instead of seekoff/seekpos.

I think this will catch most problems related with stringstreams.

-- 
Carlo Wood <ca...@al...>

  I filed two bugs against  the library, the first is the compilation against 
3.0, and the other is the one we discussed yesterday.  I've done work on 
both, and they "appear" to be fixed in the CVS... I'll do some more testing 
before I'm sure.

  The compilation against 3.0 needs some work-around, as iostream and 
strstream are missing formatted output methods.

Orn

  Now, it locks up... and the reason is that for some reason the content in 
the mutex variable has changed... a bug.  I fixed it by using a spinlock 
instead... that's not a good solution though.

Orn

2000	Jan	Feb	Mar	Apr (6)	May (3)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2001	Jan	Feb (2)	Mar (1)	Apr	May	Jun (4)	Jul (20)	Aug	Sep	Oct (30)	Nov	Dec
2002	Jan (1)	Feb (3)	Mar (1)	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2003	Jan	Feb (5)	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec
2004	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep (2)	Oct	Nov	Dec