harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: [build] status
Date Wed, 19 Jul 2006 10:13:05 GMT
Can anybody say about the build status on Windows we have now?
Unfortunately, I cannot build for the recent sources due to the following
issue:

     [exec] winFont.obj : error LNK2019: unresolved external symbol "void
__cde
l throwNPException(struct JNIEnv_ *,char const *)" (
?throwNPException@@YAXPAUJN
Env_@@PBD@Z) referenced in function
_Java_org_apache_harmony_awt_gl_font_Native
ont_enumSystemFonts@8
     [exec] ..\fontlib.dll : fatal error LNK1120: 1 unresolved externals
     [exec] NMAKE : fatal error U1077: 'link' : return code '0x460'
     [exec] Stop.

Any ideas?

Thanks,
Vladimir.

On 7/19/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>
>
>
> Nathan Beyer wrote:
> >> -----Original Message-----
> >> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> >> Paulex Yang wrote:
> >>> I think Richard's patch is fine, i.e., specify a locale to the test,
> >>> what we want to test is toPattern()'s logic, not the locale data or
> >>> something, and the specified locale is OK to test the logic. And I
> also
> >>> think maybe one locale is not enough, so we may want to include some
> >>> more exceptional locale, say, en_UK in this case, by which, we can try
> >>> to follow RI as possible. Loose the test by removing the assertion
> here
> >>> is dangerous, just like any other cases without clear spec.
> >> I think what this proved to us is that our testing matrix must include
> >> WinXP en_US, en_UK, en_RU etc.
> >
> > Locale-sensitive testing is pragmatically only necessary on a small
> subset
> > of Harmony's modules (for example, text); this could be isolated to the
> > build scripts of those modules. A trivial implementation would be to
> setup a
> > list of locales to test, iterate the modules suite of tests for each
> locale
> > and set the default locale respective to the iteration.
>
> Sure, although I don't know how to flip locale programmatically from ant
> in windows :)
>
> I do know how to ask Tim, Stephan, Paulex and myself to run the same
> tests :)
>
> geir
>
> >
> > -Nathan
> >
> >> IOW, we want to run our test suite on as many locale's as possible, and
> >> have it pass on every one of them.  We may choose local-specific tests,
> >> btw, which is what I think you are suggesting.
> >>
> >> geir
> >>
> >>>
> >>> Geir Magnusson Jr wrote:
> >>>> What do you suggest then?
> >>>>
> >>>> Paulex Yang wrote:
> >>>>
> >>>>> Geir Magnusson Jr wrote:
> >>>>>
> >>>>>> Then I guess we just fix the test.
> >>>>>>
> >>>>> Agree, just think we should not "fix" the test by removing the
> >>>>> assertion.
> >>>>>
> >>>>>> geir
> >>>>>>
> >>>>>>
> >>>>>> Paulex Yang wrote:
> >>>>>>
> >>>>>>
> >>>>>>> Tim Ellison wrote:
> >>>>>>>
> >>>>>>>> Geir Magnusson Jr wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Now, on my windows box I got a clean build, no failures....
 hm.
> >>>>>>>>>
> >>>>>>>> The test works on en_US locale and fails on en_UK. 
I'm guessing
> >> that
> >>>>>>>> your machine is set up as en_US.
> >>>>>>>>
> >>>>>>>> Richard offered a patch that sets the locale to en_US
for all
> >>>>>>>> MessageFormatTest-s, but I suggested that was not a
suitable
> >>>>>>>> solution.
> >>>>>>>>
> >>>>>>>> For now I suggest we remove the assertion, since it
is beyond the
> >>>>>>>> spec
> >>>>>>>> requirements for this type.
> >>>>>>>>
> >>>>>>> Tim,
> >>>>>>>
> >>>>>>> Should we also consider the principle of "follow the RI"
here?  I
> >>>>>>> think
> >>>>>>> it is a sample of unclear spec, and we should assert if
our
> >>>>>>> implementation follows RI, i.e., the assert about return
value of
> >>>>>>> toPattern() is necessary. The issue here is just that the
testcase
> >>>>>>> assumes the return value is locale-independent, so I think
> Richard's
> >>>>>>> patch is OK. Further, from the test perspective, maybe(just
maybe)
> >>>>>>> test
> >>>>>>> case on only one locale is not enough to check Harmony's
> toPattern()
> >>>>>>> logic, tests on more different locale(especially the 'exceptional'
> >>>>>>> case
> >>>>>>> like en_UK) are better.
> >>>>>>>
> >>>>>>> Also FYI, I tried the original test case with RI on en_UK
locale,
> >>>>>>> and it
> >>>>>>> failed exactly as Harmony.
> >>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Tim
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Geir Magnusson Jr wrote:
> >>>>>>>>>
> >>>>>>>>>> This is nuts.  We need to chase down the commit
that broke
> this,
> >>>>>>>>>> and
> >>>>>>>>>> reverse it.  We can't have a broken build persisting
this long.
> >>>>>>>>>>
> >>>>>>>>>> geir
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Tim Ellison wrote:
> >>>>>>>>>>
> >>>>>>>>>>> (1) Linux build/tests are passing again,
but for some reason
> the
> >>>>>>>>>>> 'BUILD SUCCESSFUL' note didn't go to the
commit list?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> (2) Windows build/test is still failing
with:
> >>>>>>>>>>>
> >>>>>>>>>>> Wrong full date pattern expected:<...full...>
but
> >> was:<...long...>
> >>>>>>>>>>> junit.framework.ComparisonFailure: Wrong
full date pattern
> >>>>>>>>>>> expected:<...full...> but was:<...long...>
at
> >>>>>>>>>>>
> >>
> org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatter
> >> nLjava_lang_String(MessageFormatTest.java:244)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Tim
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> -----------------------------------------------------------------
> >> ----
> >>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> 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
> >>>>
> >>>>
> >>>>
> >>>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message