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 stepan.mishura@gmail.com
 designates 209.85.146.182 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:content-transfer-encoding:content-disposition:references;
        b=ceas9UkO7Aq9qJ+gSsFSAkIVex0ZqOx1aVWCglCuNf6Nn8KGLLrphmDLvtXMjWcdT5dQIe48M/D7bdoOvQ/Lx570qveskM47h8gQkxr7bhGYthUiGs0/Gl+QEMPtdbAwR421g/5RQW0ESVyYMgD/2bRa3F8GN9B3MdTYRCnR3g8=
Message-ID: <6e47b64f0801152137i5c4c13cfp730b35979cb2496c@mail.gmail.com>
Date: Wed, 16 Jan 2008 11:37:44 +0600
From: "Stepan Mishura" <stepan.mishura@gmail.com>
To: dev@harmony.apache.org
Subject: Re: latest stable packages JRE packages - jre-r603534 (M4)
In-Reply-To: <a52d53dd0801150930s2ec1ecc9t2a1f59c03117b332@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <a52d53dd0801150930s2ec1ecc9t2a1f59c03117b332@mail.gmail.com>

Hi Konstantin,

On 1/15/08, Konstantin Lupach <konstantin.lupach@gmail.com> wrote:
> 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?
>

Yes, you are right - both packages depend on libstdc++.so.6.
Sorry, I missed that - OSes on the build hosts were upgraded and now
libstdc++.so.6 is linked but still ICU libraries by default go with
libstdc++.so.5 dependency.

I think this is the right time to start publishing binaries with
libstdc++.so.6 dependency only.
Mark, you have committed ICU built libraries in
depends/libs/linux.x86.libstdc++6. How we can get the same for x86_64
platform?


> 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.
>

Yep, this issue was discussed some time ago. Any VM guru want to comment this?

-Stepan.

> We are looking at the opportunity to use a single VM package (per CPU
> architecture and OS family) and redistribute it with our product that is
> distributed in the binary form and supports a large variety of Linux
> operating systems.
>
> --
> Kind regards,
> Konstantin Lupach
>