On Sat, Dec 3, 2016 at 6:00 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
> > 1. Currently apr 1.6.x doesn't build on Windows using makefiles: > [[[ > link.exe @C:\Users\ivan\AppData\Local\Temp\nm2BCE.tmp > Creating library .\x64\Release\libapr-1.lib and object > .\x64\Release\libapr-1.exp > poll.obj : error LNK2019: unresolved external symbol > apr_poll_drain_wakeup_pipe referenced in function impl_pollset_poll > select.obj : error LNK2001: unresolved external symbol > apr_poll_drain_wakeup_pipe > pollcb.obj : error LNK2019: unresolved external symbol > apr_poll_create_wakeup_pipe referenced in function > apr_pollcb_create_ex > pollset.obj : error LNK2001: unresolved external symbol > apr_poll_create_wakeup_pipe > pollcb.obj : error LNK2019: unresolved external symbol > apr_poll_close_wakeup_pipe referenced in function pollcb_cleanup > pollset.obj : error LNK2001: unresolved external symbol > apr_poll_close_wakeup_pipe > .\x64\Release\libapr-1.dll : fatal error LNK1120: 3 unresolved externals > NMAKE : fatal error U1077: '"C:\Program Files > (x86)\VS14\VC\BIN\amd64\link.exe"' : return code '0x460' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files > (x86)\VS14\VC\BIN\amd64\nmake.exe"' : return code '0x2' > Stop. > ]]] > > Attached patch apr-1.6.x-win32-fix-makefiles-v1.patch.txt fixes this > problem. There is no makefiles for Windows on trunk, so how should I > proceed? May I just commit this patch to 1.6.x branch or it's better > to propose it to STATUS? > +1 to simply commit. "windows makefiles" (as derived from .dsp/.dsw) had proven too volatile to leave on trunk, a lot like "configure" itself. The theory had been that 1.released doesn't change all that much again, even as trunk is expanded and refactored. > 2. The same problem with CMake build. There is no such problem on > trunk. Attached patch apr-1.6.x-win32-fix-cmake-v1.patch > > 3. Compilation fails due unresolved external symbol > file_socket_pipe_close referenced in function > _apr_poll_close_wakeup_pipe. This happens because there is no > file_socket_pipe_close() function on the 1.6.x branch: it's named > apr_file_socket_pipe_close(). Solution could either backport r892386 > [1] from trunk or apply attached patch > (apr-1.6.x-unix-wakeup.patch.txt) . The r892386 doesn't merge cleanly > so I think applying local patch to branch is better. > > I'm not familiar with APR release/backport process yet, so please > excuse me if my questions are stupid. > > [1] https://svn.apache.org/r892386 Nope, no dumb questions here. I'm wondering, where do we go on trunk with 2.0 on Windows, now that we can emit solution/project files from CMake, or just straightforward .mak files? It insisting on a local install of CMake all that much of a hassle for the Windows build machine?
