logo
Apache Lounge
Webmasters

 

About Forum Index Downloads Search Register Log in RSS X


Keep Server Online

If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.

or

Bitcoin

A donation makes a contribution towards the costs, the time and effort that's going in this site and building.

Thank You! Steffen

Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
Post new topic   Forum Index -> Building & Member Downloads View previous topic :: View next topic
Reply to topic   Topic: libaprutil-1.dll does not get build
Author
Jan-E



Joined: 09 Mar 2012
Posts: 1266
Location: Amsterdam, NL, EU

PostPosted: Thu 15 Jun '17 3:42    Post subject: libaprutil-1.dll does not get build Reply with quote

Split from https://www.apachelounge.com/viewtopic.php?t=7621

One change in apr-util does not seem to be documented: libaprutil.vcxproj has to link the additional library xml.lib now, otherwise libaprutil-1.dll does not get built.

Error messages like:
Quote:
error LNK2019: unresolved external symbol XML_ParserCreate referenced in function apr_xml_parser_create

Just converting the libaprutil.dsp is not enough, because it does not link the xml.lib. To make building with the GUI painless the libaprutil.dsp has to be adjusted.

BTW: I checked how this was solved in the CMake build. CMake does not link xml.lib, but builds libexpat.lib and links that lib. libexpat.lib also provides the necessary functions XML_ParserCreate() and the like.
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1266
Location: Amsterdam, NL, EU

PostPosted: Thu 15 Jun '17 3:43    Post subject: Reply with quote

I also had some trouble with building apr-1.lib, because srclib/apr/include/apr_escape_test_char.h is not included in the tarball and did not get generated initially.
Back to top
admin
Site Admin


Joined: 15 Oct 2005
Posts: 692

PostPosted: Thu 15 Jun '17 7:37    Post subject: Reply with quote

Assuming you use apr/apr-util 1.6. Not seen you issues here. Did not have to change libaprutil.dsp. As far as I know apr_escape_test_char.h is generated and was never included.

Btw.

Expat is now included any more and has to be in an other place with 1.6:


Note in makefile.win:

# APU 1.6 (and up?)
!IF EXIST("srclib\apr-util\xml\xml.mak")
EXPAT=xml
EXPBCK = ..
!ELSE
EXPAT=xml\expat\lib
EXPBCK = ..\..\..
!ENDIF

In cvtdsp.pl is now an option to change e.g. the new location in apache.dsw
Back to top
glsmith
Moderator


Joined: 16 Oct 2007
Posts: 2268
Location: Sun Diego, USA

PostPosted: Thu 15 Jun '17 16:37    Post subject: Reply with quote

cvtdsp.pl -ossl11
when building with OpenSSL 1.1.0
This is documented and handles the new xml.dsp location also.

cvtdsp.pl -apr16
for OpenSSL 1.0.2 (or none) but apr/u 1.6.x.
This is not documented you're right, I'll figure out some wording and add it in for 2.4.next.

But why apr_escape_test_char.h wasn't being generated at first is kind of a surprise since the build is supposed to (in order);

1. create apr.h**
2. compile testchar.exe
3. create apr_escape_test_char.h with testchar.exe
4. compile apr

** I suppose if apr.h exists it will not run the pre-build step. It has to do this in a specific order and the only way it would do that is if all these things were in one single pre-build step. Different versions of VC++ would fire off pre-build steps in different orders which I found strange but was the case and apr_escape_test_char.h requires apr.h. This was also the case in apr 1.5 so nothing changed there.


Last edited by glsmith on Thu 15 Jun '17 16:59; edited 1 time in total
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1266
Location: Amsterdam, NL, EU

PostPosted: Thu 15 Jun '17 16:54    Post subject: Reply with quote

@gregg: both failures happened when building Apr, Apr-iconv and Apr-util separately, not as part of Apache. Try converting aprutil.dsw in srclib/apr-util.
Back to top
glsmith
Moderator


Joined: 16 Oct 2007
Posts: 2268
Location: Sun Diego, USA

PostPosted: Thu 15 Jun '17 17:26    Post subject: Reply with quote

Jan-E wrote:
Try converting aprutil.dsw in srclib/apr-util.


Not sure I understand Jan. If I convert the apu dsw/dsp to sln/vc?proj in VC there should be no problem because the xml.dsp's new location is correct in aprutil.dsw.

Code:
###############################################################################

Project: "xml"=".\xml\xml.dsp" - Package Owner=<4>

Package=<5>
{{{
}}}

Package=<4>
{{{
}}}

###############################################################################

as opposed to it's pre 1.6 location of .\xml\expat\lib\xml.dsp
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1266
Location: Amsterdam, NL, EU

PostPosted: Thu 15 Jun '17 17:53    Post subject: Reply with quote

When you build the solution in the aprutil.sln that you have created the xml.lib will be built. But it is not linked in libaprutil.vcxproj. And the apr_escape_test_char.h is not created either.

