harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [build] status
Date Thu, 20 Jul 2006 07:37:50 GMT

This was the build break I tried to own up to yesterday.  It was caused
by my refactoring of exception function - to have one set not several.
(I missed the extern "C" clause and included it in some C++ code.)

-Mark.

On 20 July 2006 at 14:30, "Vladimir Gorr" <vvgorr@gmail.com> wrote:
> 
>  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_applyPatte
> r
> > > >> 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
> > >
> > >
> >
> 
> ------=_Part_4963_12864818.1153380636819--



---------------------------------------------------------------------
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
View raw message