If you build ZLib with the Windows specific assembly optimizations you
introduce known issues. Please make sure that you run the Subversion test that
was designed to show you this problem.
These assembly optimizations to zlib are a non-supported contributed package to
zlib and not supported by the zlib authors. And as such they weren’t kept up to
date over the last few releases.
In some cases this may corrupt your data when transferred via ra-serf. This is
how we found and reported the now-known problem to the zlib authors. They are
currently not interested in fixing this issue, as the optimizations are
non-supported and out of date anyway.
Bert
From: Troy Curtis Jr [mailto:troycurti...@gmail.com]
Sent: zondag 28 januari 2018 16:23
To: Nathan Hartman <hartman.nat...@gmail.com>
Cc: Subversion Development <dev@subversion.apache.org>
Subject: Re: Windows Compile Help
On Sun, Jan 28, 2018 at 12:21 AM Nathan Hartman <hartman.nat...@gmail.com
<mailto:hartman.nat...@gmail.com> > wrote:
On Jan 27, 2018, at 11:44 PM, Troy Curtis Jr <troycurti...@gmail.com
<mailto:troycurti...@gmail.com> > wrote:
I'm hoping someone can point me in the right direction with an issue I'm having
compiling Subversion on Windows 10 using Visual Studio 2015 tools.
I decided to break out of my comfort zone a bit and see if I could get the
changes in for the py3c dependency added on the Windows side, but I am *not* a
Windows dev. I've done a lot of learning, which as been fun, but I can't
figure this last error out. I've attached the error log, and my WIP visual
studio script that basically got me this far.
It seems to complain the it can't find a handful of symbols related to zlib,
but if I look at the static archive I see those names (though there are all
those different calling conventions on windows, so maybe that is related to my
issue?).
Anyway, I've run out of ideas and was hoping for a little nudge.
…
Troy
<vs-build.txt>
<svnbuilderr.txt>
Forgive the second reply but on further study of the build log and some
googling around, I think the absolute/relative paths are not the culprit, and
that your suspicion about calling conventions may be correct.
https://stackoverflow.com/questions/5424549/unresolved-externals-despite-linking-in-zlib-lib
Which led to:
http://www.zlib.net/DLL_FAQ.txt
To summarize, CDECL is default and therefore probably what Subversion is
building with, but zlib may be building with STDCALL.
I would check if the zlib project defines ZLIB_WINAPI and if so, remove it and
retry the build.
Thanks so much for taking the time to look at this Nathan! You were right on.
I had gotten close earlier but went the wrong way. At one point I *added*
ZLIB_WINAPI to the config header, but of course it complained about a
redefinition. It didn't click that I needed to *remove* it. Pulling that out
of the build configuration finally got me linking (well, after added /safeseh
to the asm build in zlib as well).
Now to add swig to the mix and maybe eventually actually adding the change I
want to test! XD
Thanks again!
Troy
