You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/05/04 07:29:01 UTC
Re: DRLVM contribution - try this out!
On 3 May 2006 at 18:21, "Elford, Chris L" <ch...@intel.com> wrote:
> Hi all,
>
> Since I shared initial experiences with this package, I thought I
> should do the same on Linux. I have not experienced as much luck there
> yet.
>
> A few notes:
>
> 1) If you are behind a proxy, make sure to follow the instructions
> regarding setting up the svn proxy [~/.subversion/servers]. The proxy
> parameters to build.sh are not passed on to svn.
>
> 2) Don't try to use gcj as the JAVA_HOME for initial compilation. I
> tried this first but it looks for a tools.jar that gcj doesn't have. =20
>
> 3) I did not experience much success on Fedora Core 5. I believe it is
> a compiler issue w/ C++ compatibility [FC5 ships with gcc 4.1.0-3].
> The errors that I get on Fedora core 5 are:
>
> [cc]
> /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> c/include/log4cxx/xml/domconfigurator.h:243: error: extra qualification
> 'log4cxx::xml::DOMConfigurator::' on member 'subst'
> [cc]
> /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> c/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification
> 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8'
> [cc]
> /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> c/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification
> 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8'
> [cc]
> /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> c/include/log4cxx/xml/domconfigurator.h:243: error: extra qualification
> 'log4cxx::xml::DOMConfigurator::' on member 'subst'
> [cc]
> /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> c/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification
> 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8'
>
> 4) I switched back to a Fedora Core 4 system in the hopes that this
> would resolve the compiler issue. Fedora Core 4 comes with gcc
> 4.0.0-8. That doesn't see the errors above but has numerous warnings
> then errors out with some C++ template prototype mismatches. I can
> send a log with the warnings/errors if desired.
>
> The readme indicates that gcc is supported [CXX=gcc].
>
> Is there a specific version of gcc required to get this to compile on
> Fedora Core 4 or Fedora Core 5?
In case this helps anyone else on Linux, I had a few problems:
1) missing bfd.h
Fixed by installing binutils-dev on Debian.
2) Missing ext/stl_hash_fun.h
I was using gcc/g++/libstdc++ 4.0.3 and this header file is called
ext/hash_fun.h on this version. I figure from this that it was intended
to be built using an older 3.x version where the header has the required
name.
Using gcc 3.3.6, I'm stuck building native of vm.jitrino with link
errors:
build.native.link:
[cc] 0 total files to be compiled.
[cc] Starting link
[cc] `.L3696' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o
[cc] `.L3681' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o
[cc] `.L3695' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o
[cc] `.L3682' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o
I decided it was time to get sleep at that point. I will resume
investigating this later.
Regards,
Mark.
---------------------------------------------------------------------
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
Re: DRLVM contribution - try this out!
Posted by Leo Simons <ma...@leosimons.com>.
On Sun, May 07, 2006 at 01:36:11PM +0700, Vladimir Gorr wrote:
> I understand how it works when the patches are integrated to the repository
> on regular base. After this all customers can create new patches and etc.
> etc. etc.
> Here I see no any issues. There are a lot of GUI tools allowing to merge the
> changes.
> The number of patches is a constant approximately.
>
> I don't understand how it should [or will] work when any of contributions
> exists long time
> in the form of zip file. New bugs appear. As a result new patches will be
> created.
> The corresponding JIRA issues are linked to the original contribution. And
> etc. etc.
> It will be continued until all sources are integrated to the repository. I
> don't think
> the customers will be very happy to re-read each time the JIRA description
> to understand
> how to get the recent version of product.
"Customers" should not get sources or patches out of jira. While apache doesn't
have customers as such (since we give everything away for free), what will
happen with harmony as the project matures is that we'll be pushing out source
releases and binary releases, both "snapshots" and "stable" releases, which is
the primary means for *users* to get hold of our "products". Harmony is
essentially sort-of in "stealth mode" right now, which is why those kinds of
things are not yet in place, and neither are facilities such as mailing list for
users or end-user-targetted documentation on how to install it. We don't actually
want that many "regular" users (eg the people just looking for a jdk to use),
since we wouldn't be able to support them, but that will change as this neat
little (heh. Not so little anymore already :-)) project matures.
Hope that clarifies a little!
cheers,
Leo
---------------------------------------------------------------------
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
Re: DRLVM contribution - try this out!
Posted by Vladimir Gorr <vv...@gmail.com>.
Hi Leo,
thank you very much for all details and very valuable links!
Yes, I'm aware about the existence the technologies mentioned by you.
Actually I meant a little bit other thing.
I understand how it works when the patches are integrated to the repository
on regular base. After this all customers can create new patches and etc.
etc. etc.
Here I see no any issues. There are a lot of GUI tools allowing to merge the
changes.
The number of patches is a constant approximately.
I don't understand how it should [or will] work when any of contributions
exists long time
in the form of zip file. New bugs appear. As a result new patches will be
created.
The corresponding JIRA issues are linked to the original contribution. And
etc. etc.
It will be continued until all sources are integrated to the repository. I
don't think
the customers will be very happy to re-read each time the JIRA description
to understand
how to get the recent version of product.
Maybe the latest situation is hypothetical I don't know. Probably I was
wrong when I started this discussion.
In any case thanks for your feedback.
Regards,
Vladimir.
On 5/6/06, Leo Simons <ma...@leosimons.com> wrote:
>
> Hi Vladimir!
>
> On Sat, May 06, 2006 at 08:13:25AM +0700, Vladimir Gorr wrote:
> > Certainly all I'll say is obvious
>
> Don't worry about that one bit. I highly doubt this stuff is obvious for
> most of
> the people reading this list -- you're getting a bunch of responses
> because its
> an interesing topic, not because its an obvious one :-)
>
> > but ...
> > Suppose the patches A & B should change same lines of sources code to
> fix
> > the different bugs.
> > They cannot be accepted independently.
>
> This depends on the specific patch. For example patch A might touch files
> x and y,
> and patch B might touch file z. The patch will then apply "cleanly". For
> cases
> where it doesn't (both A and B touch file x, and the "chunks" of the
> patches do not
> all apply cleanly to that file), its a little more involved.
>
> There is an extensive patch/diff/merge toolchain to take care of this kind
> of thing.
> Basically it is the main secondary activity for the maintainers of the
> linux kernel
> these days (the primary one is reading/verifying/discussing patches), and
> git
> (http://git.or.cz/) is all but completely dedicated to this kind of use
> case.
>
> If it is about source tree X and patches A and B the problem is called a
> "three-way
> merge" [1]. If it is about source tree X and patches A1,A2,...,An it is
> sort of an
> "n-way merge", which becomes n-1 three-way merges.
>
> > Other example when the B patch is
> > created after as A was accepted.
> > In this case we should describe the exact order these patches should
> will be
> > accepted in (a good example is JIRA-443).
>
> Yep! One common way to do this is to postfix the filename for the patch
> with a
> number, eg you get a classlib.patch.txt.1, classlib.patch.txt.2, etc etc.
>
> > I had in mind these things speaking about the advisability to have one
> > patch for the user convenience.
>
> Understood, and many thanks for that! I just think that "parallelized
> patches" is
> a problem (or rather, challenge!) that harmony needs to deal with anyway
> (since
> there is potential for huge numbers of patches especially from users of
> the class
> libraries later on in the project) so we might as well accept it as a
> given and
> design our workflows to match!
>
> cheers,
>
> Leo
>
> [1] -
> http://en.wikipedia.org/wiki/Merge_(revision_control)#Three-Way_Merge
>
> ---------------------------------------------------------------------
> 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
>
>
Re: DRLVM contribution - try this out!
Posted by Leo Simons <ma...@leosimons.com>.
Hi Vladimir!
On Sat, May 06, 2006 at 08:13:25AM +0700, Vladimir Gorr wrote:
> Certainly all I'll say is obvious
Don't worry about that one bit. I highly doubt this stuff is obvious for most of
the people reading this list -- you're getting a bunch of responses because its
an interesing topic, not because its an obvious one :-)
> but ...
> Suppose the patches A & B should change same lines of sources code to fix
> the different bugs.
> They cannot be accepted independently.
This depends on the specific patch. For example patch A might touch files x and y,
and patch B might touch file z. The patch will then apply "cleanly". For cases
where it doesn't (both A and B touch file x, and the "chunks" of the patches do not
all apply cleanly to that file), its a little more involved.
There is an extensive patch/diff/merge toolchain to take care of this kind of thing.
Basically it is the main secondary activity for the maintainers of the linux kernel
these days (the primary one is reading/verifying/discussing patches), and git
(http://git.or.cz/) is all but completely dedicated to this kind of use case.
If it is about source tree X and patches A and B the problem is called a "three-way
merge" [1]. If it is about source tree X and patches A1,A2,...,An it is sort of an
"n-way merge", which becomes n-1 three-way merges.
> Other example when the B patch is
> created after as A was accepted.
> In this case we should describe the exact order these patches should will be
> accepted in (a good example is JIRA-443).
Yep! One common way to do this is to postfix the filename for the patch with a
number, eg you get a classlib.patch.txt.1, classlib.patch.txt.2, etc etc.
> I had in mind these things speaking about the advisability to have one
> patch for the user convenience.
Understood, and many thanks for that! I just think that "parallelized patches" is
a problem (or rather, challenge!) that harmony needs to deal with anyway (since
there is potential for huge numbers of patches especially from users of the class
libraries later on in the project) so we might as well accept it as a given and
design our workflows to match!
cheers,
Leo
[1] - http://en.wikipedia.org/wiki/Merge_(revision_control)#Three-Way_Merge
---------------------------------------------------------------------
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
Re: DRLVM contribution - try this out!
Posted by Vladimir Gorr <vv...@gmail.com>.
Certainly all I'll say is obvious but ...
Suppose the patches A & B should change same lines of sources code to fix
the different bugs.
They cannot be accepted independently. Other example when the B patch is
created after as A was accepted.
In this case we should describe the exact order these patches should will be
accepted in (a good example is JIRA-443).
I had in mind these things speaking about the advisability to have one
patch for the user convenience.
Thanks,
Vladimir.
On 5/5/06, Tim Ellison <t....@gmail.com> wrote:
>
> +1 to Geir's comments below (i.e. that's my preference too)
>
> Regards,
> Tim
>
> Geir Magnusson Jr wrote:
> >
> >
> > Leo Simons wrote:
> >> On Thu, May 04, 2006 at 04:50:28PM -0700, Rana Dasgupta wrote:
> >>> We should probably hold off on patching right now?
> >>
> >> I don't see why you can't attach patches to the relevant jira issue,
> >> if the
> >> code is accepted then its likely the patch will be, too :-)
> >
> > Personally, I'd prefer that new JIRAs are created and linked to the
> > original submission issue, because then we can accept and close JIRAs
> > atomically.
> >
> > We ran into a problem when patches to patches were attached to the same
> > JIRA, and it becomes a bit confusing to try and figure out which is
> > right from the comments.
> >
> > It's much cleaner to say "This patch replaced the patch in HARMONY-XYZ"
> > rather than "this patch replaces the other one I did before I submitted
> > the extra build file" or whatever...
> >
> >>
> >> Patch management is going to be hard if there's a lot of patches, but
> >> that's
> >> just further incentive to get things integrated more quickly ;-)
> >>
> >>> The submission compiles and runs fine with XP V2, msvc VC7 and with
> >>> SUSE
> >>> 9.2 and GCC 3.3.4.
> >>> We should pick the Linux/GCC version that we run Harmony builds
> >>> regularly on and make all the changes in one shot to fix the compile
> on
> >>> that. Has this version already been identified?
> >>
> >> Hmm. I think the key is in making the buildsystem and the code aware of
> >> the linux/gcc version and adapt behaviour based on that.
> >>
> >>>> Is it ok to attach patch here or should I use JIRA?
> >>
> >> In general sending patches through the mailing list is not all that
> >> bad, but
> >> the people integrating code (eg, Tim :-)) do seem to prefer to use
> >> JIRA, so
> >> after talking about things on the list, adding them to jira does make
> >> sense.
> >
> > Yep - JIRA makes it much easier to track and search and know status.
> >
> > geir
> >
> >>
> >> cheers!
> >>
> >> LSD
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> 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
>
>
Re: DRLVM contribution - try this out!
Posted by Leo Simons <ma...@leosimons.com>.
On Fri, May 05, 2006 at 10:24:12AM +0100, Tim Ellison wrote:
> +1 to Geir's comments below (i.e. that's my preference too)
wiki-fy it! :-)
LSD
---------------------------------------------------------------------
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
Re: DRLVM contribution - try this out!
Posted by Tim Ellison <t....@gmail.com>.
+1 to Geir's comments below (i.e. that's my preference too)
Regards,
Tim
Geir Magnusson Jr wrote:
>
>
> Leo Simons wrote:
>> On Thu, May 04, 2006 at 04:50:28PM -0700, Rana Dasgupta wrote:
>>> We should probably hold off on patching right now?
>>
>> I don't see why you can't attach patches to the relevant jira issue,
>> if the
>> code is accepted then its likely the patch will be, too :-)
>
> Personally, I'd prefer that new JIRAs are created and linked to the
> original submission issue, because then we can accept and close JIRAs
> atomically.
>
> We ran into a problem when patches to patches were attached to the same
> JIRA, and it becomes a bit confusing to try and figure out which is
> right from the comments.
>
> It's much cleaner to say "This patch replaced the patch in HARMONY-XYZ"
> rather than "this patch replaces the other one I did before I submitted
> the extra build file" or whatever...
>
>>
>> Patch management is going to be hard if there's a lot of patches, but
>> that's
>> just further incentive to get things integrated more quickly ;-)
>>
>>> The submission compiles and runs fine with XP V2, msvc VC7 and with
>>> SUSE
>>> 9.2 and GCC 3.3.4.
>>> We should pick the Linux/GCC version that we run Harmony builds
>>> regularly on and make all the changes in one shot to fix the compile on
>>> that. Has this version already been identified?
>>
>> Hmm. I think the key is in making the buildsystem and the code aware of
>> the linux/gcc version and adapt behaviour based on that.
>>
>>>> Is it ok to attach patch here or should I use JIRA?
>>
>> In general sending patches through the mailing list is not all that
>> bad, but
>> the people integrating code (eg, Tim :-)) do seem to prefer to use
>> JIRA, so
>> after talking about things on the list, adding them to jira does make
>> sense.
>
> Yep - JIRA makes it much easier to track and search and know status.
>
> geir
>
>>
>> cheers!
>>
>> LSD
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: DRLVM contribution - try this out!
Posted by Vladimir Gorr <vv...@gmail.com>.
In my opinion the presence a lot of patches for same contribution (until it
will be put to SVN) is not good idea.
It's very conveniently to have one patch if its size is not too big.
Otherwise we will have the issues with the maintenance.
Now we try to fix the build problems (using different versions of GCC
compiler). Tomorrow we will (possible) have to fix
new bugs. All these changes should be integrated to one patch. Then each of
us should not forget to accept this patch
not to once more step on rake figuratively speaking. My question is the
following. Whether is it possible to have
the temporary SVN branch where we could accept our patches?
Thanks,
Vladimir.
On 5/5/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Leo Simons wrote:
> > On Thu, May 04, 2006 at 04:50:28PM -0700, Rana Dasgupta wrote:
> >> We should probably hold off on patching right now?
> >
> > I don't see why you can't attach patches to the relevant jira issue, if
> the
> > code is accepted then its likely the patch will be, too :-)
>
> Personally, I'd prefer that new JIRAs are created and linked to the
> original submission issue, because then we can accept and close JIRAs
> atomically.
>
> We ran into a problem when patches to patches were attached to the same
> JIRA, and it becomes a bit confusing to try and figure out which is
> right from the comments.
>
> It's much cleaner to say "This patch replaced the patch in HARMONY-XYZ"
> rather than "this patch replaces the other one I did before I submitted
> the extra build file" or whatever...
>
> >
> > Patch management is going to be hard if there's a lot of patches, but
> that's
> > just further incentive to get things integrated more quickly ;-)
> >
> >> The submission compiles and runs fine with XP V2, msvc VC7 and with
> SUSE
> >> 9.2 and GCC 3.3.4.
> >> We should pick the Linux/GCC version that we run Harmony builds
> >> regularly on and make all the changes in one shot to fix the compile on
> >> that. Has this version already been identified?
> >
> > Hmm. I think the key is in making the buildsystem and the code aware of
> > the linux/gcc version and adapt behaviour based on that.
> >
> >>> Is it ok to attach patch here or should I use JIRA?
> >
> > In general sending patches through the mailing list is not all that bad,
> but
> > the people integrating code (eg, Tim :-)) do seem to prefer to use JIRA,
> so
> > after talking about things on the list, adding them to jira does make
> sense.
>
> Yep - JIRA makes it much easier to track and search and know status.
>
> geir
>
> >
> > cheers!
> >
> > LSD
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
Re: DRLVM contribution - try this out!
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Leo Simons wrote:
> On Thu, May 04, 2006 at 04:50:28PM -0700, Rana Dasgupta wrote:
>> We should probably hold off on patching right now?
>
> I don't see why you can't attach patches to the relevant jira issue, if the
> code is accepted then its likely the patch will be, too :-)
Personally, I'd prefer that new JIRAs are created and linked to the
original submission issue, because then we can accept and close JIRAs
atomically.
We ran into a problem when patches to patches were attached to the same
JIRA, and it becomes a bit confusing to try and figure out which is
right from the comments.
It's much cleaner to say "This patch replaced the patch in HARMONY-XYZ"
rather than "this patch replaces the other one I did before I submitted
the extra build file" or whatever...
>
> Patch management is going to be hard if there's a lot of patches, but that's
> just further incentive to get things integrated more quickly ;-)
>
>> The submission compiles and runs fine with XP V2, msvc VC7 and with SUSE
>> 9.2 and GCC 3.3.4.
>> We should pick the Linux/GCC version that we run Harmony builds
>> regularly on and make all the changes in one shot to fix the compile on
>> that. Has this version already been identified?
>
> Hmm. I think the key is in making the buildsystem and the code aware of
> the linux/gcc version and adapt behaviour based on that.
>
>>> Is it ok to attach patch here or should I use JIRA?
>
> In general sending patches through the mailing list is not all that bad, but
> the people integrating code (eg, Tim :-)) do seem to prefer to use JIRA, so
> after talking about things on the list, adding them to jira does make sense.
Yep - JIRA makes it much easier to track and search and know status.
geir
>
> cheers!
>
> LSD
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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
Re: DRLVM contribution - try this out!
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I linked 443 to the original DRL contrib JIRA.
geir
Ivan Volosyuk wrote:
> Leo, thank you, for the clarification.
>
> I have created JIRA issue 'Harmony-443' with the patch.
> It fixes compilation with GCC-3.4.6
> I have checked, that fix doesn't break GCC-3.3.x build or windows build.
>
> Now I am working on compilation issues with GCC-4.1.0.
> I've found a few in log4cxx and some in jitrino.
>
> Rana, the patch is not intended for immediate acceptance it's just here for
> evaluation.
> --
> Ivan
> Intel Middleware Development
>
> On 5/5/06, Leo Simons <ma...@leosimons.com> wrote:
>>
>>
>> > >Is it ok to attach patch here or should I use JIRA?
>>
>> In general sending patches through the mailing list is not all that bad,
>> but
>> the people integrating code (eg, Tim :-)) do seem to prefer to use JIRA,
>> so
>> after talking about things on the list, adding them to jira does make
>> sense.
>>
>> cheers!
>>
>> LSD
>>
>>
>
---------------------------------------------------------------------
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
Re: DRLVM contribution - try this out!
Posted by Ivan Volosyuk <iv...@gmail.com>.
Leo, thank you, for the clarification.
I have created JIRA issue 'Harmony-443' with the patch.
It fixes compilation with GCC-3.4.6
I have checked, that fix doesn't break GCC-3.3.x build or windows build.
Now I am working on compilation issues with GCC-4.1.0.
I've found a few in log4cxx and some in jitrino.
Rana, the patch is not intended for immediate acceptance it's just here for
evaluation.
--
Ivan
Intel Middleware Development
On 5/5/06, Leo Simons <ma...@leosimons.com> wrote:
>
>
> > >Is it ok to attach patch here or should I use JIRA?
>
> In general sending patches through the mailing list is not all that bad,
> but
> the people integrating code (eg, Tim :-)) do seem to prefer to use JIRA,
> so
> after talking about things on the list, adding them to jira does make
> sense.
>
> cheers!
>
> LSD
>
>
Re: DRLVM contribution - try this out!
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, May 04, 2006 at 04:50:28PM -0700, Rana Dasgupta wrote:
> We should probably hold off on patching right now?
I don't see why you can't attach patches to the relevant jira issue, if the
code is accepted then its likely the patch will be, too :-)
Patch management is going to be hard if there's a lot of patches, but that's
just further incentive to get things integrated more quickly ;-)
> The submission compiles and runs fine with XP V2, msvc VC7 and with SUSE
> 9.2 and GCC 3.3.4.
> We should pick the Linux/GCC version that we run Harmony builds
> regularly on and make all the changes in one shot to fix the compile on
> that. Has this version already been identified?
Hmm. I think the key is in making the buildsystem and the code aware of
the linux/gcc version and adapt behaviour based on that.
> >Is it ok to attach patch here or should I use JIRA?
In general sending patches through the mailing list is not all that bad, but
the people integrating code (eg, Tim :-)) do seem to prefer to use JIRA, so
after talking about things on the list, adding them to jira does make sense.
cheers!
LSD
---------------------------------------------------------------------
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
Re: DRLVM contribution - try this out!
Posted by Rana Dasgupta <rd...@gmail.com>.
We should probably hold off on patching right now?
The submission compiles and runs fine with XP V2, msvc VC7 and with SUSE
9.2 and GCC 3.3.4.
We should pick the Linux/GCC version that we run Harmony builds
regularly on and make all the changes in one shot to fix the compile on
that. Has this version already been identified?
Thanks,
Rana Dasgupta
Intel Middleware Development
On 5/4/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> Great! Good progress.
>
> Here is mine:
> gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
> Gcc-4.x is masked in gentoo, so I have started with gcc-3.4.6.
>
> It was harder then before. I have made number of changes in
> jitrino/**/Set.h
> to get it compile.
> A few more changes in other places in jitrino, and it builds and eclipse
> works again.
> I am not sure it still builds on gcc-3.3.6. All changes should be portable
> to 3.3.6 IMHO except for renaming "ext/stl_hash_map.h" to
> "ext/hash_map.h".
> Looks like the compile-time check for GCC version is needed here.
>
> Is it ok to attach patch here or should I use JIRA?
> --
> Ivan
>
>
> On 5/4/06, Mark Hindess <ma...@googlemail.com> wrote:
> >
> >
> > On 4 May 2006 at 21:43, "Ivan Volosyuk" <iv...@gmail.com> wrote:
> > >
> > > DRLVM compiled fine on my home computer. Eclipse works.
> > > Configuration:
> > > Gentoo stable, not much up to date.
> > > gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
> > > Binutils: 2.16.1
> > > Kernel: 2.6.15.6
> >
> > I'm using Debian testing and I'd tried downgrading everything except
> > binutils which would have been a little too much trouble. So I ended up
> > building a chroot image with Debian sarge/stable. I then installed the
> > ant and ant-optional packages from testing. The build then worked!
> >
> > The key package versions required were:
> >
> > ant-optional/testing 1.6.5-5
> > ant/testing 1.6.5-5
> > binutils-dev/stable 2.15-6
> > binutils/stable 2.15-6
> > g++-3.3/stable 1:3.3.5-13
> > g++/stable 4:3.3.5-3
> > gcc-3.3-base/stable 1:3.3.5-13
> > gcc-3.3/stable 1:3.3.5-13
> > gcc/stable 4:3.3.5-3
> > libstdc++5-3.3-dev/stable 1:3.3.5-13
> > libstdc++5/stable 1:3.3.5-13
> >
> > > One build issue:
> > > When using /usr/bin/ant compilation failed even for ant-1.6.5, I have
> > > compiled custom ant in home directory and it worked for me.
> > >
> > > I'm going to upgrade to Gcc 4.x and fix the compilation on it.
> >
> > Cool. Keep us posted with progress.
> >
> > Regards,
> > Mark.
> >
> > > On 5/4/06, Mark Hindess <ma...@googlemail.com> wrote:
> > > >
> > > >
> > > > On 4 May 2006 at 13:58, "Andrey Chernyshev" <
> a.y.chernyshev@gmail.com>
> > > > wrote:
> > > > >
> > > > > Mark Hindess wrote:
> > > > > > Using gcc 3.3.6, I'm stuck building native of vm.jitrino with
> link
> > > > > > errors:
> > > > >
> > > > > I can suggest that link errors may be result of previous
> compilation
> > > > > with GCC 4.0 and then subsequent attempt to link with GCC 3.3.6.
> > > > > You may do the "build clean" first if you are changing the things
> > like
> > > > > compiler, or, manually delete the directory
> > > > > Harmony/build/lnx_ia32_gcc_release before rebuilding.
> > > >
> > > > Yeah, that was the first thing I tried. That got rid of some errors
> > but
> > > > left me with the ones I posted.
> > > >
> > > > > We didn't check that this can be built on a whole variety of
> > existing
> > > > > Linux distributions and different GCC versions, this would be a
> huge
> > > > > task that only Harmony can afford to do :)
> > > >
> > > > Absolutely. I'm certainly not complaining. I'm just trying to help
> > > > others avoid tripping over the same problems that I'm seeing ... and
> > > > hopefully fixing. ;-)
> > > >
> > > > > One of the configurations that worked fine was:
> > > > > SuSE Linux 9.2 (i586)
> > > > > kernel release: 2.6.8-24-smp
> > > > > gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
> > > >
> > > > This is v. useful. Thanks.
> > > >
> > > > Hmm. That is a slightly older gcc than the version I'm using. As a
> > > > first step, I might try to build with that exact version. If/when I
> > get
> > > > something that works, I can start to investigate the differences.
> > > >
> > > > Regards,
> > > > Mark.
> > > >
> > > >
> > > >
> > >
> > > ------=_Part_3248_11123540.1146764639573--
> >
> >
> >
>
>
Re: DRLVM contribution - try this out!
Posted by Ivan Volosyuk <iv...@gmail.com>.
Great! Good progress.
Here is mine:
gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
Gcc-4.x is masked in gentoo, so I have started with gcc-3.4.6.
It was harder then before. I have made number of changes in jitrino/**/Set.h
to get it compile.
A few more changes in other places in jitrino, and it builds and eclipse
works again.
I am not sure it still builds on gcc-3.3.6. All changes should be portable
to 3.3.6 IMHO except for renaming "ext/stl_hash_map.h" to "ext/hash_map.h".
Looks like the compile-time check for GCC version is needed here.
Is it ok to attach patch here or should I use JIRA?
--
Ivan
On 5/4/06, Mark Hindess <ma...@googlemail.com> wrote:
>
>
> On 4 May 2006 at 21:43, "Ivan Volosyuk" <iv...@gmail.com> wrote:
> >
> > DRLVM compiled fine on my home computer. Eclipse works.
> > Configuration:
> > Gentoo stable, not much up to date.
> > gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
> > Binutils: 2.16.1
> > Kernel: 2.6.15.6
>
> I'm using Debian testing and I'd tried downgrading everything except
> binutils which would have been a little too much trouble. So I ended up
> building a chroot image with Debian sarge/stable. I then installed the
> ant and ant-optional packages from testing. The build then worked!
>
> The key package versions required were:
>
> ant-optional/testing 1.6.5-5
> ant/testing 1.6.5-5
> binutils-dev/stable 2.15-6
> binutils/stable 2.15-6
> g++-3.3/stable 1:3.3.5-13
> g++/stable 4:3.3.5-3
> gcc-3.3-base/stable 1:3.3.5-13
> gcc-3.3/stable 1:3.3.5-13
> gcc/stable 4:3.3.5-3
> libstdc++5-3.3-dev/stable 1:3.3.5-13
> libstdc++5/stable 1:3.3.5-13
>
> > One build issue:
> > When using /usr/bin/ant compilation failed even for ant-1.6.5, I have
> > compiled custom ant in home directory and it worked for me.
> >
> > I'm going to upgrade to Gcc 4.x and fix the compilation on it.
>
> Cool. Keep us posted with progress.
>
> Regards,
> Mark.
>
> > On 5/4/06, Mark Hindess <ma...@googlemail.com> wrote:
> > >
> > >
> > > On 4 May 2006 at 13:58, "Andrey Chernyshev" <a....@gmail.com>
> > > wrote:
> > > >
> > > > Mark Hindess wrote:
> > > > > Using gcc 3.3.6, I'm stuck building native of vm.jitrino with link
> > > > > errors:
> > > >
> > > > I can suggest that link errors may be result of previous compilation
> > > > with GCC 4.0 and then subsequent attempt to link with GCC 3.3.6.
> > > > You may do the "build clean" first if you are changing the things
> like
> > > > compiler, or, manually delete the directory
> > > > Harmony/build/lnx_ia32_gcc_release before rebuilding.
> > >
> > > Yeah, that was the first thing I tried. That got rid of some errors
> but
> > > left me with the ones I posted.
> > >
> > > > We didn't check that this can be built on a whole variety of
> existing
> > > > Linux distributions and different GCC versions, this would be a huge
> > > > task that only Harmony can afford to do :)
> > >
> > > Absolutely. I'm certainly not complaining. I'm just trying to help
> > > others avoid tripping over the same problems that I'm seeing ... and
> > > hopefully fixing. ;-)
> > >
> > > > One of the configurations that worked fine was:
> > > > SuSE Linux 9.2 (i586)
> > > > kernel release: 2.6.8-24-smp
> > > > gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
> > >
> > > This is v. useful. Thanks.
> > >
> > > Hmm. That is a slightly older gcc than the version I'm using. As a
> > > first step, I might try to build with that exact version. If/when I
> get
> > > something that works, I can start to investigate the differences.
> > >
> > > Regards,
> > > Mark.
> > >
> > >
> > >
> >
> > ------=_Part_3248_11123540.1146764639573--
>
>
>
Re: DRLVM contribution - try this out!
Posted by Ivan Volosyuk <iv...@gmail.com>.
DRLVM compiled fine on my home computer. Eclipse works.
Configuration:
Gentoo stable, not much up to date.
gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
Binutils: 2.16.1
Kernel: 2.6.15.6
One build issue:
When using /usr/bin/ant compilation failed even for ant-1.6.5, I have
compiled custom ant in home directory and it worked for me.
I'm going to upgrade to Gcc 4.x and fix the compilation on it.
--
Ivan
On 5/4/06, Mark Hindess <ma...@googlemail.com> wrote:
>
>
> On 4 May 2006 at 13:58, "Andrey Chernyshev" <a....@gmail.com>
> wrote:
> >
> > Mark Hindess wrote:
> > > Using gcc 3.3.6, I'm stuck building native of vm.jitrino with link
> > > errors:
> >
> > I can suggest that link errors may be result of previous compilation
> > with GCC 4.0 and then subsequent attempt to link with GCC 3.3.6.
> > You may do the "build clean" first if you are changing the things like
> > compiler, or, manually delete the directory
> > Harmony/build/lnx_ia32_gcc_release before rebuilding.
>
> Yeah, that was the first thing I tried. That got rid of some errors but
> left me with the ones I posted.
>
> > We didn't check that this can be built on a whole variety of existing
> > Linux distributions and different GCC versions, this would be a huge
> > task that only Harmony can afford to do :)
>
> Absolutely. I'm certainly not complaining. I'm just trying to help
> others avoid tripping over the same problems that I'm seeing ... and
> hopefully fixing. ;-)
>
> > One of the configurations that worked fine was:
> > SuSE Linux 9.2 (i586)
> > kernel release: 2.6.8-24-smp
> > gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
>
> This is v. useful. Thanks.
>
> Hmm. That is a slightly older gcc than the version I'm using. As a
> first step, I might try to build with that exact version. If/when I get
> something that works, I can start to investigate the differences.
>
> Regards,
> Mark.
>
>
>
Re: DRLVM contribution - try this out!
Posted by Andrey Chernyshev <a....@gmail.com>.
> Using gcc 3.3.6, I'm stuck building native of vm.jitrino with link
> errors:
I can suggest that link errors may be result of previous compilation
with GCC 4.0 and then subsequent attempt to link with GCC 3.3.6.
You may do the "build clean" first if you are changing the things like
compiler, or, manually delete the directory
Harmony/build/lnx_ia32_gcc_release before rebuilding.
We didn't check that this can be built on a whole variety of existing
Linux distributions and different GCC versions, this would be a huge
task that only Harmony can afford to do :)
One of the configurations that worked fine was:
SuSE Linux 9.2 (i586)
kernel release: 2.6.8-24-smp
gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
Thanks,
Andrey.
On 5/4/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 3 May 2006 at 18:21, "Elford, Chris L" <ch...@intel.com> wrote:
> > Hi all,
> >
> > Since I shared initial experiences with this package, I thought I
> > should do the same on Linux. I have not experienced as much luck there
> > yet.
> >
> > A few notes:
> >
> > 1) If you are behind a proxy, make sure to follow the instructions
> > regarding setting up the svn proxy [~/.subversion/servers]. The proxy
> > parameters to build.sh are not passed on to svn.
> >
> > 2) Don't try to use gcj as the JAVA_HOME for initial compilation. I
> > tried this first but it looks for a tools.jar that gcj doesn't have. =20
> >
> > 3) I did not experience much success on Fedora Core 5. I believe it is
> > a compiler issue w/ C++ compatibility [FC5 ships with gcc 4.1.0-3].
> > The errors that I get on Fedora core 5 are:
> >
> > [cc]
> > /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> > c/include/log4cxx/xml/domconfigurator.h:243: error: extra qualification
> > 'log4cxx::xml::DOMConfigurator::' on member 'subst'
> > [cc]
> > /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> > c/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification
> > 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8'
> > [cc]
> > /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> > c/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification
> > 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8'
> > [cc]
> > /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> > c/include/log4cxx/xml/domconfigurator.h:243: error: extra qualification
> > 'log4cxx::xml::DOMConfigurator::' on member 'subst'
> > [cc]
> > /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> > c/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification
> > 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8'
> >
> > 4) I switched back to a Fedora Core 4 system in the hopes that this
> > would resolve the compiler issue. Fedora Core 4 comes with gcc
> > 4.0.0-8. That doesn't see the errors above but has numerous warnings
> > then errors out with some C++ template prototype mismatches. I can
> > send a log with the warnings/errors if desired.
> >
> > The readme indicates that gcc is supported [CXX=gcc].
> >
> > Is there a specific version of gcc required to get this to compile on
> > Fedora Core 4 or Fedora Core 5?
>
> In case this helps anyone else on Linux, I had a few problems:
>
> 1) missing bfd.h
>
> Fixed by installing binutils-dev on Debian.
>
> 2) Missing ext/stl_hash_fun.h
>
> I was using gcc/g++/libstdc++ 4.0.3 and this header file is called
> ext/hash_fun.h on this version. I figure from this that it was intended
> to be built using an older 3.x version where the header has the required
> name.
>
> Using gcc 3.3.6, I'm stuck building native of vm.jitrino with link
> errors:
>
> build.native.link:
> [cc] 0 total files to be compiled.
> [cc] Starting link
> [cc] `.L3696' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o
> [cc] `.L3681' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o
> [cc] `.L3695' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o
> [cc] `.L3682' referenced in section `.rodata' of ../_obj/JavaLabelPrepass.o: defined in discarded section `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of ../_obj/JavaLabelPrepass.o
>
> I decided it was time to get sleep at that point. I will resume
> investigating this later.
>
> Regards,
> Mark.
>
>
>
---------------------------------------------------------------------
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
Re: DRLVM contribution - try this out!
Posted by Vladimir Gorr <vv...@gmail.com>.
Hi Mark,
thank you very much for this valuable information. Indeed we used the gcc of
3.X version to build DRLVM.
It's not clear a cause why this header file (stl_hash_fun.h) has been
renamed for the recent gcc versions.
It seems the DRLVM sources should be correspondingly tuned to avoid the
problem detected by you.
Thanks,
Vladimir.
On 5/4/06, Mark Hindess <ma...@googlemail.com> wrote:
>
>
> On 3 May 2006 at 18:21, "Elford, Chris L" <ch...@intel.com>
> wrote:
> > Hi all,
> >
> > Since I shared initial experiences with this package, I thought I
> > should do the same on Linux. I have not experienced as much luck there
> > yet.
> >
> > A few notes:
> >
> > 1) If you are behind a proxy, make sure to follow the instructions
> > regarding setting up the svn proxy [~/.subversion/servers]. The proxy
> > parameters to build.sh are not passed on to svn.
> >
> > 2) Don't try to use gcj as the JAVA_HOME for initial compilation. I
> > tried this first but it looks for a tools.jar that gcj doesn't have. =20
> >
> > 3) I did not experience much success on Fedora Core 5. I believe it is
> > a compiler issue w/ C++ compatibility [FC5 ships with gcc 4.1.0-3].
> > The errors that I get on Fedora core 5 are:
> >
> > [cc]
> > /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> > c/include/log4cxx/xml/domconfigurator.h:243: error: extra qualification
> > 'log4cxx::xml::DOMConfigurator::' on member 'subst'
> > [cc]
> > /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> > c/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification
> > 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8'
> > [cc]
> > /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> > c/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification
> > 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8'
> > [cc]
> > /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> > c/include/log4cxx/xml/domconfigurator.h:243: error: extra qualification
> > 'log4cxx::xml::DOMConfigurator::' on member 'subst'
> > [cc]
> > /usr/local/src/Harmony/build/lnx_ia32_gcc_release/semis/extra/log4cxx/sr
> > c/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification
> > 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8'
> >
> > 4) I switched back to a Fedora Core 4 system in the hopes that this
> > would resolve the compiler issue. Fedora Core 4 comes with gcc
> > 4.0.0-8. That doesn't see the errors above but has numerous warnings
> > then errors out with some C++ template prototype mismatches. I can
> > send a log with the warnings/errors if desired.
> >
> > The readme indicates that gcc is supported [CXX=gcc].
> >
> > Is there a specific version of gcc required to get this to compile on
> > Fedora Core 4 or Fedora Core 5?
>
> In case this helps anyone else on Linux, I had a few problems:
>
> 1) missing bfd.h
>
> Fixed by installing binutils-dev on Debian.
>
> 2) Missing ext/stl_hash_fun.h
>
> I was using gcc/g++/libstdc++ 4.0.3 and this header file is called
> ext/hash_fun.h on this version. I figure from this that it was intended
> to be built using an older 3.x version where the header has the required
> name.
>
> Using gcc 3.3.6, I'm stuck building native of vm.jitrino with link
> errors:
>
> build.native.link:
> [cc] 0 total files to be compiled.
> [cc] Starting link
> [cc] `.L3696' referenced in section `.rodata' of
> ../_obj/JavaLabelPrepass.o: defined in discarded section
> `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of
> ../_obj/JavaLabelPrepass.o
> [cc] `.L3681' referenced in section `.rodata' of
> ../_obj/JavaLabelPrepass.o: defined in discarded section
> `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of
> ../_obj/JavaLabelPrepass.o
> [cc] `.L3695' referenced in section `.rodata' of
> ../_obj/JavaLabelPrepass.o: defined in discarded section
> `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of
> ../_obj/JavaLabelPrepass.o
> [cc] `.L3682' referenced in section `.rodata' of
> ../_obj/JavaLabelPrepass.o: defined in discarded section
> `.gnu.linkonce.t._ZN7Jitrino16JavaLabelPrepass11getJavaTypeEPNS_4TypeE' of
> ../_obj/JavaLabelPrepass.o
>
> I decided it was time to get sleep at that point. I will resume
> investigating this later.
>
> Regards,
> Mark.
>
>
>
> ---------------------------------------------------------------------
> 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
>
>