Re: compiler error with vs 2008

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

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