From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15131 invoked by alias); 19 Nov 2003 06:27:47 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 15120 invoked from network); 19 Nov 2003 06:27:42 -0000 Received: from unknown (HELO mail.npsl.co.uk) (213.232.85.2) by sources.redhat.com with SMTP; 19 Nov 2003 06:27:42 -0000 Received: from 81.96.65.27 (helo=mouse) by mail.npsl.co.uk with smtp (Yam) id DpdtOCBl4cvDG; Wed, 19 Nov 2003 06:27:41 GMT From: "Mark Weaver" To: Subject: RE: [pthreads-win32] How can you use errno with pthreads DLL? Date: Wed, 19 Nov 2003 06:27:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <9D3D7CEF3A236243AF0335652672E348027AEA84@maxis-mb1.max.ad.ea.com> X-SW-Source: 2003/txt/msg00137.txt.bz2 > > I am trying to use pthreads-win32 but have run into a problem. I get an > error return value from pthreads-win32 but I can't use the errno because > pthreads-win32 uses the errno for its C runtime library but my app uses > its own errno from its C runtime library. How do I read the errno from > pthreads-win32's view of things inside its DLL? I don't see a function > for such a thing. I looked at the pthread.dsp file and it is set to use > "Multithreaded DLL" library mode, so I figure that pthreads-win32 is > more or less forcing me to use that mode. Well my application doesn't > use that and can't do so. > > So is it not possible for there to simply be a pthreads-win32 function > to get the errno? It may not be highly pretty but as it stands right now > pthreads-win32 is unusable because of this problem. > Well it seems to me that you have a few options here: 1. Recompile pthreads against the same runtime library that you are using rather than MSVC. This is more than likely the best solution as having two different CRTs is nasty bloat: think two separate heaps and copies of all support data structure, not to mention the additional code size. 2. Explicitly import and use the function "_errno" from MSVCRT.DLL. To avoid the linker going nuts with two copies of most of the standard C library symbols the least painful way to do this is to use LoadLibrary and GetProcAddress. _errno basically is a wrapper around some thread local storage: errno needs to be per thread in a multi-threaded environment. TBH, I thought that pthreads didn't really use errno but opted to return an errno.h defined status code. sem_* and sched_* do, so if you don't use those you could bypass this problem.