From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31570 invoked by alias); 20 Jan 2012 02:18:49 -0000 Received: (qmail 31048 invoked by uid 22791); 20 Jan 2012 02:18:46 -0000 X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_99,TW_CV,TW_VC X-Spam-Check-By: sourceware.org Received: from flexo.grapevine.net.au (HELO flexo.grapevine.net.au) (203.129.32.140) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Jan 2012 02:18:30 +0000 Received: from localhost (localhost [127.0.0.1]) by flexo.grapevine.net.au (Postfix) with ESMTP id EA5485E802D; Fri, 20 Jan 2012 13:18:27 +1100 (EST) Received: from flexo.grapevine.net.au ([127.0.0.1]) by localhost (flexo.grapevine.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAGFTUYJREUE; Fri, 20 Jan 2012 13:18:27 +1100 (EST) Received: from [192.168.2.2] (ppp-44-124.grapevine.net.au [203.129.44.124]) (Authenticated sender: Ross.Johnson@homemail.com.au) by flexo.grapevine.net.au (Postfix) with ESMTPA id 7A2245E80B3; Fri, 20 Jan 2012 13:18:27 +1100 (EST) Message-ID: <4F18CEE6.9080709@homemail.com.au> Date: Fri, 20 Jan 2012 02:18:00 -0000 From: Ross Johnson User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Immanuel Dold CC: pthreads-win32@sourceware.org Subject: Re: compiler error with vs 2008 References: <4ED584BF.70500@homemail.com.au> <4ED6DA44.3000604@homemail.com.au> <4EDB6750.5060900@homemail.com.au> <4F1771DF.3060403@homemail.com.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2012/txt/msg00008.txt.bz2 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 >>>> >>>> . >>>> >>>> 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 >> >>