httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steffen <>
Subject Re: minor APR 1.5.2 build error on Windows
Date Sat, 27 Jun 2015 08:52:18 GMT

Indeed, the APR libraries have projects named libapr but produce 
output named libapr-1. The problem with this is in newer versions of 
Visual Studio TargetName defaults to the project name and not the 
basename of the output.  Since the PDB file is named based on the 
TargetName the pdb file ends up being named libapr.pdb instead of 

I am a IDE/GUI-only guy and run the following perl routine,  it fixes 
by explicitly providing a TargetName definition and shuts up some 
warnings about this problem as well.

 find(sub {
         return unless (/\.vcxproj$/);
         my $output_file = get_output_file($_);
         return unless (defined($output_file));
         my ($project_name) = fileparse($_, qr/\.[^.]*$/);
         my ($old_style_target_name) = fileparse($output_file, 
         return if ($old_style_target_name eq $project_name);
       }, "$SRCLIB\\apr", "$SRCLIB\\apr-util", "$SRCLIB\\apr-iconv");

Without this routine the install fails when it tries to copy 

See this thread for details of the changes:


On Saturday 27/06/2015 at 09:59, Gregg Smith  wrote:
> On 6/26/2015 1:54 AM, Stefan Hett wrote:
>> On 6/26/2015 4:55 AM, Gregg Smith wrote:
>>> On 6/25/2015 10:51 AM, Stefan Hett wrote:
>>>> Hi Gregg,
>>>>> On 6/22/2015 3:58 AM, Stefan Hett wrote:
>>>>>> Hi Gregg,
>>>>>>> On 6/22/2015 2:49 AM, Stefan Hett wrote:
>>>>>>>> Hi,
>>>>>>>> I just tested building APR 1.5.2 from source on windows,
>>>>>>>> the instructions from the readme file.
>>>>>>>> compiling (aka: nmake -f succeeded without
>>>>>>>> but the following install command (aka: nmake -f

>>>>>>>> PREFIX=FOO install) failed with return code 0x1:
>>>>>>>> copy Release/libapr-1.pdb "..\apr-dist\bin\" <.y
>>>>>>>> The system cannot find the file specified.
>>>>>>>> NMAKE : fatal error U1077: 'copy' : return code '0x1'
>>>>>>>> Stop.
>>>>>>>> Without looking at the build script I assume that the PDB
is not  
>>>>>>>> created for Release builds and therefore the file is missing.
>>>>>>>> Maybe worth either adjusting the linker/compiler settings
so the  PDB 
>>>>>>>> is also generated in Release builds or adding a  file-existence-check

>>>>>>>> prior to the copy operation, so building  doesn't issue that
>>>>>>>> For me that's not a problem here. Just thought might be good
to  raise 
>>>>>>>> that point so that user experience with APR could be  improved.
>>>>>>> But it is there, look at the Link line in libapr.mak
>>>>>>> /pdb:"$(OUTDIR)\libapr-1.pdb"
>>>>>>> It didn't get produced for some reason. What Visual C++ version
>>>>>>> you using?
>>>>>> Using Visual Studio 2010 SP1 here.
>>>>>> I'm not that familiar with APR internals. So pardon me if I'm  wrong

>>>>>> here.
>>>>>> I assume you are refering to apr/libapr.mak here. For instance in
>>>>>> line 174.
>>>>>> I can see that the /pdb-parameter is specified. However I don't 
>>>>>> the /debug parameter here. To my knowledge the /pdb parameter  just

>>>>>> specifies the output filename for the PDB. It doesn't  actually 
>>>>>> specify that the PDB is to be generated (for which the  /Debug 
>>>>>> parameter would be used for). Also see: 
>>>>>> Am I on the wrong page here?
>>>>> I don't think so but yes, line 174, /debug is right after the /pdb  
>>>>> switch.
>>>>> tal:no /pdb:"$(OUTDIR)\libapr-1.pdb" /debug /out:"$
>>>> I just got back and checked this issue out once more. Of course you  
>>>> are right here. The linker settings seem to be fine. I just realized  
>>>> that in the build-directory (apr/Release) there indeed is a  generated 
>>>> pdb-file, but it's called libapr.pdb.
>>>> Looking through the libapr.mak-file I didn't get a clue how it could  
>>>> name the pdb without the "-1"-suffix...
>>>> When building libapr I get these linker warnings:
>>>> 1>C:\Program Files  
>>>> (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5):  
>>>> warning MSB8012:  
>>>> TargetPath(E:\[delete]SVNTest\SVN\apr\.\Release\libapr.dll) does not  
>>>> match the Linker's OutputFile property value  
>>>> (E:\[delete]SVNTest\SVN\apr\Release\libapr-1.dll). This may cause  
>>>> your project to build incorrectly. To correct this, please make sure  
>>>> that $(OutDir), $(TargetName) and $(TargetExt) property values match  
>>>> the value specified in %(Link.OutputFile).
>>>> 1>C:\Program Files  
>>>> (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(992,5):  
>>>> warning MSB8012: TargetName(libapr) does not match the Linker's  
>>>> OutputFile property value (libapr-1). This may cause your project to  
>>>> build incorrectly. To correct this, please make sure that $(OutDir),  
>>>> $(TargetName) and $(TargetExt) property values match the value  
>>>> specified in %(Link.OutputFile).
>>>> 1>Link:
>>>> 1>     Creating library Release\libapr-1.lib and object  
>>>> Release\libapr-1.exp
>>>> 1>  libapr.vcxproj -> E:\[delete]SVNTest\SVN\apr\.\Release\libapr.dll
>>>> Maybe these information ring a bell on ur side (atm it doesn't for 
>>>> me).
>>> Hi Stefan,
>>> OK, the plot thickens ... libapr.vcxproj
>>> You only get the.vcxproj when using the IDE which uses the dsp files,  
>>> not the .mak.
>>> Bill found one today but it was in the Windows 9x build. This error  
>>> message does not allude to this being a Win9x build.
>>> I can't find any others. I say search your libapr.dsp file for  
>>> libapr.pdb but I don't think you will find it.
>>> It looks like the compiler knows what it is told to do but instead is  
>>> simply going to do what it wants to.
>> Hi Gregg,
>> already replied Bill per PM on his findings.
>> I guess u are right here. Somehow MSBuild 4.0 seems to ignore the  
>> passed /pdb parameter and rather sets the pdb-filename based on the  
>> $TargetName instead. The converted dsp-file doesn't explicitly set the 
>>  TargetName (therefore using its default which is $ProjectName).
>> Modifying the vcxproj-file and setting TargetName to $(ProjectName)-1  
>> resolves the MSBuild warning and creates the correctly named pdb-file.
>> I don't know whether this suspicion of mine (bug in MSBuild 4.0) is  
>> true or not and I couldn't spot any reference on the web (and tbh I'm  
>> not familiar enough with the MSBuild internals to make a proper  
>> assumption here).
>> Given the current findings, I'm not sure whether you want to adjust  
>> the build setup to update the TargetName parameter and set it to the  
>> proper value. I'd argue that for the sake of consistency of the  
>> buildparameters that wouldn't be a bad idea, even if the underlying  
>> issue is actually a bug in MSBuild and shouldn't trigger the problem  
>> in the first place (assuming setting the TargetName is possible  
>> somehow from ur side in some way).
> I installed 2010 and gave this a run and I can duplicate. I can 
> duplicate this on every version from 2010 - 2013. I do not yet have 
> 2015.
> What is most dissatisfying is that these versions ignore the Target 
> Name listed in the General properties and accept and use the Output 
> File (/out:filename) in the General Linker properties, we do get a 
> libapr-1.dll file. Same with the Import Library in the Linker Advanced 
> properties (/implib:filename).  It's just /pdb:filename that it 
> completely ignores.
> In my view, that is a bug in Visual Studio.
> Oddly, what it tells you in the output screen is wrong as well. It 
> doesn't even know what it is really doing.
> 1>Link:
> 1>     Creating library Release\libapr-1.lib and object 
> Release\libapr-1.exp
> 1>  libapr.vcxproj -> K:\Build10\apr-1.5.2a\.\Release\libapr.dll
> That is incorrect because it outputs libapr-1.dll.
> As far as adjusting the build setup to update the TargetName 
> parameter, this is out of our control, this Target Name lunacy was 
> added in VC10.
> That said, you are not completely off base, just need to read that 
> line from right to left. If the project name is used for the Target 
> Name, then the project names needs to change to *-1. When I do this it 
> works like a charm. Unfortunately this cannot be done in a stable 
> branch, it's too drastic in my view at least. This might however be a 
> good candidate for build\ -2010. It would have to modify the 
> dsw files as well possibly, but that's a small price.

View raw message