Re: Linking with libapr-1.lib on MS Windows using MSVC 19
Actually, while doing the same thing, but with the 1.52 release, it worked!
Unfortunately, I cannot swear I didn't change anything in MSVS setup, but I
don't think I did... maybe inadvertedly somehow...
From: Oleg Sivokon
Sent: Wednesday, June 20, 2018 2:38:16 PM
To: Gregg Smith; dev@apr.apache.org
Subject: Re: Linking with libapr-1.lib on MS Windows using MSVC 19
> No not really, but this gives me problems trying to build x86 on a x64
> computer so I just remove it from makefile.win.
> Just to make sure this is not an oversight: I'm on a x64 and am trying to
> build x64, no 32-bit is desired.
>
> !IF [$(COMSPEC) /c cl /nologo /? \
> | $(SystemRoot)\System32\find.exe "x64" >NUL ] == 0
> ARCH=x64 Release
> !ELSE
> ARCH=Win32 Release
> !ENDIF
Removing these lines made no difference
> Are you using the VS20xx x64 Native Tools Command Prompt?
Yes, I tried MSVS 2017 and MSVS 2015, should I try even earlier versions?
> If all else fails I believe you can bypass makefile.win
>
> nmake /f libapr.mak cfg="libapr - x64 Release"
This gives the exact same error (although, this time the executable that
produces it isn't the rc.exe, but link.exe)
More information that might help / shed some light:
I was trying to convert worspace files into solutions, but it failed completely
for all projects. Unfortunately, MSVS doesn't produce any intelligible
reports, just "failed".
I also tried to run nmake on apr-util Makefile, but it complains about syntax
error in line 91, which reads:
!IF "$(XML_PARSER)" == "libexpat"
Is this symptomatic of anything?
But, in all honesty, I would really, really, want to avoid touching MSVS at
all. Personal preferences aside, I want this project to run in automated
testing environment, and the very thought of having to deal with MSVS invokes a
lot of painful memories...
Best.
Oleg
This communication and all information contained in or attached to it is
confidential, intended solely for the addressee, may be legally privileged and
is the intellectual property of one of the companies of NEX Group plc ("NEX")
or third parties. If you are not the intended addressee or receive this message
in error, please immediately delete all copies of it and notify the sender. We
have taken precautions to minimise the risk of transmitting software viruses,
but we advise you to carry out your own virus checks on any attachments. We do
not accept liability for any loss or damage caused by software viruses. NEX
reserves the right to monitor all communications. We do not accept any legal
responsibility for the content of communications, and no communication shall be
considered legally binding. Furthermore, if the content of this communication
is personal or unconnected with our business, we accept no liability or
responsibility for it. NEX Group plc is a public limited company registered in
England and Wales under number 10013770 and certain of its affiliates are
authorised and regulated by regulatory authorities. For further regulatory
information please see www.NEX.com.
Re: Linking with libapr-1.lib on MS Windows using MSVC 19
> No not really, but this gives me problems trying to build x86 on a x64
> computer so I just remove it from makefile.win.
> Just to make sure this is not an oversight: I'm on a x64 and am trying to
> build x64, no 32-bit is desired.
>
> !IF [$(COMSPEC) /c cl /nologo /? \
> | $(SystemRoot)\System32\find.exe "x64" >NUL ] == 0
> ARCH=x64 Release
> !ELSE
> ARCH=Win32 Release
> !ENDIF
Removing these lines made no difference
> Are you using the VS20xx x64 Native Tools Command Prompt?
Yes, I tried MSVS 2017 and MSVS 2015, should I try even earlier versions?
> If all else fails I believe you can bypass makefile.win
>
> nmake /f libapr.mak cfg="libapr - x64 Release"
This gives the exact same error (although, this time the executable that
produces it isn't the rc.exe, but link.exe)
More information that might help / shed some light:
I was trying to convert worspace files into solutions, but it failed completely
for all projects. Unfortunately, MSVS doesn't produce any intelligible
reports, just "failed".
I also tried to run nmake on apr-util Makefile, but it complains about syntax
error in line 91, which reads:
!IF "$(XML_PARSER)" == "libexpat"
Is this symptomatic of anything?
But, in all honesty, I would really, really, want to avoid touching MSVS at
all. Personal preferences aside, I want this project to run in automated
testing environment, and the very thought of having to deal with MSVS invokes a
lot of painful memories...
Best.
Oleg
This communication and all information contained in or attached to it is
confidential, intended solely for the addressee, may be legally privileged and
is the intellectual property of one of the companies of NEX Group plc ("NEX")
or third parties. If you are not the intended addressee or receive this message
in error, please immediately delete all copies of it and notify the sender. We
have taken precautions to minimise the risk of transmitting software viruses,
but we advise you to carry out your own virus checks on any attachments. We do
not accept liability for any loss or damage caused by software viruses. NEX
reserves the right to monitor all communications. We do not accept any legal
responsibility for the content of communications, and no communication shall be
considered legally binding. Furthermore, if the content of this communication
is personal or unconnected with our business, we accept no liability or
responsibility for it. NEX Group plc is a public limited company registered in
England and Wales under number 10013770 and certain of its affiliates are
authorised and regulated by regulatory authorities. For further regulatory
information please see www.NEX.com.
Re: Linking with libapr-1.lib on MS Windows using MSVC 19
On Tue, Jun 19, 2018 at 9:17 AM, Oleg Sivokon wrote: > Hello list! > > Later, in Release directory I discovered libapr-1.lib which, as far as I > understand is analogous to an *.a file (archive), and is used by MSVC to > look up symbol definitions. > Note, it looks them up, but the code exists in libapr-1.dll. Think of the pair as the equivalent of an .so file. You'll also find an apr-1.lib, this is more the equivalent of an .a file, and when linked to an executable the functions will be copied to the binary (.exe). I think you would want libapr-1.lib/libapr-1.so if you plan to load the library at runtime from python, in the future. > I then dropped this file in the directory I configured the linker to look > into. Here's the complete command line given to the linker: > > C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\BIN\x86_amd64\link.exe > /nologo > /INCREMENTAL:NO > /LTCG > /DLL > /MANIFEST:EMBED,ID=2 > /MANIFESTUAC:NO > /LIBPATH:c:\dev\protopy\lib/apr > /LIBPATH:c:\bin\python\Libs > /LIBPATH:c:\dev\protopy\.venv\libs > /LIBPATH:c:\dev\protopy\.venv\PCbuild\amd64 > "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\LIB\amd64" > "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\ > x64" > "/LIBPATH:C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64" > apr-1.lib > /EXPORT:PyInit_wrapped build\temp.win-amd64-3.6\Release\protopy/lib/ > descriptors.obj > build\temp.win-amd64-3.6\Release\protopy/lib/binparser.obj > build\temp.win-amd64-3.6\Release\protopy/lib/defparser.obj > build\temp.win-amd64-3.6\Release\protopy/lib/protopy.lex.obj > build\temp.win-amd64-3.6\Release\protopy/lib/protopy.tab.obj > build\temp.win-amd64-3.6\Release\protopy/lib/pyhelpers.obj > build\temp.win-amd64-3.6\Release\protopy/lib/list.obj > build\temp.win-amd64-3.6\Release\protopy/wrapper.obj > /OUT:build\lib.win-amd64-3.6\protopy\wrapped.cp36-win_amd64.pyd > /IMPLIB:build\temp.win-amd64-3.6\Release\protopy/lib\ > wrapped.cp36-win_amd64.lib > > formatted for readability. > > The error I'm getting: > > error LNK2001: unresolved external symbol \ > __imp_apr_hash_set > > After running dumpbin.exe on libapr-1.lib, I can see that the symbols it > exports are all named __imp__apr_something, while when liking with my code > it looks for __imp_apr_something (notice single vs double underscores). > You don't quote your cc flags, but I'm presuming that your code is prepared to link to libapr-1.lib (dynamic library __imp[ort]__) but you are linking above to apr-1.lib (not dynamic.) If you want your code to link to apr-1.lib instead, and not have a dynamic dependency to libapr-1.so, then be sure to add /D APR_STATIC when compiling your code for Windows.
Re: Linking with libapr-1.lib on MS Windows using MSVC 19
No not really, but this gives me problems trying to build x86 on a x64
computer so I just remove it from makefile.win.
!IF [$(COMSPEC) /c cl /nologo /? \
| $(SystemRoot)\System32\find.exe "x64" >NUL ] == 0
ARCH=x64 Release
!ELSE
ARCH=Win32 Release
!ENDIF
Are you using the VS20xx x64 Native Tools Command Prompt?
If all else fails I believe you can bypass makefile.win
nmake /f libapr.mak cfg="libapr - x64 Release"
Cheers
On 6/19/2018 8:38 AM, Oleg Sivokon wrote:
As I continue to struggle with this issue, I realized that
nmake -f Makefile.win
would compile a 32-bit library, but, I I need the 64-bit version, so I tried
this:
nmake -f Makefile.win ARCH="x64 Release"
And after installing a lot of MS garbage SDKs and code editors, when I think I
finally have all the necessary headers, I'm stuck at this:
LNK1112: module machine type x86 conflicts with target...
when compiling libapr.rc. I don't know what makes it think it is intended for
32-bit architecture...
Is this as expected? Am I missing some settings, or is this a misconfiguration
on your side?
Thanks!
Oleg
From: Oleg Sivokon
Sent: Tuesday, June 19, 2018 5:17:38 PM
To: dev@apr.apache.org
Subject: Linking with libapr-1.lib on MS Windows using MSVC 19
Hello list!
I'm trying to compile my Python extension which uses APR library. I could do
this on Linux, but on MS Windows... well, I really know very little about MS
tool-chain and how things work, so would appreciate some help.
I followed the instructions in the README in the project and compiled the
library using:
cd apr
nmake -f Makefile.win
Later, in Release directory I discovered libapr-1.lib which, as far as I
understand is analogous to an *.a file (archive), and is used by MSVC to look
up symbol definitions.
I then dropped this file in the directory I configured the linker to look into.
Here's the complete command line given to the linker:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe
/nologo
/INCREMENTAL:NO
/LTCG
/DLL
/MANIFEST:EMBED,ID=2
/MANIFESTUAC:NO
/LIBPATH:c:\dev\protopy\lib/apr
/LIBPATH:c:\bin\python\Libs
/LIBPATH:c:\dev\protopy\.venv\libs
/LIBPATH:c:\dev\protopy\.venv\PCbuild\amd64
"/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64"
"/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x64"
"/LIBPATH:C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64"
apr-1.lib
/EXPORT:PyInit_wrapped
build\temp.win-amd64-3.6\Release\protopy/lib/descriptors.obj
build\temp.win-amd64-3.6\Release\protopy/lib/binparser.obj
build\temp.win-amd64-3.6\Release\protopy/lib/defparser.obj
build\temp.win-amd64-3.6\Release\protopy/lib/protopy.lex.obj
build\temp.win-amd64-3.6\Release\protopy/lib/protopy.tab.obj
build\temp.win-amd64-3.6\Release\protopy/lib/pyhelpers.obj
build\temp.win-amd64-3.6\Release\protopy/lib/list.obj
build\temp.win-amd64-3.6\Release\protopy/wrapper.obj
/OUT:build\lib.win-amd64-3.6\protopy\wrapped.cp36-win_amd64.pyd
/IMPLIB:build\temp.win-amd64-3.6\Release\protopy/lib\wrapped.cp36-win_amd64.lib
formatted for readability.
The error I'm getting:
error LNK2001: unresolved external symbol \
__imp_apr_hash_set
After running dumpbin.exe on libapr-1.lib, I can see that the symbols it
exports are all named __imp__apr_something, while when liking with my code it
looks for __imp_apr_something (notice single vs double underscores).
What am I doing wrong? Why do the names differ?
Thanks!
Oleg
PS. I also posted this question to Stack Overflow:
https://stackoverflow.com/q/50930010/5691066
This communication and all information contained in or attached to it is confidential,
intended solely for the addressee, may be legally privileged and is the intellectual
property of one of the companies of NEX Group plc ("NEX") or third parties. If
you are not the intended addressee or receive this message in error, please immediately
delete all copies of it and notify the sender. We have taken precautions to minimise the
risk of transmitting software viruses, but we advise you to carry out your own virus
checks on any attachments. We do not accept liability for any loss or damage caused by
software viruses. NEX reserves the right to monitor all communications. We do not accept
any legal responsibility for the content of communications, and no communication shall be
considered legally binding. Furthermore, if the content of this communication is personal
or unconnected with our business, we accept no liability or responsibility for it. NEX
Group plc is a public limited company registered in England and Wales under number
10013770 and certain of its affiliates are authorised and regulated by regulatory
authorities. For further regulatory information please see www.NEX.com.
This communication and all information
Re: Linking with libapr-1.lib on MS Windows using MSVC 19
As I continue to struggle with this issue, I realized that
nmake -f Makefile.win
would compile a 32-bit library, but, I I need the 64-bit version, so I tried
this:
nmake -f Makefile.win ARCH="x64 Release"
And after installing a lot of MS garbage SDKs and code editors, when I think I
finally have all the necessary headers, I'm stuck at this:
LNK1112: module machine type x86 conflicts with target...
when compiling libapr.rc. I don't know what makes it think it is intended for
32-bit architecture...
Is this as expected? Am I missing some settings, or is this a misconfiguration
on your side?
Thanks!
Oleg
From: Oleg Sivokon
Sent: Tuesday, June 19, 2018 5:17:38 PM
To: dev@apr.apache.org
Subject: Linking with libapr-1.lib on MS Windows using MSVC 19
Hello list!
I'm trying to compile my Python extension which uses APR library. I could do
this on Linux, but on MS Windows... well, I really know very little about MS
tool-chain and how things work, so would appreciate some help.
I followed the instructions in the README in the project and compiled the
library using:
cd apr
nmake -f Makefile.win
Later, in Release directory I discovered libapr-1.lib which, as far as I
understand is analogous to an *.a file (archive), and is used by MSVC to look
up symbol definitions.
I then dropped this file in the directory I configured the linker to look into.
Here's the complete command line given to the linker:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe
/nologo
/INCREMENTAL:NO
/LTCG
/DLL
/MANIFEST:EMBED,ID=2
/MANIFESTUAC:NO
/LIBPATH:c:\dev\protopy\lib/apr
/LIBPATH:c:\bin\python\Libs
/LIBPATH:c:\dev\protopy\.venv\libs
/LIBPATH:c:\dev\protopy\.venv\PCbuild\amd64
"/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64"
"/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x64"
"/LIBPATH:C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64"
apr-1.lib
/EXPORT:PyInit_wrapped
build\temp.win-amd64-3.6\Release\protopy/lib/descriptors.obj
build\temp.win-amd64-3.6\Release\protopy/lib/binparser.obj
build\temp.win-amd64-3.6\Release\protopy/lib/defparser.obj
build\temp.win-amd64-3.6\Release\protopy/lib/protopy.lex.obj
build\temp.win-amd64-3.6\Release\protopy/lib/protopy.tab.obj
build\temp.win-amd64-3.6\Release\protopy/lib/pyhelpers.obj
build\temp.win-amd64-3.6\Release\protopy/lib/list.obj
build\temp.win-amd64-3.6\Release\protopy/wrapper.obj
/OUT:build\lib.win-amd64-3.6\protopy\wrapped.cp36-win_amd64.pyd
/IMPLIB:build\temp.win-amd64-3.6\Release\protopy/lib\wrapped.cp36-win_amd64.lib
formatted for readability.
The error I'm getting:
error LNK2001: unresolved external symbol \
__imp_apr_hash_set
After running dumpbin.exe on libapr-1.lib, I can see that the symbols it
exports are all named __imp__apr_something, while when liking with my code it
looks for __imp_apr_something (notice single vs double underscores).
What am I doing wrong? Why do the names differ?
Thanks!
Oleg
PS. I also posted this question to Stack Overflow:
https://stackoverflow.com/q/50930010/5691066
This communication and all information contained in or attached to it is
confidential, intended solely for the addressee, may be legally privileged and
is the intellectual property of one of the companies of NEX Group plc ("NEX")
or third parties. If you are not the intended addressee or receive this message
in error, please immediately delete all copies of it and notify the sender. We
have taken precautions to minimise the risk of transmitting software viruses,
but we advise you to carry out your own virus checks on any attachments. We do
not accept liability for any loss or damage caused by software viruses. NEX
reserves the right to monitor all communications. We do not accept any legal
responsibility for the content of communications, and no communication shall be
considered legally binding. Furthermore, if the content of this communication
is personal or unconnected with our business, we accept no liability or
responsibility for it. NEX Group plc is a public limited company registered in
England and Wales under number 10013770 and certain of its affiliates are
authorised and regulated by regulatory authorities. For further regulatory
information please see www.NEX.com.
This communication and all information contained in or attached to it is
confidential, intended solely for the addressee, may be legally privileged and
is the intellectual property of one of the companies of NEX Group plc ("NEX")
or third parties. If you are not the intended addressee or receive this message
in error, please immediately delete all copies of it and notify the sender. We
have taken precautions to minimise the risk of transmitting software viruses,
but we advise you to carry out your own virus checks on any attachments. We do
