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 Thu, 20 Jul 2006 07:30:36 GMT
 The issue mentioned below disapperead after the latest changes for class
library.
Nevertheless I'm not clear a clue for this build error. In any case thanks
for this fix.

Vladimir.



On 7/19/06, Vladimir Gorr <vvgorr@gmail.com> wrote:
>
>  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