public inbox for
 help / color / mirror / Atom feed
From: Ross Johnson <>
To: Immanuel Dold <>
Subject: Re: compiler error with vs 2008
Date: Fri, 20 Jan 2012 02:18:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <BLU0-SMTP4367F43D5B4295DA76006BCAC860@phx.gbl>

Hi Immanuel,

The only runtime requirement of pthreadsvc2.dll is the /MD compiler flag 
that is set in the Makefile. You can see all the compiler flags output 
as nmake builds the dll. This doesn't force a choice between 32/64 bits 
though. Pthreads doesn't specify any particular runtime path.

Can an application/process load more than one runtime? If not, why is 
pthreadvc2.dll determining which one? Are you sure you're not picking up 
a 32 bit version of pthreadvc2.dll from a previous build or download? 
Are you sure you're running the application from within the same 64 bit 
build environment?

In Linux I would run ldd to check the full paths of all dynamic libs as 
determined by the runtime link loader in the current environment. Does 
Dependency Walker do a similar job, i.e. show the full path to the DLL 
that the system will try to load?


On 20/01/2012 4:57 AM, Immanuel Dold wrote:
> Hi Ross.
> First of all to your question: I have got seven copies of the
> MSVCR90.dll. Some of them come with two programs I have installed on my
> machine. Two come with VS 2008 and two of a previous installation of VS
> 2010. I checked and there are at least two copies which are x64 versions
> of the library. The problem is not, that pthread does not find the
> correct version of the library. The problem is, that pthread tries to
> load the false version. It is linked to the 32-bit version of the
> MSVCR90.dll although it is itself a 64-bit library. I think nmake links
> it wrong when it compiles pthread. It is a little bit strange because
> apart from the MSVCR90.dll nmake links all other libraries in their
> x64-bit version to pthread.
> I am sorry but to be honest I only did a little google search but it did
> not come up with a result. My first guess was that there has to be a way
> to tell nmake to link pthread against the x64-bit version of
> MSVCR90.dll. I thought this option has to be put in one of the files
> coming with the pthread source code. Thats why I asked you (guys). Maybe
> I am wrong and I have to use another compiler or linker flag on the
> command prompt. But still, I do not know which.
> Well, at least my program runs. But it would be great if I were able to
> build my own pthread dll as a x64 library.
> Thank you again for your quick answer.
> Have a nice day
> Immanuel
> Am 19.01.2012 02:29, schrieb Ross Johnson:
>> Hi Immanuel,
>> Good to hear you've got it going.
>> Re the MSVCR90.DLL issue I can only guess and I'm sure you've googled
>> it already but since it is a dll, I would assume the usual search
>> rules apply, i.e. in order:
>> current location
>> same folder as exe
>> known system areas (?)
>> environment PATH
>> etc.
>> Please excuse me asking the obvious question: how many copies of
>> MSVCR90.DLL do you have and what are their locations?
>> Hopefully someone can provide the real answer.
>> Cheers.
>> Ross
>> On 18/01/2012 11:56 PM, Immanuel Dold wrote:
>>> Hi Ross.
>>> I do not know if anybody cares but I have made some progress. I got my
>>> whole project running. As you suggested in one of your ealier e-mails I
>>> compiled the main project as a x64-program and therefore compiled every
>>> linked library as a x64-lib, too. Well, long story short the programm
>>> runs fine. While cracking as a release version on my 32-bit pc it even
>>> runs as a release version on my x64-bit notebook.
>>> I just have one thing left: I had to use a x64-build of pthreadVC.dll
>>> and had already found one on the net some time ago, so I used this one.
>>> Today I tried to compile my own one from the source code, I had checked
>>> out with cvs. I used the x64-command-prompt from VS 2008 and it compiled
>>> fine. I checked pthreads dependencies with a program called "Dependency
>>> Walker" and there I got an error. Even compiled with the x64-compiler
>>> the dll was linked to the x86 version of the MSVCR90.DLL. I linked my
>>> own build to my main project and it did not work (probably because of
>>> the false linked dll). What do I have to change in what file so nmakes
>>> links pthread to the correct x64 version of the MSVCR90 library?
>>> Thanks again for all the help I got.
>>> Best regards
>>> Immanuel
>>> P.S.: A little bit late: Happy new year to everybody!
>>> Hi Ross,
>>> yes I do know the links you sent me. When I first read them I thought
>>> "oh no, thats to big for me" so I stopped thinking about it. Reading it
>>> again I got one problem left: If I understand the text correct the whole
>>> solution will only work if you are using the command line to build your
>>> project. Thats the only way to get the corrected manifest into your
>>> program. Well, until now I used the GUI and since VS2005 there is no way
>>> to export your project to a nmake makefile. You can still build on the
>>> command prompt but  you have to use msdev or vcbuild and they use the
>>> old .dsw or .dsp project files. As I already sad I am using VS 2008 and
>>> therefor do not have any of these files. I only got a .sln solution file
>>> which does not help in any way. The only way to get the proper makefile
>>> would be to write one by hand. And there we are again: I never wrote a
>>> makefile. The whole project is a little mess with at least six different
>>> dependencies, include files all over the partition as well as libraries.
>>> I am so thankful that I got the project running/building with the GUI by
>>> telling VS where to find all the files but I just had to set one single
>>> compiler flag myself. The one you told me. So to make a long story
>>> short: I do not see me getting my problem solved and therefor I will
>>> probably do not get you your Sorry for that.
>>> I am going to discuss the problem again with my tutor and if we find a
>>> solution I will let you know.
>>> One thing left: Just for fun I compiled a minimal test program for
>>> pthread found on the English Wikipedia
>>> ( I linked it to the
>>> pre-build version 2.8.0 of pthread to see if it works and yes it does.
>>> How come it works on my x64 Windows 7? Are there more sophisticated
>>> functions which conflict with my OS?
>>> Thanks again.
>>> Immanuel
>>> Am 04.12.2011 13:28, schrieb Ross Johnson:
>>>> Hi Immanuel,
>>>> Googling the runtime error R6034 I see lots of Windows 7 related pages.
>>>> One of those was:
>>>> You may have seen it already. On that page is says:
>>>>         To correct this error
>>>>     *
>>>>       Rebuild your application with a manifest. Building an application
>>>>       with Visual Studio automatically puts the manifest into the
>>>>       resulting EXE or DLL file. If you are building at the command
>>>> line,
>>>>       use the mt.exe tool to add the manifest as a resource. Use
>>>> resource
>>>>       ID 1 if building an EXE, 2 if building a DLL. For more
>>>> information,
>>>>       see How to: Embed a Manifest Inside a C/C++ Application
>>>> <>.
>>>> Note the part about "building at the command line".
>>>> I don't know if this will help but if you find that it solves the
>>>> problem could you please send me the details so that I can perhaps put
>>>> the additional build steps in the makefiles. That link "How to: Embed
>>>> ..." describes mods to the makefile but I don't have the ""
>>>> as part of VC++ 2010 Express, however if it's part of the Windows SDK
>>>> then I'll be grabbing that soon for another purpose.
>>>> Thanks.
>>>> On 3/12/2011 10:42 PM, Immanuel Dold wrote:
>>>>> Hello Ross,
>>>>> thanks allot for your help. After Reading the README on the topic of
>>>>> "/D__CLEANUP_C" I am giving up compiling the VCE Versions because
>>>>> it is
>>>>> mentioned to be broken. So I tried both of your suggestions. First I
>>>>> compiled my libcvd using the newest pthread VC version and using the
>>>>> flag /D "__CLEANUP_C" (I think this is the correct way to type the
>>>>> flag
>>>>> into the GUI of MSVC - every other flag looks the same). Second I
>>>>> compiled my main project PTAM (as a library instead of a standalone
>>>>> executable) linking it to the new libcvd and again setting the
>>>>> compiler
>>>>> flag to /D "__CLEANUP_C". Well sadly it turned out that I get the same
>>>>> error message as before. I am aware that you probably do not even know
>>>>> libcvd or PTAM but since it looks like the libraries used for my
>>>>> project
>>>>> use different runtime libraries could it be that libcvd and pthread
>>>>> are
>>>>> cleaned up well but the other libraries like "gvars3", "glew32" and
>>>>> "lapack" conflict know? Is there a way to find out which library
>>>>> causes
>>>>> the error?
>>>>> The next step was to compile everything as a x64 application. As I
>>>>> already was afraid of it did not work out. Compiling pthread and
>>>>> libcvd
>>>>> using nmake x64, the MSVC GUI and the above mentioned compiler flag
>>>>> worked out fine. When I then tried to build PTAM linking to the x64
>>>>> libraries and setting the flag I got a linker error that a external
>>>>> defined symbol in some header files of "TooN" can not be found. So it
>>>>> seems it has nothing to do with pthread but with "TooN". It
>>>>> troubles me
>>>>> because I do not know why "TooN" works fine under x86-32 but seems
>>>>> buggy
>>>>> when compiled for a Windows 7 x64 system.
>>>>>> Google suggests that it can be problematic with Windows 7 but some
>>>>>> sources suggest that there is a way to get a Windows XP compatible
>>>>>> environment for 32 bit apps. Ultimately (2) is going to be much more
>>>>>> convenient for all, obviously.
>>>>> I think you mean the XP-Mode for Windows 7 Pro and above. It was my
>>>>> first idea when I recognized x64 will make problems.
>>>>> If you have any suggestions left, let me know. I am glad for all the
>>>>> help I can get.
>>>>> Have a nice weekend and best regards,
>>>>> Immanuel
>>>>> Am 01.12.2011 02:37, schrieb Ross Johnson:
>>>>>> Hi Immanuel,
>>>>>> On 30/11/2011 11:28 PM, Immanuel Dold wrote:
>>>>>>> Hi Ross.
>>>>>>> Thanks for the help. As I already told you I am not familiar with
>>>>>>> setting up compiler flags. I tried setting /DNO_STRICT into the
>>>>>>> right
>>>>>>> line. I copied it behind line 28 in the makefile so it now looks
>>>>>>> like
>>>>>>> this: "CPPFLAGS = /I. /DHAVE_PTW32_CONFIG_H /DNO_STRICT" In the
>>>>>>> event
>>>>>>> that this is indeed the correct line, the result is poor because
>>>>>>> I still
>>>>>>> get the same errors as described below. Did I choose the wrong line?
>>>>>>> Since the errors occur in "ptw32_MCS_lock.c" does my problem have
>>>>>>> to do
>>>>>>> something with the "/DHAVE_PTW32_CONFIG_H" flag?
>>>>>> You got the correct line but I wasn't sure if /DNO_STRICT would help
>>>>>> or not. It was worth trying.
>>>>>> The problem is not due to "/DHAVE_PTW32_CONFIG_H", which just tells
>>>>>> the build to include config.h.
>>>>>>> You already sad that the VCE version is not recommended so I
>>>>>>> tried using
>>>>>>> VC for my project(s). Both of them build but the last one crashed
>>>>>>> with
>>>>>>> an exception R6034. It seems some of the libraries static or dynamic
>>>>>>> linked to my project use different versions of the C runtime
>>>>>>> library.
>>>>>>> Because this problem is way out of my league I would prefer to
>>>>>>> stay with
>>>>>>> VCE.
>>>>>> If the exception is due to inconsistent runtimes then I believe it
>>>>>> will be a problem with both VC and VCE, but the reason/solution for
>>>>>> this may be simpler, hopefully.
>>>>>> You need another compiler flag when building your app, which is
>>>>>> "/D__CLEANUP_C". The reason for this is that pthread.h is used during
>>>>>> both the DLL build and your application build, and so "/D__CLEANUP_C"
>>>>>> ensures that the same definitions are used for both. There is some
>>>>>> discussion of this in the README IIRC, search for "__CLEANUP_".
>>>>>> As examples, there are nmake targets in the tests\Makefile to do
>>>>>> basic
>>>>>> testing of the case where the C dll is used with a C++ app build,
>>>>>> e.g.
>>>>>> cd tests
>>>>>> nmake clean VCX
>>>>>> nmake clean VCX-bench
>>>>>> nmake clean VCX-stress
>>>>>> All these do differently is set that compiler flag.
>>>>>>> I still have one question left. There are two options.
>>>>>>> 1. Build pthread with a x86 compiler and link it to a x86 program
>>>>>>> to run
>>>>>>> it on a x64 windows.
>>>>>>> 2. Build pthread with a x64 compiler and link it to a (probably) x64
>>>>>>> program to run it on a x64 windows.
>>>>>>> Which of these two options is the right one? I am asking because
>>>>>>> I used
>>>>>>> option one till now. Probably I wont be able to build my x86
>>>>>>> programs as
>>>>>>> 64-Bit programs so if I have to use option two my whole project will
>>>>>>> most likely fail.
>>>>>> If your application runs on 32 bit Windows systems then (1) should be
>>>>>> viable. Google suggests that it can be problematic with Windows 7 but
>>>>>> some sources suggest that there is a way to get a Windows XP
>>>>>> compatible environment for 32 bit apps. Ultimately (2) is going to be
>>>>>> much more convenient for all, obviously.
>>>>>> I would persist with option (2) by building your app with the
>>>>>> pthreadsVC2 (i.e. C) version of the dll as above and resolve the
>>>>>> runtime problem if it's still there after that.
>>>>>>> Thank you again for the help. Best regards
>>>>>>> Immanuel
>>>>>>> Am 30.11.2011 02:19, schrieb Ross Johnson:
>>>>>>>> On 30/11/2011 7:53 AM, Immanuel Dold wrote:
>>>>>>>>> Hello everybody.
>>>>>>>>> I am new to this project but I need help. I am a German student
>>>>>>>>> and
>>>>>>>>> I am
>>>>>>>>> currently working with PTAM and libcvd. The program I am building
>>>>>>>>> works
>>>>>>>>> fine under windows 7 32-bit. The problem is that my tutor for my
>>>>>>>>> thesis
>>>>>>>>> works with windows 7 64-bit. You are probably guessing right
>>>>>>>>> that on
>>>>>>>>> that machine the program only hangs. I get a 100% processor load
>>>>>>>>> but the
>>>>>>>>> program not even gets to the main() function. Until now I used
>>>>>>>>> pthread
>>>>>>>>> 2.8.0 and after some research on the net I found out that I
>>>>>>>>> have to
>>>>>>>>> use
>>>>>>>>> more recent code. Since there is no release I tried to build my
>>>>>>>>> own
>>>>>>>>> libraries.
>>>>>>>> You do need to use the latest cvs version for 64 bit builds.
>>>>>>>>> This is why I looked up for wincvs and checked out the newest code
>>>>>>>>> from
>>>>>>>>> the server. I looked into the README file for instructions on
>>>>>>>>> how to
>>>>>>>>> build all the .lib and .dll files. Now there is my problem. Using
>>>>>>>>> nmake
>>>>>>>>> from Visual Studio 2008 Pro with the parameters "clean VC" and
>>>>>>>>> "clean
>>>>>>>>> VSE" works just fine. But libcvd and PTAM rely both on the VCE
>>>>>>>>> version
>>>>>>>>> and so I tried "nmake clean VCE" and there I got stuck. The
>>>>>>>>> compiler
>>>>>>>>> throws errors (C2264) in "ptw32-MCS_lock.c" in lines 108, 127,
>>>>>>>>> 136,
>>>>>>>>> 197
>>>>>>>>> and 215 saying that the it can not cast "volatile size_t *" into
>>>>>>>>> "volatile LONG *".
>>>>>>>> You may find that using the VC build works with your
>>>>>>>> application. The
>>>>>>>> VCE version has problems anyway and is not really recommended.
>>>>>>>> This problem has been reported to me by Daniel Richard G. who
>>>>>>>> has also
>>>>>>>> provided a substantial patch that also includes a large number of
>>>>>>>> other changes not necessarily related to this issue.
>>>>>>>> Unfortunately I
>>>>>>>> just don't have the time now or the [64 bit MSVS] tools to properly
>>>>>>>> incorporate and test complex patch sets or coordinate those who do,
>>>>>>>> considering that this project aims to work with several compilers
>>>>>>>> (e.g. MS and GNU) and their various versions and supported
>>>>>>>> architectures.
>>>>>>>> But I do want to note here that the current code in cvs has been
>>>>>>>> built
>>>>>>>> and well tested on several 64 bit systems and compilers, but
>>>>>>>> presumably not using this specific MSVC++ compiler version.
>>>>>>>> I don't know if this link helps at all with the cast error, i.e.
>>>>>>>> adding the /DNO_STRICT compiler option to the compiler flags in the
>>>>>>>> nmake Makefile:
>>>>>>>> Regards.
>>>>>>>> Ross

      reply	other threads:[~2012-01-20  2:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29 20:52 Immanuel Dold
2011-11-30  1:21 ` Ross Johnson
2011-11-30 12:28   ` Immanuel Dold
2011-12-01  1:38     ` Ross Johnson
2011-12-03 11:42       ` Immanuel Dold
     [not found]         ` <>
2011-12-04 17:10           ` Immanuel Dold
2012-01-18 12:56           ` Immanuel Dold
2012-01-19  1:30             ` Ross Johnson
2012-01-19 17:58               ` Immanuel Dold
2012-01-20  2:18                 ` Ross Johnson [this message]

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:

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

  git send-email \ \ \ \ \

* 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).