Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <558E5746.6070309@gknw.net>
Date: Sat, 27 Jun 2015 00:56:54 -0700
From: Gregg Smith <gls@gknw.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: minor APR 1.5.2 build error on Windows
References: <5587DA14.80704@egosoft.com> <5587E0A9.2050309@gknw.net>
 <5587EA39.10801@egosoft.com> <55884A6A.2000504@gknw.net>
 <558C3FB0.9010300@egosoft.com> <558CBF3A.7090004@gknw.net>
 <558D1346.1060209@egosoft.com>
In-Reply-To: <558D1346.1060209@egosoft.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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, 
>>>>>>> following the instructions from the readme file.
>>>>>>>
>>>>>>> compiling (aka: nmake -f Makefile.win) succeeded without 
>>>>>>> problems, but the following install command (aka: nmake -f 
>>>>>>> Makefile.win 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 error?
>>>>>>>
>>>>>>> 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 
>>>>>> are 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 
>>>>> see 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: 
>>>>> https://msdn.microsoft.com/en-us/library/kwx19e36.aspx
>>>>>
>>>>> 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:"$
>>>>
>>>> http://svn.apache.org/viewvc/apr/apr/tags/1.5.2/libapr.mak?view=annotate 
>>>>
>>>
>>> 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.
>> http://svn.apache.org/r1687620
>>
>> 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\cvtdsp.pl -2010. It would have to modify the dsw files as well 
possibly, but that's a small price.