From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1167 invoked by alias); 19 Jan 2012 01:30:26 -0000 Received: (qmail 1154 invoked by uid 22791); 19 Jan 2012 01:30:24 -0000 X-SWARE-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,BAYES_99,TW_CV,TW_VC X-Spam-Check-By: sourceware.org Received: from bender.grapevine.net.au (HELO bender.grapevine.net.au) (203.129.32.139) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Jan 2012 01:30:08 +0000 Received: from localhost (localhost [127.0.0.1]) by bender.grapevine.net.au (Postfix) with ESMTP id 924C121007F; Thu, 19 Jan 2012 12:30:05 +1100 (EST) Received: from bender.grapevine.net.au ([127.0.0.1]) by localhost (bender.grapevine.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 439FUElbYUaT; Thu, 19 Jan 2012 12:30:05 +1100 (EST) Received: from [192.168.2.2] (ppp-124.44.129.203.grapevine.net.au [203.129.44.124]) (Authenticated sender: Ross.Johnson@homemail.com.au) by bender.grapevine.net.au (Postfix) with ESMTPA id 2BDFA2400F5; Thu, 19 Jan 2012 12:30:05 +1100 (EST) Message-ID: <4F1771DF.3060403@homemail.com.au> Date: Thu, 19 Jan 2012 01:30: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> 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/msg00006.txt.bz2 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