apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Smith <...@gknw.net>
Subject Re: Building apr on win32
Date Fri, 13 Jun 2014 17:50:14 GMT
On 6/13/2014 10:16 AM, Christopher Schultz wrote:
> Greg,
>
> On 6/13/14, 12:57 PM, Gregg Smith wrote:
>> On 6/13/2014 9:36 AM, Christopher Schultz wrote:
>>> Greg,
>>>
>>> On 6/13/14, 12:24 PM, Gregg Smith wrote:
>>>> Old instrucions for building in IDE really. If you want to build in the
>>>> IDE just open apr-util.dsw and allow VC to convert.
>>>>
>>>> If you want to build at the command line;
>>> Yeah, I'd like something that I can script. Right now, there's basically
>>> one guy who knows how to build tcnative on win32. We're trying to change
>>> that ;)
>>>
>>>> On 6/13/2014 8:49 AM, Christopher Schultz wrote:
>>>>> Hello,
>>>>>
>>>>> I'm trying to build apr on win32 from the command-line and I'm running
>>>>> into some resistance. I'm using Visual Studio 12 on Windows 8.1. I have
>>>>> installed the "Windows SDK" as well to try to help, but it doesn't seem
>>>>> to have improved things.
>>>>>
>>>>> I'm following the instructions found here:
>>>>> http://apr.apache.org/compiling_win32.html
>>>>>
>>>>> I have downloaded the ZIP files for apr, apr-util, and apr-iconv and
>>>>> put
>>>>> them into the requisite directories.
>>>>>
>>>>> I've run VS's VC\bin\vcvars32.bat to get the build tools in the path,
>>>>    From here cd to c:\work\apr-util then
>>>>
>>>> nmake /f makefile.win ARCH="Win32 Release" buildall checkall
>>>>
>>>> See the makefile.win file for all possible options.
>>> Okay, that seems to get started, but I haven't told it where to find
>>> OpenSSL. I'd like to make sure that the crypto routines get built, and
>>> makefile.win doesn't really make it clear (to me, anyway) how to specify
>>> where the OpenSSL libraries, headers, etc. exist.
>>>
>>> It looks like ../crypto/[cryptos] should exist and perhaps it will
>>> automatically look for ../crypto/openssl/stuff. Do I have that right?
>> Crypto, here's what you'll have to do;
>>
>> Edit apr-util\include\apu.hw and change the 0 to 1 for
>>
>> #define APU_HAVE_CRYPTO         0
>>
>> #ifndef APU_DSO_MODULE_BUILD
>> #define APU_HAVE_OPENSSL        0
> Can I specify that stuff on the command-line like with
> -DAPU_HAVE_CRYPTO=1 and -DAPU_HAVE_OPENSSL=1, or are those values
> clobbered during the make?
>> If you look at apr-util\crypto\apr_crypto_openssl.mak
>> you will notice it looks for needed headers in "../../openssl/inc32" and
>> libs in "..\..\openssl\out32dll" which translates to
>> c:\work\openssl\inc32 and c:\work\openssl\out32dll
> Okay, I can see both of those directories under ..\openssl-1.0.1h. I'll
> re-name the openssl directory accordingly.
>
> Are these things that could be parameterized? I noticed the "no
> exceptions" note on the "Building on win32" page, but it seems like
> NMAKE should be able to use paths defined on the CLI, no?
>

No, because makefile.win is calling nmake multiple times for each and 
every .mak file and quickly looking I do not see anything to propagate 
your /I this&that or /D this&that to each evocation of nmake.

>> You mentioned compiling in openssl statically (in your reply to Jeff I
>> believe), in windows we normally compile and use DLLs, you would have to
>> modify apr_crypto_openssl.mak to build using the openssl static lib.
> Yeah, we do a statically-compiled tcnative because ... honestly I don't
> really know. It's not that I need a static libapr... I need a static
> tcnative. So as long as I produce linkable objects from libapr, I should
> be able to statically-link tcnative (which itself is a .dll).
>
>> and to build it's
>>
>> nmake /f makefile.win ARCH="Win32 Release" CRYPTO_LIST="openssl"
>> buildall checkall
> Awesome. I'll give all that a try.
>
> Thanks,
> -chris

Have fun!

Gregg


Mime
View raw message