Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 89955 invoked from network); 21 Dec 2006 08:12:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Dec 2006 08:12:35 -0000 Received: (qmail 69969 invoked by uid 500); 21 Dec 2006 08:12:39 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 69880 invoked by uid 500); 21 Dec 2006 08:12:39 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 69871 invoked by uid 99); 21 Dec 2006 08:12:39 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Dec 2006 00:12:39 -0800 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=MAILTO_TO_SPAM_ADDR X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [143.182.124.21] (HELO mga03.intel.com) (143.182.124.21) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Dec 2006 00:12:28 -0800 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 21 Dec 2006 00:12:03 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by azsmga001.ch.intel.com with ESMTP; 21 Dec 2006 00:12:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,197,1165219200"; d="scan'208"; a="160950408:sNHT24275958" Received: from mssmsx411.ccr.corp.intel.com ([10.125.2.10]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 00:11:32 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [build] Downloading dependencies Date: Thu, 21 Dec 2006 11:11:28 +0300 Message-ID: <8E389A5F2FEABA4CB1DEC35A25CB39CE88DC21@mssmsx411> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [build] Downloading dependencies Thread-Index: AcckX0RC3JJUFOeSQVu63eQ//84MRAAdkBXQ From: "Ivanov, Alexey A" To: X-OriginalArrivalTime: 21 Dec 2006 08:11:32.0192 (UTC) FILETIME=[9FDC1E00:01C724D7] X-Virus-Checked: Checked by ClamAV on apache.org >-----Original Message----- >From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com] >Sent: Wednesday, December 20, 2006 8:49 PM >To: dev@harmony.apache.org >Subject: Re: [build] Downloading dependencies > >2006/12/20, Stefano Mazzocchi : >> Gregory Shimansky wrote: >> > Ivanov, Alexey A wrote: >> >> In default installation WinXP does not have this library in system32. >> >> This library is installed by Visual Studio 2003 and may be installed >by >> >> other software which was compiled with Visual Studio 2003 (which is >> >> v7.1). Visual Studio 2002 (v7.0) has msvc70.dll, if I remember >> >> correctly. >> > >> > Also if the person has VS.NET 2005 installed, the DLL name is >msvcr80.dll. >> ah, that might be why! I had 2005 installed >:) I believe this DLL is not needed during build, no matter what compiler do you use. The compiler itself will find the correct DLL (it should install it into system32). We will need the correct DLL to be able to run natives. I mean we should have the DLL in snapshots which are targeted at end-users who may not have any version of Visual Studio or Compiler installed. And we should provide the correct version of the DLL which corresponds to the version of the compiler that was used to build the snapshots. I even think that this DLL is not needed in deploy directory either: when we start VM, the system will link with the DLL from system32 which is there if one compiled the natives oneself. Am I wrong? Alexey, why do we need the DLL while building? Regards, Alexey. > >SY, Alexey > >> >> That is it may happen system lacks for this DLL. And Microsoft >> >> recommends avoiding copying DLLs to system32 when installing an >> >> application. Thus we better distribute this DLL in snapshots and >further >> >> releases because users may not have it. >> >> >> >> On the other hand, if a person has Microsoft compiler installed, the >DLL >> >> will most likely be in system32. >> >> >> >> That's it. >> >> -- >> >> Alexey A. Ivanov >> >> Intel Enterprise Solutions Software Division >> >> >> >> >> >>> -----Original Message----- >> >>> From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com] >> >>> Sent: Wednesday, December 20, 2006 8:49 AM >> >>> To: dev@harmony.apache.org >> >>> Subject: Re: [build] Downloading dependencies >> >>> >> >>> If this library exists in system32 then we do not need to download it >> >>> or do any additional search. Linker will do it for us. >> >>> So we can simple remove all mentions of this library from >dependencies. >> >>> >> >>> But when I suggested this last time someone reported that he has MSVC >> >>> but does not have this library... This looks really strange. >> >>> >> >>> We can remove this dependency and look... :) >> >>> >> >>> SY, Alexey >> >>> >> >>> 2006/12/20, Leo Li : >> >>>> Yes, actually we can just get MSVC71.dll from the system32 >directory >> >> at >> >>>> least from XP, but as for other windows versions I am not sure the >> >> exact >> >>>> version of MSVC DLL. So is it ok if we do not explicitly get it but >> >> use >> >>> it >> >>>> while linking by the search path of the os system just like other >> >>>> kernel32.dll? >> >>>> >> >>>> On 12/20/06, Geir Magnusson Jr. wrote: >> >>>>> >> >>>>> >> >>>>> Stefano Mazzocchi wrote: >> >>>>>> Geir Magnusson Jr. wrote: >> >>>>>>> Do we really need to download this dll? Everyone who has the >> >> MSVC >> >>>>>>> installed should have it, right? >> >>>>>> I don't care if it's downloaded, linked or magically generated >> >> out of >> >>>>>> looking into tea leaves, the problem is that the build needs >> >> manual >> >>>>>> intervention and this is not documented anywhere. >> >>>>>> >> >>>>>> We need to make sure that what we say you need to do is *only* >> >> what >> >>> you >> >>>>>> need to do. Every other (undocumented step) is annoying and slows >> >> our >> >>>>>> community development down. >> >>>>> Yeah, I get it. My point is that I'm still not convinced we need >> >> this >> >>>>> to be downloaded... >> >>>>> >> >>>>> So do we? >> >>>>> >> >>>>> geir >> >>>>> >> >>>>>>> geir >> >>>>>>> >> >>>>>>> >> >>>>>>> Stefano Mazzocchi wrote: >> >>>>>>>> Tim Ellison wrote: >> >>>>>>>>> Stefano Mazzocchi wrote: >> >>>>>>>>>> Mark Hindess wrote: >> >>>>>>>>>>> I tried doing fetch-depends before rebuild but it would fail >> >> or >> >>>>>>>>>>> corrupt >> >>>>>>>>>>> dependencies often enough that it caused more trouble than >> >> it >> >>>>> solved. >> >>>>>>>>>>> I can try it again I suppose - IIRC it was ibiblio that was >> >> the >> >>>>> main >> >>>>>>>>>>> problem and that might have been a temporary issue. >> >>>>>>>>>> People, you do realize that if fetch-depends breaks that >> >> often we >> >>>>>>>>>> have a >> >>>>>>>>>> bigger problem than just dealing with faulty updates? >> >>>>>>>>>> >> >>>>>>>>>> Imagine that every time fetch-depends doesn't work we lose >> >> the >> >>>>> ability >> >>>>>>>>>> for some guy out there to contribute something to us. >> >>>>>>>>>> >> >>>>>>>>>> This is, from a community building perspective, a *way* >> >> bigger >> >>>>> problem >> >>>>>>>>>> than if the JVM ran at all after it compiled!! >> >>>>>>>>> I remember the discussion over the msvcr71.dll download. Have >> >>> there >> >>>>> been >> >>>>>>>>> other problems? >> >>>>>>>> it's still not fixed! >> > >> > >> >> >> -- >> Stefano. >> >> -- Alexey A. Ivanov Intel Enterprise Solutions Software Division