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 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... SY, Alexey 2008/1/22, Alexey Petrenko <[EMAIL PROTECTED]>: > 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_component.xml:74: > The following error occurred while executing this line: > [exec] > /localdisk/aapetren/harmony/working_vm/build/lnx_ia32_gcc_release/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 <[EMAIL PROTECTED]>: > > > > 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" > > <[EMAIL PROTECTED]> wrote: > > > Thanks, Mark! > > > > > > SY, Alexey > > > > > > 2008/1/16, Mark Hindess <[EMAIL PROTECTED]>: > > > > > > > > On 16 January 2008 at 15:53, "Alexey Petrenko" <[EMAIL PROTECTED] > > > > wrote: > > > > > 2008/1/16, Alexey Varlamov <[EMAIL PROTECTED]>: > > > > > > 2008/1/9, Mark Hindess <[EMAIL PROTECTED]>: > > > > > > > > > > > > > > On 9 January 2008 at 19:07, "Alexey Varlamov" <[EMAIL PROTECTED] > > > 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 > > > > > > > > modularit > > > y; > > > > > > > > 2) Unified approach and shared scripts across Harmony modules - > > > > > > > > VMs > > > , > > > > > > > > classlib, jdktools; > > > > > > > > 3) Reduce duplication of resources (traffic, space, etc) between > > > > > > > > modules within the same workspace; > > > > > > > > I'd also add 4) If possible, reuse resources in different > > > > > > > > workspace > > > 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 few > > > > > > > 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 really > > > > > > 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 now. > > > > > > > > -Mark. > > > > > > > > > > > > > > > > > > > > > >
