On Jan 7, 2012 8:39 AM, "Johan Corveleyn" <jcorvel_at_gmail.com> wrote:
>...
> On Sat, Jan 7, 2012 at 10:30 AM, Bert Huijben <bert_at_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
Received on 2012-01-07 19:14:56 CET