Re: compiler error with vs 2008

[Ross Johnson <Ross.Johnson@homemail.com.au>]

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?

Regards.
Ross

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 makefile.inc. 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
>>> (http://en.wikipedia.org/wiki/POSIX_Threads). 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:
>>>>
>>>> http://msdn.microsoft.com/en-us/library/ms235560%28v=VS.90%29.aspx
>>>>
>>>> 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
>>>>
>>>> <http://msdn.microsoft.com/en-us/library/ms235591%28v=vs.80%29.aspx>.
>>>>
>>>> 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 "makefile.inc"
>>>> 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:
>>>>>>>>
>>>>>>>> http://msdn.microsoft.com/en-us/library/aa383679%28v=vs.85%29.aspx
>>>>>>>>
>>>>>>>> Regards.
>>>>>>>> Ross
>>
>>