On 22 January 2008 at 23:07, "Alexey Petrenko" <[EMAIL PROTECTED]> 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 <[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_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 <[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] > il.com > > > > > wrote: > > > > > > 2008/1/16, Alexey Varlamov <[EMAIL PROTECTED]>: > > > > > > > 2008/1/9, Mark Hindess <[EMAIL PROTECTED]>: > > > > > > > > > > > > > > > > On 9 January 2008 at 19:07, "Alexey Varlamov" <alexey.v.varlamo > [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 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
