Re: Thread termination & Mutex bug?

[NTR]

Hi,

thanks for the reply. I'm using Visual C++ 6 SP5 and did all of the things
you mentioned. The problem lies in compiling the ccext2 libraries
(commoncpp2 1.0.8), which produces the following compile warning:
---
..\include\cc++/digest.h(386) : warning C4275: non dll-interface class
'ost::SHADigest<unsigned __int64,64>' used as base for dll-interface class
'ost::SHA64DigestHelper'
        ..\include\cc++/digest.h(386) : see declaration of
'SHA64DigestHelper'
..\include\cc++/digest.h(388) : warning C4251: 'h' : class
'ost::SHATumbler<unsigned __int32>' needs to have dll-interface to be used
by clients of class 'ost::SHA64DigestHelper'
..\include\cc++/digest.h(389) : warning C4251: 'a' : class
'ost::SHATumbler<unsigned __int32>' needs to have dll-interface to be used
by clients of class 'ost::SHA64DigestHelper'
---
Apparently these warnings cause linking for the Release build (Debug library
works fine) to fail:
---
Creating library Release/ccext2.lib and object Release/ccext2.exp
digest.obj : error LNK2001: unresolved external symbol "public: unsigned int
__thiscall ost::SHATumbler<unsigned __int32>::placeInBuffer(unsigned char
*)" (address@hidden@address@hidden@@address@hidden)
md5.obj : error LNK2001: unresolved external symbol "public: unsigned int
__thiscall ost::SHATumbler<unsigned __int32>::placeInBuffer(unsigned char
*)" (address@hidden@address@hidden@@address@hidden)
Release/ccext2.dll : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
---

Regards,
Niels

PS: The Mutex bug was a mistake on my behalf. Sorry. It works fine in
CommonC++ 1.9.1.

> I have a working build on win2000/XP without the use of LibXML. I
> removed(commented) the
> #define HAVE_LIBXML
> in win32/c++/config.h
> And then simply compiled the source without the makefile. (excluding
> xml.cpp) and linked with
> -lwsock32 -lws2_32.
> I was using gcc3.2 under MingW and hence also had to remove
> HAVE_OLD_IOSTREAM
> from the config as above.
> You don't mention which compiler you are using?
> Also there is a know issue with Thread::join() since it is in a #ifndef
> __WIN32__ and needs to be moved up the header outside of the block.
> (That fix was sent to me by someone else on the group thanks again).
> Hope this is of some help.
> Jon Wilson
>
> NTR wrote:
>
> >Hi,
> >
> >I have been working with CommonC++ 1.9.1 on Win2000 using the Thread,
Mutex,
> >Semaphore classes in a multi-threaded and I'm having problems with
> >terminating threads from "main(...)" as this cannot call "Terminate()" as
it
> >is protected. What is the reason for this? Couldn't it be public instead?
> >Could I just derive my own thread class and make a public "MyTerminate"
> >method which calls "this->Terminate()"?
> >
> >Anyway, I assume there is a good reason for this so ... how can I
terminate
> >a thread from the main method? I have noticed the Thread(bool), which is
> >supposed to construct a context for the main thread. However, I have no
idea
> >how to use this ... if anybody has an example it would be highly
> >appreciated.
> >
> >In addition, I'm experiencing problems with Mutex and Semaphore not being
> >thread safe in a producer/consumer scenario. Is this a known bug in
1.9.1?
> >
> >My scenario is something like:
> >main()
> >{
> >   ProducerConsumerBuffer buf;
> >   ProducerThread prod(buf);//Puts data in buf ... overwrites data in buf
> >   ConsumerThread cons(buf);//Waits on semaphore for data in buf
> >   prod.Start();
> >   cons.Start();
> >
> >   ccxx_sleep(100000);//In my case I process user input until ESC has
been
> >pressed
> >
> >   //Due to various reasons I cannot simply let threads
> >   //delete themselves when the main thread stops but have
> >   //to stop the threads first
> >   prod.Terminate();//WRONG
> >   cons.Terminate();//WRONG
> >}
> >
> >Regards,
> >Niels
> >
> >PS: Is the new commoncpp2 1.0.x endiansafe for TCP transmission from a
Win32
> >to an Irix 6.5 SGI computer? The reason I'm using 1.9.1 is that some
other
> >people have modified this version to be endiansafe for TCP transmission.
I
> >think they submitted a bug report...
> >PPS: I have previously downloaded commoncpp2 1.0.8, but haven't had any
luck
> >compiling it (without XML) on Win2000 is this still a problem?
> >
> >
> >_______________________________________________
> >Bug-commoncpp mailing list
> >address@hidden
> >http://mail.gnu.org/mailman/listinfo/bug-commoncpp
> >
> >
> >
>
>
>