public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* compiler error with vs 2008
@ 2011-11-29 20:52 Immanuel Dold
  2011-11-30  1:21 ` Ross Johnson
  0 siblings, 1 reply; 10+ messages in thread
From: Immanuel Dold @ 2011-11-29 20:52 UTC (permalink / raw)
  To: pthreads-win32

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.

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

I do not even know if the current code resolves my problem and my
programs will run on a x64 machine. So if you think pthread 2.8.0 should
run in a win32 (not x64) application on a x64 machine it does not bother
me not being able to compile the proper *VCE.dll. But if you could (or
is it "can"?) help me building the libraries, I would be very happy.

One thing left: My knowledge about compilers especially nmake is very
limited but since I am using VS I would prefer to stay with nmake.

Thanks to everybody taking the time to help me.
Sincerely yours,
Immanuel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: compiler error with vs 2008
  2011-11-29 20:52 compiler error with vs 2008 Immanuel Dold
@ 2011-11-30  1:21 ` Ross Johnson
  2011-11-30 12:28   ` Immanuel Dold
  0 siblings, 1 reply; 10+ messages in thread
From: Ross Johnson @ 2011-11-30  1:21 UTC (permalink / raw)
  To: Immanuel Dold; +Cc: pthreads-win32

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: compiler error with vs 2008
  2011-11-30  1:21 ` Ross Johnson
@ 2011-11-30 12:28   ` Immanuel Dold
  2011-12-01  1:38     ` Ross Johnson
  0 siblings, 1 reply; 10+ messages in thread
From: Immanuel Dold @ 2011-11-30 12:28 UTC (permalink / raw)
  To: pthreads-win32; +Cc: Ross Johnson

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

Given that I can not resolve my problem but have already got two of my
needed dlls, is there anybody who might give me the last .lib and .dll
files (VCE) working for windows?

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.

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: compiler error with vs 2008
  2011-11-30 12:28   ` Immanuel Dold
@ 2011-12-01  1:38     ` Ross Johnson
  2011-12-03 11:42       ` Immanuel Dold
  0 siblings, 1 reply; 10+ messages in thread
From: Ross Johnson @ 2011-12-01  1:38 UTC (permalink / raw)
  To: Immanuel Dold, pthreads-win32

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: compiler error with vs 2008
  2011-12-01  1:38     ` Ross Johnson
@ 2011-12-03 11:42       ` Immanuel Dold
       [not found]         ` <4EDB6750.5060900@homemail.com.au>
  0 siblings, 1 reply; 10+ messages in thread
From: Immanuel Dold @ 2011-12-03 11:42 UTC (permalink / raw)
  To: pthreads-win32; +Cc: Ross Johnson

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: compiler error with vs 2008
       [not found]         ` <4EDB6750.5060900@homemail.com.au>
@ 2011-12-04 17:10           ` Immanuel Dold
  2012-01-18 12:56           ` Immanuel Dold
  1 sibling, 0 replies; 10+ messages in thread
From: Immanuel Dold @ 2011-12-04 17:10 UTC (permalink / raw)
  To: pthreads-win32

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
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: compiler error with vs 2008
       [not found]         ` <4EDB6750.5060900@homemail.com.au>
  2011-12-04 17:10           ` Immanuel Dold
@ 2012-01-18 12:56           ` Immanuel Dold
  2012-01-19  1:30             ` Ross Johnson
  1 sibling, 1 reply; 10+ messages in thread
From: Immanuel Dold @ 2012-01-18 12:56 UTC (permalink / raw)
  To: Ross Johnson; +Cc: pthreads-win32

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
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: compiler error with vs 2008
  2012-01-18 12:56           ` Immanuel Dold
@ 2012-01-19  1:30             ` Ross Johnson
  2012-01-19 17:58               ` Immanuel Dold
  0 siblings, 1 reply; 10+ messages in thread
From: Ross Johnson @ 2012-01-19  1:30 UTC (permalink / raw)
  To: Immanuel Dold; +Cc: pthreads-win32

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: compiler error with vs 2008
  2012-01-19  1:30             ` Ross Johnson
@ 2012-01-19 17:58               ` Immanuel Dold
  2012-01-20  2:18                 ` Ross Johnson
  0 siblings, 1 reply; 10+ messages in thread
From: Immanuel Dold @ 2012-01-19 17:58 UTC (permalink / raw)
  To: Ross Johnson; +Cc: pthreads-win32

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
>
>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: compiler error with vs 2008
  2012-01-19 17:58               ` Immanuel Dold
@ 2012-01-20  2:18                 ` Ross Johnson
  0 siblings, 0 replies; 10+ messages in thread
From: Ross Johnson @ 2012-01-20  2:18 UTC (permalink / raw)
  To: Immanuel Dold; +Cc: pthreads-win32

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
>>
>>

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2012-01-20  2:18 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-29 20:52 compiler error with vs 2008 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]         ` <4EDB6750.5060900@homemail.com.au>
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 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).