Re: compiler error with vs 2008

[Immanuel Dold <ihd2008@live.de>]

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