Did you try building Release|Win32 or Release|x64 in aprutil.sln? If you do not add xml.lib manually to libaprutil.vcxproj you'll end up with 10 unresolved externals, starting with
Code:
Severity   Code   Description   Project   File   Line   Suppression State
Error   LNK2019   unresolved external symbol XML_ParserCreate referenced in function apr_xml_parser_create   libaprutil   N:\httpd\srclib\apr-util\apr_xml.obj   1

and ending with
Code:
Severity   Code   Description   Project   File   Line   Suppression State
Error   LNK2019   unresolved external symbol XML_ErrorString referenced in function apr_xml_parser_geterror   libaprutil   N:\httpd\srclib\apr-util\apr_xml.obj   1   
Back to top
glsmith
Moderator


Joined: 16 Oct 2007
Posts: 2268
Location: Sun Diego, USA

PostPosted: Thu 15 Jun '17 18:48    Post subject: Reply with quote

libapu 1.5
Code:
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib /nologo /base:"0x6EE60000" /subsystem:windows /dll /incremental:no /debug /opt:ref
# ADD LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib /nologo /base:"0x6EE60000" /subsystem:windows /dll /incremental:no /debug /out:"Release\libaprutil-1.dll" /pdb:"Release\libaprutil-1.pdb" /implib:"Release\libaprutil-1.lib" /MACHINE:X86 /opt:ref
# Begin Special Build Tool
TargetPath=Release\libaprutil-1.dll
SOURCE="$(InputPath)"


libapu 1.6
Code:
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib /nologo /base:"0x6EE60000" /subsystem:windows /dll /incremental:no /debug /opt:ref
# ADD LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib ole32.lib /nologo /base:"0x6EE60000" /subsystem:windows /dll /incremental:no /debug /out:"Release\libaprutil-1.dll" /pdb:"Release\libaprutil-1.pdb" /implib:"Release\libaprutil-1.lib" /MACHINE:X86 /opt:ref
# Begin Special Build Tool
TargetPath=Release\libaprutil-1.dll
SOURCE="$(InputPath)"


It never did have a specific link, VC is able to figure it out because it knows via the dsw/sln that it's there and is part of the solution (implied /libpath).

It always worked for me in VC9 which is what I test dsw/dsp conversions in because it takes forever on my computer to convert in VC>9.

However, I did a complete VC14 sln/vcxproj build of Apache 2.4.26-dev and apr/apu 1.6 and it worked fine there, which uses the very same aprutil/libaprutil dsp/vc?proj files in srclib/apr-util.

Curious, which VC version? 15? I have only built the complete Apache package w/ apr/apu 1.6 at the command line.
Back to top
glsmith
Moderator


Joined: 16 Oct 2007
Posts: 2268
Location: Sun Diego, USA

PostPosted: Mon 19 Jun '17 20:17    Post subject: Reply with quote

Jan-E wrote:
Try converting aprutil.dsw in srclib/apr-util.


Ok, I did this yesterday w/ VC15.

Right off the start I forgot to add expat and yes, lib/aprutil-1.dlls would not build obviously. Once I added the expat source it built fine in x86. [1]

The only real problem I had was with the x64 build, after conversion x64 projects were set to VC10 which I do not have loaded on any machine so it would not build.

However, retargeting a few of the projects (didn't have to do them all for a bare minimum build), it built just fine. We have no way to control this that I know of in the dsw/dsp so we're just going to have to deal with it. [2]

[1] It would be nice to have a warning like we do in httpd if expat is missing and just fail before trying to compile anything, like we do in the command line build. We also have the _try-this-and-that in the httpd build but those do not fire off till the very end which I guess is ok cause we have to build all the other stuff and lib/aprutil-1.dlls are built last.

[2] We may be able to have a post conversion script to change this in the sln/vcxproj files. Of course this would require saving/closing the solution, running the script and opening the solution again but that is easier than retargeting all the projects inside the VC IDE.

It would be easiest the just delete the x64 option and then make a new one like you do in httpd.

And that darn dbd_freetds conector project got missed in the dsw. Nick removed the dsps and I didn't notice he missed the dsw when I then ripped it out of makefile.win. Oh well, not fatal, just startling, fix in r1799251 for apu 1.6.1.
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1266
Location: Amsterdam, NL, EU

PostPosted: Mon 26 Jun '17 22:52    Post subject: Reply with quote

I am not the only one that stumbled over a missing xml/expat in apr/apr-util. On *nix some changes in the build process were needed as well:
https://lists.apache.org/thread.html/b31a17b01f1309fa00ce35366344fe4d90dbc1224f1067c1b57b45e0@<dev.apr.apache.org>
Back to top


Reply to topic   Topic: libaprutil-1.dll does not get build View previous topic :: View next topic
Post new topic   Forum Index -> Building & Member Downloads