Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of vasily.v.levchenko@gmail.com
 designates 209.85.198.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=W4SYochWc/TRvkiuemznIyDjP/XPjAKFkXpBM4YueJFPqyhaYSC/LNjXBxYpZOWdOCmSVAVrvvhil5YwYg9VoGczH5eYWVOKFD7INkD6yOsAFI+AUrYKOm5XIcyoOT0tnBS3bueDZ0DUw2KnxNBgJi6ZsbyxrRquFxOdQo7RdbM=
Message-ID: <14ecfd680801161904w36acd0b8l87ff35f8fd138500@mail.gmail.com>
Date: Thu, 17 Jan 2008 06:04:23 +0300
From: "Vasily Levchenko" <vasily.v.levchenko@gmail.com>
To: dev@harmony.apache.org
Subject: Re: latest stable packages JRE packages - jre-r603534 (M4)
In-Reply-To: <a52d53dd0801160625n4634415eqc99ca721eec417c4@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_6988_24747725.1200539063881"
References: <a52d53dd0801150930s2ec1ecc9t2a1f59c03117b332@mail.gmail.com>
	 <c3755b3a0801152224w50cd8270j579265ab53be81cb@mail.gmail.com>
	 <200801160825.m0G8Pj0T027632@d12av01.megacenter.de.ibm.com>
	 <a52d53dd0801160625n4634415eqc99ca721eec417c4@mail.gmail.com>

------=_Part_6988_24747725.1200539063881
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello Konstantin, folks,

On Jan 16, 2008 5:25 PM, Konstantin Lupach <konstantin.lupach@gmail.com>
wrote:

> Mark, can you please comment what are the licensing issues preventing us
> from libstdc++ redistribution you are talking about?


There shouldn't any legal issues as soon as libstdc++ is LGPL'ed, but you
could/should be ready to met some technical problems and unpredictable
behavior ;). One of the Linux problem that almost all Linux distribution has
it's own changes in the stack libc/libstdc++ and other system libraries
including changes in the kernel, so it's better to use libstdc++ that
installed in Linux distribution. External versioning  we've talked above for
the most UNIX distribution (external/internal versioning comes from SUN
Solaris/SunOS)  resolved with requirement  to  install  compat-package (from
vendor of Linux distribution)  that just place in library pathes
(/lib;/usr/lib and so on) libraries of the required versions. Automatically
it could be solved with distribution in packages (rpm, pkg and so on).


>
> I do know it is allowed to redistribute this library even with commercial
> products.
> E.g. this is what Intel(R) VTune(TM) Performance Analyzer for Linux does.
>
> I also know that there are some technical issues/tricks with this
> dependency. Let discuss them in a separate thread.
>
> Kind regards,
> Konstantin Lupach
> Intel Corporation
> Nizhny Novgorod, Russia
>
>
> On 1/16/08, Mark Hindess <mark.hindess@googlemail.com> wrote:
> >
> >
> > On 16 January 2008 at 9:24, "Alexey Petrenko" <
> alexey.a.petrenko@gmail.com
> > >
> > wrote:
> > > 2008/1/15, Konstantin Lupach <konstantin.lupach@gmail.com>:
> > > > Hi All,
> > > >
> > > > I gave a try these packages on Linux IA32 host
> > > > with RHEL3 update 6 and noticed that both
> > > > apache-harmony-jre-r603534-linux-x86-32-libstdc++v6- snapshot.tar.gz
> > > > and apache-harmony-jre-r603534-linux-x86-32-snapshot.tar.gzrequire
> > > > libstdc++.so.6. Was the 2-nd package built in a wrong compiler
> > > > environment?
> > > >
> > > > The 2-nd question is about libstdc++ dependency. Why not to
> > > > incapsulate this VM libraries dependecy? It can be either linked
> > > > statically or if you want to reduce libraries size it is possible
> > > > to put it to the build directory and provide a single IA32 package
> > > > instead of 2 stdc++ dependent as it is done now.
> > > Yes, we have this, I would say, ugly dependency. Which comes from ICU
> > > as far as I remember.
> >
> > Not really.  The dependency on libstdc++ comes from any library that
> > includes C++ code so most of the awt and imageio libraries, and a number
> > of libraries in the VM.  The libstdc++5 specific dependencies from the
> > default x86 icu is trivially avoided using the ant option.
> >
> > > I really believe that we should resolve this issue somehow. Do be
> > > honest I'm tired of this type of failures with downloaded packages
> > > myself.
> >
> > It doesn't seem to be something that has come up often on the -dev
> > list.  How much of a problem is this?
> >
> > > Any ideas or patches to fix this issue?
> > > I'll investigate the problem deeper....
> >
> > I'm not sure we can "fix" this issue - by distributing libstdc++
> > ourselves - because of licensing issues.
> >
> > Regards,
> > Mark.
> >
> >
>
>
> --
> Kind regards,
> Konstantin Lupach
>


-- 
--vvl

------=_Part_6988_24747725.1200539063881--