On Dec 21, 2006, at 3:11 AM, Ivanov, Alexey A wrote:
-----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.
That's probably only about 99.2% of the user population. Good idea ;)
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.
Yes
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?
We can never assume that anything we need is installed. So I think
that if we don't need this to build, then lets get it out of the
fetch list, and reconfigure so that the builds put the dll in the
right place (/jre/bin or jre/bin/default?)
geir
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
