Re: [x86_64] builds! now onto the tests
On the 0x222 day of Apache Harmony Gregory Shimansky wrote: > Stefano Mazzocchi wrote: > > Gregory Shimansky wrote: > >> Stefano Mazzocchi wrote: > >>> I'm happy to report that both classlib and drlvm at r474892 build on > >>> x86_64/em64t > >>> > >>> As Gregory suggested, I had to change the symlinks to from > >>> /usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the > >>> link to avoid complaining. > >> Well Geir insists that we should know what we are linking against, so he > >> prefers static libraries. I don't like it very much (it is contrary to > >> Gentoo way :) which is to link against anything which is installed on > >> the system by the user) but I can understand this POV. > >> > >> The problem is that on many distributions static libs are built without > >> -fPIC and while on x86 it may still work ok, on x86_64 it definitely > >> doesn't work. So if we decide that we should use static linking we'll > >> have to check in prebuilt the binaries into classlib source tree just > >> like we did with ICU (although ICU libraries are dynamic, not shared). I > >> see no other way to do static linking. > > I see. I wouldn't mind that. Both libpng and libjpeg seem to have an > > apache-compatible license. > > We already fetch java binary dependencies, it's not unreasonable to > > have > > a OS/CPU-based fetching of native statically built binaries as well > > since they are not going to change that much anyway over time. > > I don't know where we can fetch static libraries built with -fPIC > since no one does that. Probably this is the way configure scripts > configure the flags for building static libs. Alternative solution could be to link dynamically, but against downloaded libs (not the libs the system). If somebody is eager to use the Gentoo way, s/he makes a link. > We'll have to build the binaries ourself and store them somewhere (in SVN?). -- Egor Pasko
Re: [x86_64] builds! now onto the tests
Stefano, Regarding your original problem: [javac] The type junit.framework.TestCase cannot be resolved. It is indirectly referenced from required .class files To fix that you need to copy junit.jar into /lib directory. Thanks Evgueni On 11/15/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Gregory Shimansky wrote: > Stefano Mazzocchi wrote: >> I'm happy to report that both classlib and drlvm at r474892 build on >> x86_64/em64t >> >> As Gregory suggested, I had to change the symlinks to from >> /usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the >> link to avoid complaining. > > Well Geir insists that we should know what we are linking against, so he > prefers static libraries. I don't like it very much (it is contrary to > Gentoo way :) which is to link against anything which is installed on > the system by the user) but I can understand this POV. I'm happy to go with convention, but always worried about uncertainty and randomness. Remember Armand's problems due to a the threading library? geir
Re: [x86_64] builds! now onto the tests
Gregory Shimansky wrote: Stefano Mazzocchi wrote: I'm happy to report that both classlib and drlvm at r474892 build on x86_64/em64t As Gregory suggested, I had to change the symlinks to from /usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the link to avoid complaining. Well Geir insists that we should know what we are linking against, so he prefers static libraries. I don't like it very much (it is contrary to Gentoo way :) which is to link against anything which is installed on the system by the user) but I can understand this POV. I'm happy to go with convention, but always worried about uncertainty and randomness. Remember Armand's problems due to a the threading library? geir
Re: [x86_64] builds! now onto the tests
Stefano Mazzocchi wrote:
I'm happy to report that both classlib and drlvm at r474892 build on
x86_64/em64t
As Gregory suggested, I had to change the symlinks to from
/usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the
link to avoid complaining.
Bleah. This can't be the final solution to this...
It would be great if somebody could fix the build and do that
automatically (or tell me where to do it).
Now, I've tried "ant test" in classlib and I get
compile-tests:
[echo] Compiling ACCESSIBILITY tests
[javac] Compiling 8 source files to
/home/stefano/src/harmony/classlib/modules/accessibility/bin/test
[javac] Since fork is false, ignoring memoryMaximumSize setting
[javac] --
[javac] 1. ERROR in
/home/stefano/src/harmony/classlib/modules/accessibility/src/test/api/java/common/javax/accessibility/AccessibleBundleTest.java
[javac] (at line 27)
[javac] public class AccessibleBundleTest extends
BasicSwingTestCase {
[javac] ^^
[javac] The type junit.framework.TestCase cannot be resolved. It is
indirectly referenced from required .class files
[javac] --
[javac] 1 problem (1 error)
which is pretty weird since junit was already fetched.
Am I the only one seeing this?
Re: [x86_64] builds! now onto the tests
Stefano Mazzocchi wrote: Gregory Shimansky wrote: Stefano Mazzocchi wrote: I'm happy to report that both classlib and drlvm at r474892 build on x86_64/em64t As Gregory suggested, I had to change the symlinks to from /usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the link to avoid complaining. Well Geir insists that we should know what we are linking against, so he prefers static libraries. I don't like it very much (it is contrary to Gentoo way :) which is to link against anything which is installed on the system by the user) but I can understand this POV. The problem is that on many distributions static libs are built without -fPIC and while on x86 it may still work ok, on x86_64 it definitely doesn't work. So if we decide that we should use static linking we'll have to check in prebuilt the binaries into classlib source tree just like we did with ICU (although ICU libraries are dynamic, not shared). I see no other way to do static linking. I see. I wouldn't mind that. Both libpng and libjpeg seem to have an apache-compatible license. We already fetch java binary dependencies, it's not unreasonable to have a OS/CPU-based fetching of native statically built binaries as well since they are not going to change that much anyway over time. I don't know where we can fetch static libraries built with -fPIC since no one does that. Probably this is the way configure scripts configure the flags for building static libs. We'll have to build the binaries ourself and store them somewhere (in SVN?). -- Gregory
Re: [x86_64] builds! now onto the tests
Gregory Shimansky wrote:
> Stefano Mazzocchi wrote:
>> I'm happy to report that both classlib and drlvm at r474892 build on
>> x86_64/em64t
>>
>> As Gregory suggested, I had to change the symlinks to from
>> /usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the
>> link to avoid complaining.
>
> Well Geir insists that we should know what we are linking against, so he
> prefers static libraries. I don't like it very much (it is contrary to
> Gentoo way :) which is to link against anything which is installed on
> the system by the user) but I can understand this POV.
>
> The problem is that on many distributions static libs are built without
> -fPIC and while on x86 it may still work ok, on x86_64 it definitely
> doesn't work. So if we decide that we should use static linking we'll
> have to check in prebuilt the binaries into classlib source tree just
> like we did with ICU (although ICU libraries are dynamic, not shared). I
> see no other way to do static linking.
I see. I wouldn't mind that. Both libpng and libjpeg seem to have an
apache-compatible license.
We already fetch java binary dependencies, it's not unreasonable to have
a OS/CPU-based fetching of native statically built binaries as well
since they are not going to change that much anyway over time.
>> It would be great if somebody could fix the build and do that
>> automatically (or tell me where to do it).
>>
>> Now, I've tried "ant test" in classlib and I get
>>
>> compile-tests:
>> [echo] Compiling ACCESSIBILITY tests
>> [javac] Compiling 8 source files to
>> /home/stefano/src/harmony/classlib/modules/accessibility/bin/test
>> [javac] Since fork is false, ignoring memoryMaximumSize setting
>> [javac] --
>> [javac] 1. ERROR in
>> /home/stefano/src/harmony/classlib/modules/accessibility/src/test/api/java/common/javax/accessibility/AccessibleBundleTest.java
>>
>> [javac] (at line 27)
>> [javac] public class AccessibleBundleTest extends
>> BasicSwingTestCase {
>> [javac]
>> ^^
>> [javac] The type junit.framework.TestCase cannot be resolved. It is
>> indirectly referenced from required .class files
>> [javac] --
>> [javac] 1 problem (1 error)
>>
>> which is pretty weird since junit was already fetched.
>>
>> Am I the only one seeing this?
>>
>
>
--
Stefano.
Re: [x86_64] builds! now onto the tests
Stefano Mazzocchi wrote:
I'm happy to report that both classlib and drlvm at r474892 build on
x86_64/em64t
As Gregory suggested, I had to change the symlinks to from
/usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the
link to avoid complaining.
Well Geir insists that we should know what we are linking against, so he
prefers static libraries. I don't like it very much (it is contrary to
Gentoo way :) which is to link against anything which is installed on
the system by the user) but I can understand this POV.
The problem is that on many distributions static libs are built without
-fPIC and while on x86 it may still work ok, on x86_64 it definitely
doesn't work. So if we decide that we should use static linking we'll
have to check in prebuilt the binaries into classlib source tree just
like we did with ICU (although ICU libraries are dynamic, not shared). I
see no other way to do static linking.
It would be great if somebody could fix the build and do that
automatically (or tell me where to do it).
Now, I've tried "ant test" in classlib and I get
compile-tests:
[echo] Compiling ACCESSIBILITY tests
[javac] Compiling 8 source files to
/home/stefano/src/harmony/classlib/modules/accessibility/bin/test
[javac] Since fork is false, ignoring memoryMaximumSize setting
[javac] --
[javac] 1. ERROR in
/home/stefano/src/harmony/classlib/modules/accessibility/src/test/api/java/common/javax/accessibility/AccessibleBundleTest.java
[javac] (at line 27)
[javac] public class AccessibleBundleTest extends
BasicSwingTestCase {
[javac] ^^
[javac] The type junit.framework.TestCase cannot be resolved. It is
indirectly referenced from required .class files
[javac] --
[javac] 1 problem (1 error)
which is pretty weird since junit was already fetched.
Am I the only one seeing this?
--
Gregory
