Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of gshimansky@gmail.com designates
 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:from:reply-to:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id;
        b=sZPzfrUB/h7a1XSo5aWI8otsPv56H6cnyvEOgYrkhWYmBkuvHra99qsueSm2vr5bkYez6kPD0XB5SP4CdcAu/W/zXcHcvh7najW+BO9lCr+dqJwBBuwqOl/dzzNSzOGiyTel2K7RAi15cUS5OKznO2IlI7H52kt/qRgDTFswl4Y=
From: Gregory Shimansky <gshimansky@gmail.com>
Reply-To: harmony-dev@incubator.apache.org
To: harmony-dev@incubator.apache.org
Subject: Re: [depends]  mark and I were chatting
Date: Tue, 27 Jun 2006 22:00:08 +0400
User-Agent: KMail/1.9.1
References: <44A10FE4.1050401@pobox.com>
In-Reply-To: <44A10FE4.1050401@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200606272200.09581.gshimansky@gmail.com>

Hello Geir

I am not sure if it is appropriate to write in this thread, but it is about 
external resources as well. I've recently stumbled upon a strange problem 
with libhyzlib.so. For its build this library uses zlib sources downloaded 
and unpacked directly in classlib.

The problem which I have is on SuSE 9 (gcc-3.3.3). 3 drlvm tests and specjvm98 
segfault inside of inflate code from libhyzlib.so. The bug is not easy to 
reproduce, when I changed -O1 option to -O0 the problem went away.

I've tried to investigate the problem and the general consensus in intel team 
was that it is likely to be because of symbols collison between libhyzlib.so 
and the system /lib/libz.so which drlvm is linked with. This has been proved 
by linking libhyzlib.so with -Wl,-Bsymbolic option. This option makes linker 
to attempt to resolve all internal symbol references inside of library upon 
linking as opposed to the normal way of resolving all symbols at runtime. The 
library linked with -Bsymbolic does not cause any crashes.

<drlvm description="Problems with symbol collisions" reading="optional">

Symbol collisions like this may really be a problem on linux and we've 
encountered the problem several times already with drlvm. On linux it has a 
quite imperfect linking procedure between its components like vmcore and gc. 
The problem is that all libraries export all of the symbols (linked 
with -Wl,-export-dynamic).

Symbols are the same, in vmcore there is a variable, in gc library it is a 
function. When a library is first loaded into the process (e.g. vmcore), its 
symbols are considered resolved, then when gc library is loaded, only those 
symbols which names are new in the process space are resolved. Then when 
vmcore calls gc, which calls some of its functions which are named with the 
same name as a symbol in vmcore, the call goes to a variable in vmcore (it 
was first) and this causes a crash. This is avoided by using -Wl,-Bsymbolic 
which resolves all internal cross references at link it, so all internal 
calls inside of gc are resolved already before library is loaded. On windows 
this seems to be the default way.

The problem mentioned above in VM should be fixed at some point, 
using -Bsymbolic is really a crutch. Only necessary symbols should be 
exported using linking scripts or recently added gcc capabilities [1] to 
control symbols visibility at source level.

</drlvm>

The symbols collision is possible between libhyzlib.so and system installed 
libz because libz is loaded first into the process space when vm is 
initialized.

I didn't find the exact prove that this is really symbols collosion (maybe it 
is a gcc-3.3.3 bug after all, at home classlib compiled with gcc-3.4.6 and 
gcc-4.1.0 doesn't give any segfaults) but still. Why does classlib require 
its own zlib to be built from sources? Shouldn't it be another external 
dependency provided in binary form or by the system?

[1] http://gcc.gnu.org/wiki/Visibility

On Tuesday 27 June 2006 15:00 Geir Magnusson Jr wrote:
> Just a note to get some more discussion going.
>
> Mark and I were talking about how to start refactoring out dependencies
> to a 'peer' to drlvm and classlib.  And Tim and I have discussed this
> too... I just want to capture and get the conversation out here...
>
> So, the idea is that it would be nice to have a common place for
> dependencies that parts of Harmony can point to w/ an assist in filling
> in.  (I.e - make it easy to get stuff.)
>
> Second, we also want to give each subcomponent (drlvm, jchevm, classlib)
> full freedom for dependencies via a simple property setting, so that
> people have full freedom to do what they want...
>
> So as a starting point... (names are open to change) ... something like :
>
> /deps
>   deps.properties
>   build.xml
>     /build
>     /external
>            /ecj
>                 /3.2
>                 /3.3
>            /apr
>                 /2.1
>                 /2.2
>
> etc
>
>
> where
>
> deps.properties is something like
>
> ECJJAR = ... path to 'default' verison
> APRINCLUDE = ... etc...
>
> So that people can reconfigure locally, and even override in a
> build.properties or something
>
> Big issue here is that each artifact will have different things, like
> libs and includes, jars, etc..
>
> the build.xml will be the top-level ant script that can fetch, update
> and build the deps...

-- 
Gregory Shimansky, Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org