On Thu, Feb 2, 2012 at 11:22 PM, Stephen Butler <sbut...@elego.de> wrote: > > On Feb 2, 2012, at 23:18 , Johan Corveleyn wrote: > >> On Thu, Feb 2, 2012 at 5:13 PM, <danie...@apache.org> wrote: >>> Author: danielsh >>> Date: Thu Feb 2 16:13:20 2012 >>> New Revision: 1239695 >>> >>> URL: http://svn.apache.org/viewvc?rev=1239695&view=rev >>> Log: >>> Merge the r1207555 group from trunk: >>> >>> * r1207555, r1207808 >>> mod_dontdothat: contrib/ -> tools/ and relicense under ALv2. >>> Justification: >>> ASF infra is using this so we should maintain it. >>> Stuff in contrib/ isn't officially maintained. >>> Notes: >>> r1207555: Perform the move (from r1207550) and relicense >>> r1207808: Enable building mod_dontdothat from our standard make scripts. >>> Votes: >>> +1: rhuijben, stsp, cmpilato >> >> This just reminded me of a build problem I had with trunk with >> mod_dontdothat. Which I fixed in r1227900 [1]. I just checked, and now >> I see the same problem when building the 1.7.x branch: >> >> [[[ >> mod_dontdothat.obj : error LNK2019: unresolved external symbol >> _XML_Parse referenced in function _dontdothat_filter >> mod_dontdothat.obj : error LNK2019: unresolved external symbol >> _XML_ParserFree referenced in function _clean_up_parser >> mod_dontdothat.obj : error LNK2019: unresolved external symbol >> _XML_SetCharacterDataHandler referenced in function >> _dontdothat_insert_filters >> mod_dontdothat.obj : error LNK2019: unresolved external symbol >> _XML_SetElementHandler referenced in function >> _dontdothat_insert_filters >> mod_dontdothat.obj : error LNK2019: unresolved external symbol >> _XML_SetUserData referenced in function _dontdothat_insert_filters >> mod_dontdothat.obj : error LNK2019: unresolved external symbol >> _XML_ParserCreate referenced in function _dontdothat_insert_filters >> ..\..\..\Release\tools\server-side\mod_dontdothat\mod_dontdothat.so : >> fatal error LNK1120: 6 unresolved externals >> ]]] >> >> Am I the only one seeing this? Either this is a local problem, only >> for me (in which case, maybe it should be reverted from trunk and I >> should fix my environment or the Makefile I'm using or something), > > > I saw it on 1.7.x too, about an hour ago (Windows 7, VS2008). I > thought it was my own fault. > >> >> or others should be affected too, in which case r1227900 should be >> backported too. > > +1
Thanks for confirming. I just proposed r1227900 for backport. -- Johan
