public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Ross Johnson <rpj@ise.canberra.edu.au>
To: vc <vcotirlea@hotmail.com>
Cc: pthreads-win32@sources.redhat.com
Subject: Re: pthread Win32 - runtime lib VC++ setting
Date: Wed, 14 May 2003 03:32:00 -0000	[thread overview]
Message-ID: <3EC1B896.5060104@ise.canberra.edu.au> (raw)
In-Reply-To: <Law12-OE51YILoygXLs00000031@hotmail.com>

Thanks very much for this, and apologies for the inconvenience. As has been 
mentioned, I don't use the IDE. I've edited pthread.dsp directly to change the 
flags so I hope it's OK. It's now in CVS.

Ross

vc wrote:
> Do you remember that I've asked about which flag should I use:
> /MT - link statically the CRT (meaning that each module: dll, exe has it's
> own copy of CRT)
> or
> /MD - link dinamically the CRT (meaning that the dlls, exe are using the
> same CRT copy)
> 
> The idea is that all the tries that I've done with semaphore1.c (told about
> them in the before email) test were done having
> the pthreadVC.dll built using the /MT flag (this is what you have in the cvs
> sources
> by default set for release version for the .dsp project).
> 
> I've tried to build now the pthreadVC.dll using the other flag: /MD, as this
> is the one recommended
> by M$ when having dlls (if you are interested why, I can give you a very
> short explanation), and now
> the output of the test is:
> 
> semaphore1.c
> ... Running VC test: semaphore1.exe
> thread: sem_trywait 1: Resource temporarily unavailable
> thread: ok 2
> main: sem_trywait 1: Resource temporarily unavailable
> main: ok 2
> ...... Passed
> 
> I have no idea what's with "Resource temporarily unavailable" but the test
> passed !!!
> So, it seems that the problem is related with having just one copy of the
> CRT in exe and also
> in dll.
> 
> btw, in the pthread.dsp from your cvs you have the /MT flag set for release,
> but in Makefile you are using the /MD flag, so I assume that the problem is
> just in the .dsp file.
> 
> Viv
> 
> ----- Original Message -----
> From: "vc" <vcotirlea@hotmail.com>
> To: "Ross Johnson" <rpj@ise.canberra.edu.au>
> Sent: Tuesday, May 13, 2003 5:50 PM
> Subject: Re: pthread Win32 - runtime lib VC++ setting
> 
> 
> 
>>Hi,
>>
>>Thanks for your answer.
>>
>>In the semaphore1.c I've done the following:
>>1) check to see if NEED_SEM is defined
>>2) print the errno
>>So, now the code in semaphore1.c looks like:
>>  sem_t s;
>>  int result;
>>
>>#ifdef NEED_SEM
>>  printf("NEED_SEM is defined\n");
>>#else
>>  printf("NEED_SEM is not defined\n");
>>#endif
>>
>>  assert(sem_init(&s, PTHREAD_PROCESS_PRIVATE, 0) == 0);
>>
>>  assert((result = sem_trywait(&s)) == -1);
>>
>>  if ( result == -1 )
>>  {
>>    perror("thread: sem_trywait 1"); // No error
>>    printf("errno = %d\n", errno);
>>    assert(errno == EAGAIN);
>>  }
>>
>>The output for this code is:
>>semaphore1.c
>>... Running VC test: semaphore1.exe
>>NEED_SEM is not defined
>>thread: sem_trywait 1: No error
>>errno = 0
>>Assertion failed: (errno == EAGAIN), file semaphore1.c, line 98
>>NMAKE : fatal error U1077: '.\semaphore1.exe' : return code '0x1'
>>Stop.
>>NMAKE : fatal error U1077: '"D:\Program Files\Microsoft Visual Studio .NET
>>2003\Vc7\bin\nmake.exe"' : return code '0x2'
>>Stop.
>>
>>
>>So it seems that not the NEED_SEM is the problem, as it seems to be
>>undefined.
>>
>>I also have tried this test with the binaries that I download on 4 Nov
> 
> 2002
> 
>>from the following link:
>>http://gd.tuwien.ac.at/gnu/sourceware/pthreads-win32/dll-latest/
>>and the output is the same:
>>... Running VC test: semaphore1.exe
>>thread: sem_trywait 1: No error
>>Assertion failed: (errno == EAGAIN), file semaphore1.c, line 91
>>NMAKE : fatal error U1077: '.\semaphore1.exe' : return code '0x1'
>>Stop.
>>NMAKE : fatal error U1077: '"D:\Program Files\Microsoft Visual Studio .NET
>>2003\Vc7\bin\nmake.exe"' : return code '0x2'
>>Stop.
>>
>>
>>If this helps: I'm using VC7.1 beta on Win2k.
>>
>>Thanks a lot in advance,
>>Viv
>>
>>
>>----- Original Message -----
>>From: "Ross Johnson" <rpj@ise.canberra.edu.au>
>>To: "vc" <vcotirlea@hotmail.com>
>>Sent: Saturday, May 10, 2003 7:36 AM
>>Subject: Re: pthread Win32 - runtime lib VC++ setting
>>
>>
>>
>>>There's only one value possible for errno that sem_trywait should return
>>>at this point. That's EAGAIN, unless you somehow have defined NEED_SEM
>>>when you compile the test. Unless your target system doesn't have Win32
>>>semaphores (early WinCE etc), then NEED_SEM should not be defined.
>>>
>>>Is this a possibility?
>>>
>>>pthread.h includes config.h, which normally undefines NEED_SEM.
>>>
>>>Ross
>>>
>>>vc wrote:
>>>
>>>
>>>>Hi again,
>>>>
>>>>I've downloaded the pthread sources from the cvs, build them using the
>>
>>VC++
>>
>>>>IDE
>>>>and run the tests using "nmake clean VC".
>>>>
>>>>All the tests passed besides the semaphore1.exe.
>>>>The output is:
>>>>... Running VC test: semaphore1.exe
>>>>thread: sem_trywait 1: No error
>>>>Assertion failed: (errno == EAGAIN), file semaphore1.c, line 91
>>>>NMAKE : fatal error U1077: '.\semaphore1.exe' : return code '0x1'
>>>>Stop.
>>>>NMAKE : fatal error U1077: '"D:\Program Files\Microsoft Visual Studio
>>
>>.NET
>>
>>>>2003\Vc7\bin\nmake.exe"' : return code '0x2'
>>>>Stop.
>>>>
>>>>I couldn't find anything about the failure of this test in the docs, so
> 
> I
> 
>>>>assume that it should pass.
>>>>
>>>>As I'm not that used with the posix threads I don't really know what's
>>
>>the
>>
>>>>problem ...
>>>>Maybe somebody has an idea ?
>>>>
>>>>Thanks a lot,
>>>>Viv
>>>>
>>>>----- Original Message -----
>>>>From: "Ross Johnson" <rpj@ise.canberra.edu.au>
>>>>To: "vc" <vcotirlea@hotmail.com>
>>>>Cc: <pthreads-win32@sources.redhat.com>
>>>>Sent: Friday, May 09, 2003 2:52 AM
>>>>Subject: Re: pthread Win32 - runtime lib VC++ setting
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>vc wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi all,
>>>>>>
>>>>>>I'm working on Win2k with VC++ 7.1 (VS .NET beta).
>>>>>>I have to port a Unix app on Windows, so I'm using the pthread lib
> 
> for
> 
>>>>>>Win32 (http://sources.redhat.com/pthreads-win32/).
>>>>>>
>>>>>>I've downloaded the sources, as I want to build them myself, and
>>>>>>looking at the VC++ settings, I discovered that in Debug
>>>>>>configuration, the /MDd flag is used (which means: "multithread- and
>>>>>>DLL-specific versions of the run-time") and in Release configuration
>>>>>>the /MT flag is used (even if the release version of the /MDd flag is
>>>>>>/MD).
>>>>>>
>>>>>>Questions:
>>>>>>1) Why is not used in the project settings the same flag for both
>>>>>>configuration(i.e /MDd - debug; /MD - release or /MTd - debug; /MT -
>>>>>>release)? Is there a reason, or it was just by mistake?
>>>>>>Note: MS recommended for DLLs to use /MD (/MDd)
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>Re the /MT flag, I can't say now because I don't really know.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>2) If for this is actually no reason, is it ok if I build the sources
>>>>>>using the /MD flag for release?
>>>>>>
>>>>>>3) I donwloaded the sources from
>>>>>>ftp://sources.redhat.com/pub/pthreads-win32/sources/ and there is a
>>>>>>pthreads-snap-2002-11-04 directory. Is this a release version? Is it
>>>>>>ok if I'm using this version, or this is just a version between 2
>>>>>>releases?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>Since you wan't to build the library yourself, you should get the
> 
> source
> 
>>>>>via anonymous CVS (see the web page for details -
>>>>>http://sources.redhat.com/pthreads-win32/). It has the latest bug
> 
> fixes,
> 
>>>>>and currently bug fixes are the only changes from the latest versions
>>>>>available from ftp. I will update the ftp versions ASAP.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>4) When I downloaded just binaries some time ago, there were 3
>>>>>>versions of the binaries: VC, VSE, VCE. The sources that I downloaded
>>>>>>now seems to be for the VC version. Am I correct? (because this is
> 
> the
> 
>>>>>>version that interests me)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>See the FAQ file, answer to Q2. For VC you don't need to do anything
>>>>>because it is the default. The others can be used if you add the
>>>>>appropriate compile flags when you build your application code, and
> 
> when
> 
>>>>>you build the library if you don't use the prebuilt dlls.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Thanks a lot in advance,
>>>>>>Viv
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>Regards.
>>>>>Ross
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>
>>>

  reply	other threads:[~2003-05-14  3:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-13 16:14 vc
2003-05-14  3:32 ` Ross Johnson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-09  1:17 Simon Gerblich
2003-05-08 11:10 vc
2003-05-09  0:52 ` Ross Johnson
2003-05-09 12:43   ` vc
2003-05-09 16:20   ` vc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EC1B896.5060104@ise.canberra.edu.au \
    --to=rpj@ise.canberra.edu.au \
    --cc=pthreads-win32@sources.redhat.com \
    --cc=vcotirlea@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).