We don't really need it in class library build (if we have it in system32). We just need it in bin directory of hdk snapshots.
SY, Alexey 2006/12/25, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
On Dec 25, 2006, at 4:47 AM, Alexey Petrenko wrote: > OK, I'll remove msvcr71.dll dependency from class library. > Geir, could you add it to federated build? Yes, I suppose that's the right place to deal with the problem, although since people can simply get a HDK and drop a VM into it there for testing.... don't we need it in the classlib build as well? geir > > SY, Alexey > > 2006/12/25, Ivanov, Alexey A <[EMAIL PROTECTED]>: >> >-----Original Message----- >> >From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] >> >Sent: Saturday, December 23, 2006 3:25 PM >> >To: [email protected] >> >Subject: Re: [build] Downloading dependencies >> > >> > >> >On Dec 21, 2006, at 4:24 AM, Alexey Petrenko wrote: >> > >> >> Yes, we do not really need it while Harmony development. I've said >> >> this few times. >> >> But we definitely need this dll while building distribution >> package. >> >> >> >> So copying it while build will not break anything in >> development but >> >> will make life easier for distribution build. >> > >> >So to keep things clean... why not change things so that the build >> >brings in the dll that is being used by the build? IOW, completely >> >remove it as an external dependency, and simply copy it when making >> >the build. That way we are sure that the dll that is included is >> the >> >right one. >> >> This will be the best solution. >> >> Regards, >> Alexey. >> >> > >> >geir >> > >> >> >> >> SY, Alexey >> >> >> >> 2006/12/21, Ivanov, Alexey A <[EMAIL PROTECTED]>: >> >>> >-----Original Message----- >> >>> >From: Alexey Petrenko [mailto:[EMAIL PROTECTED] >> >>> >Sent: Wednesday, December 20, 2006 8:49 PM >> >>> >To: [email protected] >> >>> >Subject: Re: [build] Downloading dependencies >> >>> > >> >>> >2006/12/20, Stefano Mazzocchi <[EMAIL PROTECTED]>: >> >>> >> 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:[EMAIL PROTECTED] >> >>> >> >>> Sent: Wednesday, December 20, 2006 8:49 AM >> >>> >> >>> To: [email protected] >> >>> >> >>> 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 <[EMAIL PROTECTED]>: >> >>> >> >>>> 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. <[EMAIL PROTECTED]> 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 >> >>> >> >> -- >> Alexey A. Ivanov >> Intel Enterprise Solutions Software Division >>
