On Jan 7, 2012 8:39 AM, "Johan Corveleyn" <jcor...@gmail.com> wrote: >... > On Sat, Jan 7, 2012 at 10:30 AM, Bert Huijben <b...@qqmail.nl> wrote: > > This patch broke the debug shared library builds on Windows. > > Release and/or static builds still work. > > > > Note that a similar patch was applied and later reverted last year for > > exactly the same reason. > > > > I think this patch should be reverted again. > > Strange, on my machine it's the release build that's broken, the debug > build still works (because it defines all those symbols, so there is > no linker problem). Are you sure we're talking about the same patch > (r1209610, the commit that's the subject of this thread)? > > BTW, I noticed that, before r1209610, my release build was failing for > another reason: > > ..\..\..\subversion\libsvn_subr\debug.c(111): error C4013: 'SVN_DBG' > undefined; assuming extern returning int
Right. SVN_DBG should not be committed, or the usages should be wrapped with #ifdef SVN_DEBUG. > > (this started happening after r1209598, which said "Add a debug macro > to print a prop hash." --- before r1209598 all was ok) > > I assumed that was the reason for r1209610: to make the builds, which > didn't define SVN_DEBUG (release builds), working again after r1209598 > broke them. Except that it doesn't fix the problem for the Windows > compiler / linker (cf. danielsh's extractor.py pointer). > > So, if we just revert r1209610, the (release) builds will fail again > for this other reason. I think the functions should *always* exist, so that we don't have to mess with DLLs that have different sets of entrypoints based on how they were compiled. Madness. My recommendation is to move the #ifdef guards to the function content. Just make them noops in release builds. Then you can mix/match debug/release no problem. Cheers, -g
