RE: [drlvm] building jitrino in release mode
As I reported at http://issues.apache.org/jira/browse/HARMONY-1969 I
succeeded by making two changes:
* Changed build.sh
* Needed to comment a fatal warning flag
But this was on SuSE, not Ubuntu.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 4:32 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] building jitrino in release mode
Well, I have problems. I was on a short trip this week - I'll be back
at home tomorrow morning, and can revisit...
geir
Mikhail Fursov wrote:
It looks very strange to me. I've just checked linux debug build with
the
only change in build.sh (replaced -Dvm.jitrino.cfg=releaase to -
Dvm.jitrino.cfg=debug) and debug version of library was built without
any
problems.
On 11/6/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
Alex Astapchuk wrote:
Geir Magnusson Jr. wrote:
I've been having some problems getting some test cases to
exhibit
misbehavior for DRLVM, and it turns out that jitrino is built in
release mode no matter what BUILD_CFG is set to.
Yes, this is a long-long story.
Was done as 'we-will-change-it-back-soon' thing, but remains till
this
moment. :-)
When I get it to build, I'll change it back today :)
Putting this inconsistency aside for a moment, how do I get
jitrino
to build in debug?
Here it is: http://tinyurl.com/yxjp4v
This are patches for jitrino.xml build.bat, the same change
(remove
-Dvm.jitrino.cfg=release) need to be done for build.sh as well.
k (I made the change in build.sh, as I never work on windows...).
I'll
look at jitrino.xml (I can't see your URL... I'm in a car at the
moment...)
If it helps, then here is the copy:
=
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern
includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+compiler id=cpp.compiler extends=common.cpp.compiler
=
--
Thanks,
Alex
Re: [drlvm] building jitrino in release mode
Well, I have problems. I was on a short trip this week - I'll be back
at home tomorrow morning, and can revisit...
geir
Mikhail Fursov wrote:
It looks very strange to me. I've just checked linux debug build with the
only change in build.sh (replaced -Dvm.jitrino.cfg=releaase to -
Dvm.jitrino.cfg=debug) and debug version of library was built without any
problems.
On 11/6/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
Alex Astapchuk wrote:
Geir Magnusson Jr. wrote:
I've been having some problems getting some test cases to exhibit
misbehavior for DRLVM, and it turns out that jitrino is built in
release mode no matter what BUILD_CFG is set to.
Yes, this is a long-long story.
Was done as 'we-will-change-it-back-soon' thing, but remains till this
moment. :-)
When I get it to build, I'll change it back today :)
Putting this inconsistency aside for a moment, how do I get jitrino
to build in debug?
Here it is: http://tinyurl.com/yxjp4v
This are patches for jitrino.xml build.bat, the same change (remove
-Dvm.jitrino.cfg=release) need to be done for build.sh as well.
k (I made the change in build.sh, as I never work on windows...). I'll
look at jitrino.xml (I can't see your URL... I'm in a car at the
moment...)
If it helps, then here is the copy:
=
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern
includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+compiler id=cpp.compiler extends=common.cpp.compiler
=
--
Thanks,
Alex
Re: [drlvm] building jitrino in release mode
It looks very strange to me. I've just checked linux debug build with the
only change in build.sh (replaced -Dvm.jitrino.cfg=releaase to -
Dvm.jitrino.cfg=debug) and debug version of library was built without any
problems.
On 11/6/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
Alex Astapchuk wrote:
Geir Magnusson Jr. wrote:
I've been having some problems getting some test cases to exhibit
misbehavior for DRLVM, and it turns out that jitrino is built in
release mode no matter what BUILD_CFG is set to.
Yes, this is a long-long story.
Was done as 'we-will-change-it-back-soon' thing, but remains till this
moment. :-)
When I get it to build, I'll change it back today :)
Putting this inconsistency aside for a moment, how do I get jitrino
to build in debug?
Here it is: http://tinyurl.com/yxjp4v
This are patches for jitrino.xml build.bat, the same change (remove
-Dvm.jitrino.cfg=release) need to be done for build.sh as well.
k (I made the change in build.sh, as I never work on windows...). I'll
look at jitrino.xml (I can't see your URL... I'm in a car at the
moment...)
If it helps, then here is the copy:
=
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+compiler id=cpp.compiler extends=common.cpp.compiler
=
--
Thanks,
Alex
--
Mikhail Fursov
Re: [drlvm] building jitrino in release mode
That's distressing. I usually throw in a build clean every now and then - I'm almost sure I did it early yesterday or sat at the earliest and did a full build, so whatever I committed in the last two days is problematic. Not clear what though... geir Robin Garner wrote: I've been having some problems getting some test cases to exhibit misbehavior for DRLVM, and it turns out that jitrino is built in release mode no matter what BUILD_CFG is set to. Putting this inconsistency aside for a moment, how do I get jitrino to build in debug? I tried changing the setting in build.sh for -Dvm.jitrino.cfg from 'release' to 'debug', but then DRLVM doesn't build on Ubunutu 6 with gcc 3.4.6. There's some linker problem. Can anyone duplicate this (or have it build successfully in debug)? geir That wouldn't be this problem, would it ? build.native.link: [cc] 0 total files to be compiled. [cc] Starting link [cc] `.L217' referenced in section `.rodata' of ../_obj/jit_generic_rt_support_ia32.o: defined in discarded section `.gnu.linkonce.t._ZN8Imm_OpndC1E9Opnd_Sizei' of ../_obj/jit_generic_rt_support_ia32.o [cc] `.L220' referenced in section `.rodata' of ../_obj/jit_generic_rt_support_ia32.o: defined in discarded section `.gnu.linkonce.t._ZN8Imm_OpndC1E9Opnd_Sizei' of ../_obj/jit_generic_rt_support_ia32.o [snip] [cc] `.L46' referenced in section `.rodata' of /home/robing/tmp/harmony/harmony/working_vm/build/lnx_ia32_gcc_debug/semis/vm/jthread/_bin/libjthread.a(thread_helpers.o): defined in discarded section `.gnu.linkonce.t._ZN8Imm_OpndC1E9Opnd_Sizei' of /home/robing/tmp/harmony/harmony/working_vm/build/lnx_ia32_gcc_debug/semis/vm/jthread/_bin/libjthread.a(thread_helpers.o) [cc] collect2: ld returned 1 exit status -- In which case it's happening without the 'debug' setting, and I'd appreciate some help too. :) robin
Re: [drlvm] building jitrino in release mode
Alex Astapchuk wrote: Geir Magnusson Jr. wrote: I've been having some problems getting some test cases to exhibit misbehavior for DRLVM, and it turns out that jitrino is built in release mode no matter what BUILD_CFG is set to. Yes, this is a long-long story. Was done as 'we-will-change-it-back-soon' thing, but remains till this moment. :-) When I get it to build, I'll change it back today :) Putting this inconsistency aside for a moment, how do I get jitrino to build in debug? Here it is: http://tinyurl.com/yxjp4v This are patches for jitrino.xml build.bat, the same change (remove -Dvm.jitrino.cfg=release) need to be done for build.sh as well. k (I made the change in build.sh, as I never work on windows...). I'll look at jitrino.xml (I can't see your URL... I'm in a car at the moment...) thx geir
Re: [drlvm] building jitrino in release mode
Geir Magnusson Jr. wrote:
Alex Astapchuk wrote:
Geir Magnusson Jr. wrote:
I've been having some problems getting some test cases to exhibit
misbehavior for DRLVM, and it turns out that jitrino is built in
release mode no matter what BUILD_CFG is set to.
Yes, this is a long-long story.
Was done as 'we-will-change-it-back-soon' thing, but remains till this
moment. :-)
When I get it to build, I'll change it back today :)
Putting this inconsistency aside for a moment, how do I get jitrino
to build in debug?
Here it is: http://tinyurl.com/yxjp4v
This are patches for jitrino.xml build.bat, the same change (remove
-Dvm.jitrino.cfg=release) need to be done for build.sh as well.
k (I made the change in build.sh, as I never work on windows...). I'll
look at jitrino.xml (I can't see your URL... I'm in a car at the moment...)
If it helps, then here is the copy:
=
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+compiler id=cpp.compiler extends=common.cpp.compiler
=
--
Thanks,
Alex
[drlvm] building jitrino in release mode
I've been having some problems getting some test cases to exhibit misbehavior for DRLVM, and it turns out that jitrino is built in release mode no matter what BUILD_CFG is set to. Putting this inconsistency aside for a moment, how do I get jitrino to build in debug? I tried changing the setting in build.sh for -Dvm.jitrino.cfg from 'release' to 'debug', but then DRLVM doesn't build on Ubunutu 6 with gcc 3.4.6. There's some linker problem. Can anyone duplicate this (or have it build successfully in debug)? geir
Re: [drlvm] building jitrino in release mode
Geir, I always build it in debug on Windows and every time on Linux (gcc3.3.3, SUSE) before sending a patch. I'l try to reproduce your problems, as soon as I have connect to my Linux PC. On 11/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I've been having some problems getting some test cases to exhibit misbehavior for DRLVM, and it turns out that jitrino is built in release mode no matter what BUILD_CFG is set to. Putting this inconsistency aside for a moment, how do I get jitrino to build in debug? I tried changing the setting in build.sh for -Dvm.jitrino.cfg from 'release' to 'debug', but then DRLVM doesn't build on Ubunutu 6 with gcc 3.4.6. There's some linker problem. Can anyone duplicate this (or have it build successfully in debug)? geir -- Mikhail Fursov
Re: [drlvm] building jitrino in release mode
I've been having some problems getting some test cases to exhibit misbehavior for DRLVM, and it turns out that jitrino is built in release mode no matter what BUILD_CFG is set to. Putting this inconsistency aside for a moment, how do I get jitrino to build in debug? I tried changing the setting in build.sh for -Dvm.jitrino.cfg from 'release' to 'debug', but then DRLVM doesn't build on Ubunutu 6 with gcc 3.4.6. There's some linker problem. Can anyone duplicate this (or have it build successfully in debug)? geir That wouldn't be this problem, would it ? build.native.link: [cc] 0 total files to be compiled. [cc] Starting link [cc] `.L217' referenced in section `.rodata' of ../_obj/jit_generic_rt_support_ia32.o: defined in discarded section `.gnu.linkonce.t._ZN8Imm_OpndC1E9Opnd_Sizei' of ../_obj/jit_generic_rt_support_ia32.o [cc] `.L220' referenced in section `.rodata' of ../_obj/jit_generic_rt_support_ia32.o: defined in discarded section `.gnu.linkonce.t._ZN8Imm_OpndC1E9Opnd_Sizei' of ../_obj/jit_generic_rt_support_ia32.o [snip] [cc] `.L46' referenced in section `.rodata' of /home/robing/tmp/harmony/harmony/working_vm/build/lnx_ia32_gcc_debug/semis/vm/jthread/_bin/libjthread.a(thread_helpers.o): defined in discarded section `.gnu.linkonce.t._ZN8Imm_OpndC1E9Opnd_Sizei' of /home/robing/tmp/harmony/harmony/working_vm/build/lnx_ia32_gcc_debug/semis/vm/jthread/_bin/libjthread.a(thread_helpers.o) [cc] collect2: ld returned 1 exit status -- In which case it's happening without the 'debug' setting, and I'd appreciate some help too. :) robin
Re: [drlvm] building jitrino in release mode
Geir Magnusson Jr. wrote: I've been having some problems getting some test cases to exhibit misbehavior for DRLVM, and it turns out that jitrino is built in release mode no matter what BUILD_CFG is set to. Yes, this is a long-long story. Was done as 'we-will-change-it-back-soon' thing, but remains till this moment. :-) Putting this inconsistency aside for a moment, how do I get jitrino to build in debug? Here it is: http://tinyurl.com/yxjp4v This are patches for jitrino.xml build.bat, the same change (remove -Dvm.jitrino.cfg=release) need to be done for build.sh as well. -- Thanks, Alex I tried changing the setting in build.sh for -Dvm.jitrino.cfg from 'release' to 'debug', but then DRLVM doesn't build on Ubunutu 6 with gcc 3.4.6. There's some linker problem. Can anyone duplicate this (or have it build successfully in debug)? geir
Re: [DRLVM] building from svn on FC5
type $ gcc --version $ g++ --version What versions are reported? Naveen Neelakantam wrote: Hello Geir, I downloaded a fresh copy of harmony from svn and got the same error. To be clear, these were my steps: svn checkout https://svn.apache.org/repos/asf/incubator/harmony cd harmony/enhanced/drlvm/trunk/build chmod +x build.sh ./build.sh update ./build.sh And then I got the same error that I listed in my previous email: build.native.cpp: [cc] 141 total files to be compiled. [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' Previous threads led me to believe that this issue was resolved in JIRA. Mark then committed the changes into svn, and things worked for a while. Thanks, Naveen On Jun 22, 2006, at 3:19 PM, Geir Magnusson Jr wrote: Odd. Nothing should have changed re log4cxx Sure nothing else changed? geir [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn on FC5, and it has a build error that I've seen before. This issue was resolved when I was using r413745, but now I am using r416471 and it is back. The error is below: Thanks, Naveen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] building from svn on FC5
They are the default Fedora Core 5 compiler versions (which I mentioned before, but neglected to post again. sorry). ie. 4.1.0 20060304 (Red Hat 4.1.0-3). Thanks, Naveen On Jun 23, 2006, at 4:47 AM, Geir Magnusson Jr wrote: type $ gcc --version $ g++ --version What versions are reported? Naveen Neelakantam wrote: Hello Geir, I downloaded a fresh copy of harmony from svn and got the same error. To be clear, these were my steps: svn checkout https://svn.apache.org/repos/asf/incubator/harmony cd harmony/enhanced/drlvm/trunk/build chmod +x build.sh ./build.sh update ./build.sh And then I got the same error that I listed in my previous email: build.native.cpp: [cc] 141 total files to be compiled. [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/ domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/ domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' Previous threads led me to believe that this issue was resolved in JIRA. Mark then committed the changes into svn, and things worked for a while. Thanks, Naveen On Jun 22, 2006, at 3:19 PM, Geir Magnusson Jr wrote: Odd. Nothing should have changed re log4cxx Sure nothing else changed? geir [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn on FC5, and it has a build error that I've seen before. This issue was resolved when I was using r413745, but now I am using r416471 and it is back. The error is below: Thanks, Naveen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] building from svn on FC5
This issue has been fixed in log4cxx: http://issues.apache.org/jira/ browser/LOGCXX-130. Specifically, the fix was applied in r384272 of log4cxx. I did some digging around, and patched versions of domconfigurator.h and unicodehelper.h are contained in drlvm/trunk/build/patches/common/ LOG4CXX/include/log4cxx. If I copy these files over to the drlvm/ trunk/build/lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/ log4cxx directory, everything builds. Maybe that helps narrow down the cause of the problem? Naveen On Jun 23, 2006, at 8:55 AM, Naveen Neelakantam wrote: They are the default Fedora Core 5 compiler versions (which I mentioned before, but neglected to post again. sorry). ie. 4.1.0 20060304 (Red Hat 4.1.0-3). Thanks, Naveen On Jun 23, 2006, at 4:47 AM, Geir Magnusson Jr wrote: type $ gcc --version $ g++ --version What versions are reported? Naveen Neelakantam wrote: Hello Geir, I downloaded a fresh copy of harmony from svn and got the same error. To be clear, these were my steps: svn checkout https://svn.apache.org/repos/asf/incubator/harmony cd harmony/enhanced/drlvm/trunk/build chmod +x build.sh ./build.sh update ./build.sh And then I got the same error that I listed in my previous email: build.native.cpp: [cc] 141 total files to be compiled. [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/ domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/ domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' Previous threads led me to believe that this issue was resolved in JIRA. Mark then committed the changes into svn, and things worked for a while. Thanks, Naveen On Jun 22, 2006, at 3:19 PM, Geir Magnusson Jr wrote: Odd. Nothing should have changed re log4cxx Sure nothing else changed? geir [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn on FC5, and it has a build error that I've seen before. This issue was resolved when I was using r413745, but now I am using r416471 and it is back. The error is below: Thanks, Naveen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] building from svn on FC5
On 6/23/06, Naveen Neelakantam [EMAIL PROTECTED] wrote: This issue has been fixed in log4cxx: http://issues.apache.org/jira/ browser/LOGCXX-130. Specifically, the fix was applied in r384272 of log4cxx. I did some digging around, and patched versions of domconfigurator.h and unicodehelper.h are contained in drlvm/trunk/build/patches/common/ LOG4CXX/include/log4cxx. If I copy these files over to the drlvm/ trunk/build/lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/ log4cxx directory, everything builds. The drlvm/trunk/build/patches directory is used to store the patches to the external libs like LOG4CXX. The contents of the patches dir is automatically copied into the external sources tree by the build before compilation. Therefore, you may have the situation than the outdated versions of unicodehelper.h or domconfigurator.h in the patches directory just replace the newer versions obtained from SVN. If the latest versions of domconfigurator.h/unicodehelper.h are just right, their patched versions just can be removed from the drlvm build. Thanks, Andrey. Maybe that helps narrow down the cause of the problem? Naveen On Jun 23, 2006, at 8:55 AM, Naveen Neelakantam wrote: They are the default Fedora Core 5 compiler versions (which I mentioned before, but neglected to post again. sorry). ie. 4.1.0 20060304 (Red Hat 4.1.0-3). Thanks, Naveen On Jun 23, 2006, at 4:47 AM, Geir Magnusson Jr wrote: type $ gcc --version $ g++ --version What versions are reported? Naveen Neelakantam wrote: Hello Geir, I downloaded a fresh copy of harmony from svn and got the same error. To be clear, these were my steps: svn checkout https://svn.apache.org/repos/asf/incubator/harmony cd harmony/enhanced/drlvm/trunk/build chmod +x build.sh ./build.sh update ./build.sh And then I got the same error that I listed in my previous email: build.native.cpp: [cc] 141 total files to be compiled. [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/ domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/ domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' Previous threads led me to believe that this issue was resolved in JIRA. Mark then committed the changes into svn, and things worked for a while. Thanks, Naveen On Jun 22, 2006, at 3:19 PM, Geir Magnusson Jr wrote: Odd. Nothing should have changed re log4cxx Sure nothing else changed? geir [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn on FC5, and it has a build error that I've seen before. This issue was resolved when I was using r413745, but now I am using r416471 and it is back. The error is below: Thanks, Naveen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] building from svn on FC5
On Friday 23 June 2006 19:55 Naveen Neelakantam wrote: They are the default Fedora Core 5 compiler versions (which I mentioned before, but neglected to post again. sorry). ie. 4.1.0 20060304 (Red Hat 4.1.0-3). I've installed gcc-4.1.1 on gentoo and got the same errors. It is probably one more move of gcc towards stricter C++ syntax interpretation. I didn't want to figure out how to fix it, instead I just removed -r 365029 from remote.LOG4CXX.archive URL in lnx.properties to see if the problem with log4cxx was already fixed in their svn. I've removed build/pre-copied/common/LOG4CXX, did another build.sh update and the ran build again. Voila, it worked! So the problem with log4cxx is already fixed upstream in svn. I've ran build.sh test, I've tried to run specjvm98 with -Xtrace:classloader just to test logging and got the same results as yesterday. So it seems that logger is ok. If you think this deserves JIRA I can certainly create one. But since I've just deleted revision switch for svn to download the latest log4cxx at some moment we may get regression instead of improvement. The revision which worked for me is 416779. Maybe we can temporarily switch to it. Certainly it is better to use releases which are already installed in the system. On Jun 23, 2006, at 4:47 AM, Geir Magnusson Jr wrote: type $ gcc --version $ g++ --version What versions are reported? Naveen Neelakantam wrote: Hello Geir, I downloaded a fresh copy of harmony from svn and got the same error. To be clear, these were my steps: svn checkout https://svn.apache.org/repos/asf/incubator/harmony cd harmony/enhanced/drlvm/trunk/build chmod +x build.sh ./build.sh update ./build.sh And then I got the same error that I listed in my previous email: build.native.cpp: [cc] 141 total files to be compiled. [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/ domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/ domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' Previous threads led me to believe that this issue was resolved in JIRA. Mark then committed the changes into svn, and things worked for a while. Thanks, Naveen On Jun 22, 2006, at 3:19 PM, Geir Magnusson Jr wrote: Odd. Nothing should have changed re log4cxx Sure nothing else changed? geir [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn on FC5, and it has a build error that I've seen before. This issue was resolved when I was using r413745, but now I am using r416471 and it is back. The error is below: Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] building from svn on FC5
I think Harmony should use a fixed revision when pulling from svn, but clearly r365029 is missing some fixes we'd like (or at least I would like). I don't know if this necessitates a JIRA, but I'd like to see the issue resolved in the svn head. Thanks, Naveen On Jun 23, 2006, at 11:13 AM, Gregory Shimansky wrote: On Friday 23 June 2006 19:55 Naveen Neelakantam wrote: They are the default Fedora Core 5 compiler versions (which I mentioned before, but neglected to post again. sorry). ie. 4.1.0 20060304 (Red Hat 4.1.0-3). I've installed gcc-4.1.1 on gentoo and got the same errors. It is probably one more move of gcc towards stricter C++ syntax interpretation. I didn't want to figure out how to fix it, instead I just removed - r 365029 from remote.LOG4CXX.archive URL in lnx.properties to see if the problem with log4cxx was already fixed in their svn. I've removed build/pre-copied/common/LOG4CXX, did another build.sh update and the ran build again. Voila, it worked! So the problem with log4cxx is already fixed upstream in svn. I've ran build.sh test, I've tried to run specjvm98 with -Xtrace:classloader just to test logging and got the same results as yesterday. So it seems that logger is ok. If you think this deserves JIRA I can certainly create one. But since I've just deleted revision switch for svn to download the latest log4cxx at some moment we may get regression instead of improvement. The revision which worked for me is 416779. Maybe we can temporarily switch to it. Certainly it is better to use releases which are already installed in the system. On Jun 23, 2006, at 4:47 AM, Geir Magnusson Jr wrote: type $ gcc --version $ g++ --version What versions are reported? Naveen Neelakantam wrote: Hello Geir, I downloaded a fresh copy of harmony from svn and got the same error. To be clear, these were my steps: svn checkout https://svn.apache.org/repos/asf/incubator/harmony cd harmony/enhanced/drlvm/trunk/build chmod +x build.sh ./build.sh update ./build.sh And then I got the same error that I listed in my previous email: build.native.cpp: [cc] 141 total files to be compiled. [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/ domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/xml/ domconfigurator.h:243: error: extra qualification 'log4cxx::xml::DOMConfigurator::' on member 'subst' [cc] /work/nneelaka/Sandbox/harmony/enhanced/drlvm/trunk/build/ lnx_ia32_gcc_release/semis/extra/log4cxx/src/include/log4cxx/ helpers/unicodehelper.h:98: error: extra qualification 'log4cxx::helpers::UnicodeHelper::' on member 'lengthUTF8' Previous threads led me to believe that this issue was resolved in JIRA. Mark then committed the changes into svn, and things worked for a while. Thanks, Naveen On Jun 22, 2006, at 3:19 PM, Geir Magnusson Jr wrote: Odd. Nothing should have changed re log4cxx Sure nothing else changed? geir [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn on FC5, and it has a build error that I've seen before. This issue was resolved when I was using r413745, but now I am using r416471 and it is back. The error is below: Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] building from svn on FC5
On 23 June 2006 at 22:13, Gregory Shimansky [EMAIL PROTECTED] wrote: If you think this deserves JIRA I can certainly create one. But since I've just deleted revision switch for svn to download the latest log4cxx at some moment we may get regression instead of improvement. The revision which worked for me is 416779. Maybe we can temporarily switch to it. I've fixed (in r416807) the revisions for log4cxx on linux and windows to use r416779. Works for me on Linux. Can some test on windows and report if this causes any regression? -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] building from svn on FC5
Works for me on FC5 too. Thanks Mark! Naveen On Jun 23, 2006, at 12:52 PM, Mark Hindess wrote: On 23 June 2006 at 22:13, Gregory Shimansky [EMAIL PROTECTED] wrote: If you think this deserves JIRA I can certainly create one. But since I've just deleted revision switch for svn to download the latest log4cxx at some moment we may get regression instead of improvement. The revision which worked for me is 416779. Maybe we can temporarily switch to it. I've fixed (in r416807) the revisions for log4cxx on linux and windows to use r416779. Works for me on Linux. Can some test on windows and report if this causes any regression? -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] building from svn on FC5
I just tried building DRLVM out of svn on FC5, and it has a build error that I've seen before. This issue was resolved when I was using r413745, but now I am using r416471 and it is back. The error is below: Thanks, Naveen build.native.cpp: [cc] Starting dependency analysis for 136 files. [cc] 136 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 5 total files to be compiled. [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/xml/domconfigurat or.h:243: error: extra qualification ? log4cxx::xml::DOMConfigurator::? on member ?subst? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/xml/domconfigurat or.h:243: error: extra qualification ? log4cxx::xml::DOMConfigurator::? on member ?subst? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? On 6/10/06, Mark Hindess [EMAIL PROTECTED] wrote: On 10 June 2006 at 0:03, Naveen Neelakantam [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn. I am running Fedora Core 5 with gcc version 4.1.0 20060304 (Red Hat 4.1.0-3). However, I am getting the build error shown below. Previous posts on the dev list led me to believe that this issue had been resolved. Did a patch get lost in the transition to svn? Hi Naveen, I'm still testing the latest version of Ivan's patch mentioned in the message below, so it is not committed in svn yet. (I hope to finish testing it today or tomorrow.) But I don't see a JIRA with Vladimir's fixes for FC5 so I don't think this will help you. Vladimir, can you create a new JIRA with your additional changes (on top of Ivan's patch or on drlvm/trunk if I've committed Ivan's patch by the time you read this.) Regards, Mark. Thanks, Naveen On May 19, 2006, at 12:57 AM, Vladimir Gorr wrote: Small changes are required to fix the build issue for Fedora 5. I've prepared this patch and I'm ready to put it into JIRA. There are two ways to make this thing: - renew the cumulative patch created by Ivan (see JIRA issue below); - attach these changes as separate patch and adding it to the HARMONY-443. What way is more preferable? Thanks, Vladimir. On 5/5/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: The updated patch DRLVM-GCC-3.4_and_4.x- cumulative.patch is now in Harmony-443 JIRA with detailed instructions. http://issues.apache.org/jira/browse/HARMONY-443 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] building from svn on FC5
Odd. Nothing should have changed re log4cxx Sure nothing else changed? geir [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn on FC5, and it has a build error that I've seen before. This issue was resolved when I was using r413745, but now I am using r416471 and it is back. The error is below: Thanks, Naveen build.native.cpp: [cc] Starting dependency analysis for 136 files. [cc] 136 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 5 total files to be compiled. [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/xml/domconfigurat or.h:243: error: extra qualification ? log4cxx::xml::DOMConfigurator::? on member ?subst? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/xml/domconfigurat or.h:243: error: extra qualification ? log4cxx::xml::DOMConfigurator::? on member ?subst? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? On 6/10/06, Mark Hindess [EMAIL PROTECTED] wrote: On 10 June 2006 at 0:03, Naveen Neelakantam [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn. I am running Fedora Core 5 with gcc version 4.1.0 20060304 (Red Hat 4.1.0-3). However, I am getting the build error shown below. Previous posts on the dev list led me to believe that this issue had been resolved. Did a patch get lost in the transition to svn? Hi Naveen, I'm still testing the latest version of Ivan's patch mentioned in the message below, so it is not committed in svn yet. (I hope to finish testing it today or tomorrow.) But I don't see a JIRA with Vladimir's fixes for FC5 so I don't think this will help you. Vladimir, can you create a new JIRA with your additional changes (on top of Ivan's patch or on drlvm/trunk if I've committed Ivan's patch by the time you read this.) Regards, Mark. Thanks, Naveen On May 19, 2006, at 12:57 AM, Vladimir Gorr wrote: Small changes are required to fix the build issue for Fedora 5. I've prepared this patch and I'm ready to put it into JIRA. There are two ways to make this thing: - renew the cumulative patch created by Ivan (see JIRA issue below); - attach these changes as separate patch and adding it to the HARMONY-443. What way is more preferable? Thanks, Vladimir. On 5/5/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: The updated patch DRLVM-GCC-3.4_and_4.x- cumulative.patch is now in Harmony-443 JIRA with detailed instructions. http://issues.apache.org/jira/browse/HARMONY-443 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] building...
Garrett Rooney wrote: SNIP Now sometimes you do need to have a totally different implementation for a new platform, but a lot of the time, there can be some minor ifdefs (based on availability of FEATURES, not platform) that allow the same file to work on multiple platforms. Just splitting up into two implementations (or really N implementations, since eventually Harmony will run on more than just Linux and Windows) is a bit of a waste, and ifdefing based on platform is just as bad, since the stuff that works on FreeBSD or OpenBSD or Solaris is often the same as the stuff that works on Linux... What we ended up with in APR is something like this: There's a base implementation of each file that is designed to work on any unix system. These go in unix/ subdirectories. If it's feasable to make that file work elsewhere (Netware, Windows, OS/2, BeOS, whatever) then it's done via ifdefs. If the ifdefs get out of control, or the platform is really that different then you start splitting off into platform specific implementations, but that's a last resort. We actually had some discussion about doing exactly that kind of thing a while back [1] and more recently [2]. The basic ideas were: - Make the code as shared as possible, by using IFDEFs where it makes sense. We've made some progress in this area, with a lot of our code shared, but as you say there is still more to do. Im working on moving the native code around at the moment, so more unification is probably something I will look at at the same time. - Where IFDEFs are starting to make the code difficult to read, split the source up into platform specific files. The kind of layout that could be used for this is described in [2]. I think this matches what you're describing for APR. Do you agree? Im interested to know what kind of build system is used in APR - previous suggestions for picking up platform specific code have included using clever Ant scripts to figure out which file versions are needed, or using gmake and its vpath variable to pick them up (they are described more extensively in [1]). What does APR use to deal with building platform specific versions of files over shared ones? So in the end, the main things to keep in mind are to make your unix implemenation try to work across as many systems as possible, ifdefing based on availability of features as much as you can, not based on specific platforms, and only as a last resort split out into totally different platform specific implementations. IIRC Mark suggested ifdef'ing on features as opposed to platforms before [3], and it seems like a good idea to me, providing a more obvious reason for the existence of the ifdef and allowing us to use ifdefs that describe more than just a ballpark platform distinction. I think in general we have similar ideas to those you describe, but we're not at a point yet where they have been completely embodied in the codebase, or even summarised in a single post/page. Perhaps I will put these ideas together into a page for the classlib section of the Harmony website, so we have something concrete to talk about without digging back into the mail archives. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [drlvm] building...
Answering Geir's question #3:
compiler, linker and define arguments are specified via compilerarg,
linkerarg, defineset tags respectively
in .xml subcomponents descriptors depending on OS, compiler, configuration.
You can find DRL VM subcomponent descriptors at
enhanced/drlvm/trunk/build/make/components/vm/*.xml
Here're some example extracts from jitrino.xml:
!-- linux specific --
select os=lnx
defineset define=PLATFORM_POSIX /
select cxx=gcc arch=ia32,em64t
compilerarg value=-msse2 /
/select
select cxx=gcc
compilerarg value=-fmessage-length=0 /
compilerarg value=-Wall /
compilerarg value=-Werror /
/select
compilerarg value=-x /
compilerarg value=c++ /
compilerarg value=-fPIC /
select cxx=icc
compilerarg value=-wd68 /
compilerarg value=-wd654 /
compilerarg value=-wd854 /
compilerarg value=-wd470 /
compilerarg value=-wd1572 /
compilerarg value=-wd1125 /
!--
# 470 - 'qualified name is not allowed in member
declaration'
# warning #1125: function xxx is hidden by yyy
- virtual function override intended
# warning #1572: floating-point equality and
inequality comparisons are unreliable
--
/select
select cfg=debug
compilerarg value=-g /
compilerarg value=-O0 /
/select
select cfg=release
compilerarg value=-O /
/select
/select
linker name=${build.cxx} id=linker
select os=win
select arch=ipf
linkerarg value=/MACHINE:IA64 /
/select
select arch=em64t
linkerarg value=/MACHINE:AMD64 /
/select
select arch=ia32
linkerarg value=/MACHINE:X86 /
/select
linkerarg value=/DLL /
linkerarg value=/SUBSYSTEM:WINDOWS /
linkerarg value=/DEBUG /
linkerarg value=/NOLOGO /
linkerarg value=/FIXED:NO /
linkerarg value=/OPT:REF /
linkerarg value=/OUT:${libdir}/ /
libset libs=${vm.vmcore.lib} dir=${vm.vmcore.libdir} /
libset libs=${vm.encoder.lib} dir=${vm.encoder.libdir}
/
/select
select os=lnx
linkerarg value=-shared /
linkerarg value=-ldl /
linkerarg value=-lm /
/select
/linker
--
Denis Sharypov,
Intel Middleware Products Division
Re: [drlvm] building...
Thanks - I figured that out.
It's an interesting difference from makefiles, as they tend to be more
explicit and local - I can go into a directory and look at the
makefile for the params used for building stuff local to that directory.
geir
Denis Sharypov wrote:
Answering Geir's question #3:
compiler, linker and define arguments are specified via compilerarg,
linkerarg, defineset tags respectively
in .xml subcomponents descriptors depending on OS, compiler, configuration.
You can find DRL VM subcomponent descriptors at
enhanced/drlvm/trunk/build/make/components/vm/*.xml
Here're some example extracts from jitrino.xml:
!-- linux specific --
select os=lnx
defineset define=PLATFORM_POSIX /
select cxx=gcc arch=ia32,em64t
compilerarg value=-msse2 /
/select
select cxx=gcc
compilerarg value=-fmessage-length=0 /
compilerarg value=-Wall /
compilerarg value=-Werror /
/select
compilerarg value=-x /
compilerarg value=c++ /
compilerarg value=-fPIC /
select cxx=icc
compilerarg value=-wd68 /
compilerarg value=-wd654 /
compilerarg value=-wd854 /
compilerarg value=-wd470 /
compilerarg value=-wd1572 /
compilerarg value=-wd1125 /
!--
# 470 - 'qualified name is not allowed in member
declaration'
# warning #1125: function xxx is hidden by yyy
- virtual function override intended
# warning #1572: floating-point equality and
inequality comparisons are unreliable
--
/select
select cfg=debug
compilerarg value=-g /
compilerarg value=-O0 /
/select
select cfg=release
compilerarg value=-O /
/select
/select
linker name=${build.cxx} id=linker
select os=win
select arch=ipf
linkerarg value=/MACHINE:IA64 /
/select
select arch=em64t
linkerarg value=/MACHINE:AMD64 /
/select
select arch=ia32
linkerarg value=/MACHINE:X86 /
/select
linkerarg value=/DLL /
linkerarg value=/SUBSYSTEM:WINDOWS /
linkerarg value=/DEBUG /
linkerarg value=/NOLOGO /
linkerarg value=/FIXED:NO /
linkerarg value=/OPT:REF /
linkerarg value=/OUT:${libdir}/ /
libset libs=${vm.vmcore.lib} dir=${vm.vmcore.libdir} /
libset libs=${vm.encoder.lib} dir=${vm.encoder.libdir}
/
/select
select os=lnx
linkerarg value=-shared /
linkerarg value=-ldl /
linkerarg value=-lm /
/select
/linker
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] building...
On 6/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Thanks - I figured that out. It's an interesting difference from makefiles, as they tend to be more explicit and local - I can go into a directory and look at the makefile for the params used for building stuff local to that directory. Yeah, when I was trying to disect the vm build when it was first released I had similar problems. I wanted to run some of the build commands by hand to see a particular error without running the whole build, but it was very difficult to tell what the final string of arguments were, and once I had them it was difficult to tell what I would have to change to alter them. The other major problem was that when build problems occurred, compiles didn't stop. So if one file blows up because of an issue, the set of warnings in it immediately scroll off the screen and are replaced by hundreds more. On make based systems I'm used to it would stop after the first file, which is much more approachable when debugging. -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
