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
libapr-1.pdb.
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,
qr/\.[^.]*$/);
return if ($old_style_target_name eq $project_name);
insert_property_group($_,
"<TargetName>$old_style_target_name</TargetName>",
'.torig');
}, "$SRCLIB\\apr", "$SRCLIB\\apr-util", "$SRCLIB\\apr-iconv");
Without this routine the install fails when it tries to copy
libapr-1.pdb.
See this thread for details of the changes:
http://social.msdn.microsoft.com/Forums/en-US/vcprerelease/thread/3c03e730-6a0e-4ee4-a0d6-6a5c3ce4343c
Steffen
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, 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.
