[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1209610 - /subversion/trunk/subversion/libsvn_subr/debug.c

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Sat, 7 Jan 2012 14:38:33 +0100

> From: Johan Corveleyn
> Sent: 6-1-2012 23:50
> To: Daniel Shahaf
> Cc: Subversion Development; Hyrum Wright
> Subject: Re: svn commit: r1209610
> - /subversion/trunk/subversion/libsvn_subr/debug.c
> On Fri, Jan 6, 2012 at 2:45 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> Johan Corveleyn wrote on Fri, Jan 06, 2012 at 02:12:15 +0100:
>>> On Fri, Dec 2, 2011 at 7:04 PM,  <hwright_at_apache.org> wrote:
>>> > Author: hwright
>>> > Date: Fri Dec  2 18:04:14 2011
>>> > New Revision: 1209610
>>> >
>>> > URL: http://svn.apache.org/viewvc?rev=1209610&view=rev
>>> > Log:
>>> > Fix builds where SVN_DEBUG is not defined.
>>> >
>>> > * subversion/libsvn_subr/debug.c:
>>> >  Don't build any of this file if SVN_DEBUG isn't defined.  Callers don't have
>>> >  access to it in that case, anyway.
>>>
>>> For some reason, after this commit my *Release* build on Windows (VCE
>>> 2008) fails with:
>>>
>>> libsvn_subr.def : error LNK2001: unresolved external symbol svn_dbg__preamble
>>> libsvn_subr.def : error LNK2001: unresolved external symbol svn_dbg__print_props
>>> libsvn_subr.def : error LNK2001: unresolved external symbol svn_dbg__printf
>>> ..\..\..\Release\subversion\libsvn_subr\libsvn_subr-1.lib : fatal
>>> error LNK1120: 3 unresolved externals
>>>
>>> I've been trying to understand why, but I don't. Maybe something to do
>>> with preprocessors and linkers ... but my C compilation knowledge is
>>> lacking here :-).
>>>
>>> Is any of the other Windows devs seeing this?
>>>
>>> A Debug build still works, so if SVN_DEBUG is defined everything's ok.
>>> I guess that's also the reason why the buildbots don't see this
>>> problem (I guess they perform Debug-builds).
>>>
>> Does adding those three functions to the exceptions list in
>> build/generator/extractor.py fix the release build (and break the
>> debug build)?
>
> Yes.
>
> Release build works.
>
> Debug build fails with:
>
> libsvn_ra_local-1.lib(ra_plugin.obj) : error LNK2019: unresolved
> external symbol _svn_dbg__printf referenced in function
> _ignore_warnings
> libsvn_ra_local-1.lib(ra_plugin.obj) : error LNK2019: unresolved
> external symbol _svn_dbg__preamble referenced in function
> _ignore_warnings
> ..\..\..\Debug\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error
> LNK1120: 2 unresolved externals
>
>
> Any ideas on how to fix this?
>
> Has anyone been able to make a Release build on Windows since this commit?
>

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

(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.

-- 
Johan
Received on 2012-01-07 14:39:46 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.