harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [build] managing external dependencies
Date Tue, 22 Jan 2008 20:31:51 GMT

On 22 January 2008 at 23:07, "Alexey Petrenko" <alexey.a.petrenko@gmail.com> 
wrote:
> Looks like the problem with libstdc++ versions again. drlvm build
> creates symbolic links to icu libraries in linux.x86 while now this
> directory is empty and the files exists in linux.x86.libstdc++6 only.

I don't see how you'd get this type of issue if -Duse.libstdc++6=true
(or =false) was passed consistently to both the classlib and drlvm build.

> I could not find an option in drlvm build to fix the situation. Any ideas?
> 
> BTW, I'm curios how it worked before when drlvm linked v5 icu on v6 machines.
> ..

It was broken before - i.e. it would ignore the libstdc++6 setting and
link against the libstdc++5 versions which happened to have the same
interface so didn't cause any problems - but before all versions existed
because the directory tree was checked in for all platforms/variants.

-Mark.

> 2008/1/22, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
> > I got the following error on federated build which looks as a result
> > of this change:
> >
> > === cut ===
> >      [exec] -init-unix:
> >      [exec]   [symlink] ln -s
> > /localdisk/aapetren/harmony/working_classlib/depends/libs/linux.x86/icu-3.4
> /libicuuc.so.34
> > /localdisk/aapetren/harmony/working_classlib/depends/libs/linux.x86/icu-3.4
> /libicuuc.so
> >      [exec]   [symlink] /bin/ln: creating symbolic link
> > `/localdisk/aapetren/harmony/working_classlib/depends/libs/linux.x86/icu-3.
> 4/libicuuc.so':
> > File exists
> >
> >      [exec] BUILD FAILED
> >      [exec] /localdisk/aapetren/harmony/working_vm/build/make/build.xml:600
> :
> > The following error occurred while executing this line:
> >      [exec] /localdisk/aapetren/harmony/working_vm/build/make/build.xml:607
> :
> > The following error occurred while executing this line:
> >      [exec] /localdisk/aapetren/harmony/working_vm/build/make/build_compone
> nt.xml:74:
> > The following error occurred while executing this line:
> >      [exec] /localdisk/aapetren/harmony/working_vm/build/lnx_ia32_gcc_relea
> se/semis/build/init_vm.vmcore.xml:23:
> > ln failed with return code 1
> >
> >      [exec] Total time: 2 minutes 36 seconds
> >      [exec] *
> >      [exec] * Please, refer to README.txt for details.
> >
> > BUILD FAILED
> > /localdisk/aapetren/harmony/build.xml:407: exec returned: 1
> >
> > Total time: 7 minutes 45 seconds
> > === cut ===
> >
> > Will try to  find a solution.
> > Any suggestions are welcome :)
> >
> > SY, Alexey
> >
> > 2008/1/17, Mark Hindess <mark.hindess@googlemail.com>:
> > >
> > > I've committed r612947 with the trickiest part of the icu dll
> > > restructuring now.  Hopefully I've not broken too much.
> > >
> > > A clean (pre-fetch-depends) classlib svn tree shrinks from 542M to just
> > > 265M.  Of course, some of it will be added back by fetch-depends but
> > > even so that is a massive improvement.
> > >
> > > Thanks to Tim for prompting me to do this - though typically it turned
> > > out to be a can of worms[0].
> > >
> > > Regards,
> > >  Mark.
> > >
> > > [0] http://www.answers.com/topic/can-of-worms
> > >
> > > On 17 January 2008 at 11:31, "Alexey Petrenko"
> > > <alexey.a.petrenko@gmail.com> wrote:
> > > > Thanks, Mark!
> > > >
> > > > SY, Alexey
> > > >
> > > > 2008/1/16, Mark Hindess <mark.hindess@googlemail.com>:
> > > > >
> > > > > On 16 January 2008 at 15:53, "Alexey Petrenko" <alexey.a.petrenko@gma
> il.com
> > > > > wrote:
> > > > > > 2008/1/16, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> > > > > > > 2008/1/9, Mark Hindess <mark.hindess@googlemail.com>:
> > > > > > > >
> > > > > > > > On 9 January 2008 at 19:07, "Alexey Varlamov" <alexey.v.varlamo
> v@gmai
> > > > l.co
> > > > > > m> wrote:
> > > > > > > > > Folks,
> > > > > > > > >
> > > > > > > > > We did a few iterations refactoring the subject
- let's have 
> one mo
> > > > re a
> > > > > > ccess
> > > > > > > > > ;).
> > > > > > > > > Why? There was a desire to have the following:
> > > > > > > > > 1) More fine-grained control over dependencies
to empower mod
> ularit
> > > > y;
> > > > > > > > > 2) Unified approach and shared scripts across
Harmony modules
>  - VMs
> > > > ,
> > > > > > > > > classlib, jdktools;
> > > > > > > > > 3) Reduce duplication of resources (traffic,
space, etc) betw
> een
> > > > > > > > > modules within the same workspace;
> > > > > > > > > I'd also add 4) If possible, reuse resources
in different wor
> kspace
> > > > s.
> > > > > > > > > This would be quite handy for committing purposes
and for
> > > > > > > > > multi-platform development.
> > > > > > > >
> > > > > > > > I like all of the above but would add Tim's suggestion
from a f
> ew wee
> > > > ks
> > > > > > > > back which I think was something like:
> > > > > > > >
> > > > > > > > 5) Move binary dependencies - like all the icu libs
- from the 
> enhanc
> > > > ed
> > > > > > > > to the standard tree in svn and download them via
http as we do
>  other
> > > > > > > > dependencies during the fetch-depends stage.
> > > > > > >
> > > > > > > +1. Checking out tens of megabytes of unrelated binaries
is reall
> y anno
> > > > ying
> > > > > > !
> > > > > > +1
> > > > >
> > > > > I started looking at fixing this earlier today ... making steady
> > > > > progress but I've just got a new laptop so I am a little distracted
n
> ow.
> > > > >
> > > > > -Mark.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
> 



Mime
View raw message