Cannot get an incremental link of a large, mixed dll with VS 2005 SP1

  • Thread starter Thread starter Bern McCarty
  • Start date Start date
B

Bern McCarty

We have a large mixed dll that I can never seem to get to link incrementally.
Below is the console output. For simplicity I've eliminated some stuff that
we normally do when we really link this dll like manifest embedding and strong
name delay signing. Can anyone see anything wrong with my link command?
Or offer some other explanation why I can never get an incremental link out
of it? To test, I'm just touching one of the source files so it recompiles/links,
but it does a full link every time.

In the below console output I eliminated the actual .obj and .lib lists for
brevity.

-Bern McCarty, Bentley Systems


[== Building o:\out\1\Mstn\Bentley\MicroStation\ustation.dll, (o:\out\1\Mstn\build\mscore\core\mdelemnt.obj)
==]
link -out:o:\out\1\Mstn\Bentley\MicroStation\ustation.dll -assemblydebug
-WX -OPT:NoWin98 -OPT:NOREF -OPT:NOICF -Ignore:4087 -Ignore:4089 -debug
-incremental -fixed:no @o:\out\1
\Mstn\build\mscore\core\link.rsp
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

-test
-time
-BASE:@o:\out\1\Mstn\build\gensrc\ntbsaddr.linker,ustation.dll
-delaysign -keyfile:s:\src\Mozart1\bsitools\PublicPrgRightsCompliant.snk
-ASSEMBLYLINKRESOURCE:o:\out\1\Mstn\Bentley\MicroStation\ustation.resources
-pdb:o:\out\1\Mstn\Bentley\MicroStation\ustation.pdb
-manifestfile:o:\out\1\Mstn\build\mscore\core\Ustation.dll.LinkerGenerated.Manifest
o:\out\1\Mstn\build\mscore\core\mdlbltin.exp
o:\out\1\Mstn\build\mscore\core\mdlmod.obj
.....tons of other objs here...
o:\out\1\Mstn\SDK\Delivery\MicroStation\mdl\library\rmgrsubs.lib
....lots of other libs here...
o:\out\1\Mstn\build\mscore\core\ustndllresource.res
LINK : file alignment: 512, section alignment: 4096
LINK : performing full link
LINK : file alignment: 512, section alignment: 4096
MD Merge: Total time = 12.948s
Generate Transitions: Total time = 0.651s
mdlmod.obj : section 'ATL' (40000040) merged into '.rdata' (40000040)
msvcrt.lib(initsect.obj) : section '.rtc' (40000040) merged into '.rdata'
(40000040)
msvcrt.lib(cinitexe.obj) : section '.CRT' (40000040) merged into '.rdata'
(40000040)
MSVCMRT.lib(mstartup.obj) : section '.CRTMP' (40000040) merged into '.rdata'
(40000040)
MSVCMRT.lib(mstartup.obj) : section '.CRTMA' (40000040) merged into '.rdata'
(40000040)
MSVCMRT.lib(mstartup.obj) : section '.CRTVT' (40000040) merged into '.rdata'
(40000040)
LINK : section '.sdata' (C0000040) merged into '.data' (C0000040)
LINK : section '.xdata' (40000040) merged into '.rdata' (40000040)
MD Finalize: Total time = 7.982s
Pass 1: Interval #1, time = 25.146s
Pass 2: Interval #2, time = 6.860s
Final: Total time = 32.006s
Final: Total time = 41.189
 
I thought I'd add that I see the .ilk file always gets produced, but it is
always zero length. What does that mean?

Why, when the linker decides to perform a full link, can't it just tell me
why it decided to do a full link? If it would do that, then maybe I could
figure out what to do about it. Why does the linker want to keep it a secret?

-Bern
We have a large mixed dll that I can never seem to get to link
incrementally. Below is the console output. For simplicity I've
eliminated some stuff that we normally do when we really link this dll
like manifest embedding and strong name delay signing. Can anyone see
anything wrong with my link command? Or offer some other explanation
why I can never get an incremental link out of it? To test, I'm just
touching one of the source files so it recompiles/links, but it does a
full link every time.

In the below console output I eliminated the actual .obj and .lib
lists for brevity.

-Bern McCarty, Bentley Systems

[== Building o:\out\1\Mstn\Bentley\MicroStation\ustation.dll,
(o:\out\1\Mstn\build\mscore\core\mdelemnt.obj)
==]
link -out:o:\out\1\Mstn\Bentley\MicroStation\ustation.dll
-assemblydebug
-WX -OPT:NoWin98 -OPT:NOREF -OPT:NOICF -Ignore:4087 -Ignore:4089
-debug
-incremental -fixed:no @o:\out\1
\Mstn\build\mscore\core\link.rsp
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
-test
-time
-BASE:@o:\out\1\Mstn\build\gensrc\ntbsaddr.linker,ustation.dll
-delaysign
-keyfile:s:\src\Mozart1\bsitools\PublicPrgRightsCompliant.snk
-ASSEMBLYLINKRESOURCE:o:\out\1\Mstn\Bentley\MicroStation\ustation.reso
urces
-pdb:o:\out\1\Mstn\Bentley\MicroStation\ustation.pdb
-manifestfile:o:\out\1\Mstn\build\mscore\core\Ustation.dll.LinkerGener
ated.Manifest
o:\out\1\Mstn\build\mscore\core\mdlbltin.exp
o:\out\1\Mstn\build\mscore\core\mdlmod.obj
....tons of other objs here...
o:\out\1\Mstn\SDK\Delivery\MicroStation\mdl\library\rmgrsubs.lib
...lots of other libs here...
o:\out\1\Mstn\build\mscore\core\ustndllresource.res
LINK : file alignment: 512, section alignment: 4096
LINK : performing full link
LINK : file alignment: 512, section alignment: 4096
MD Merge: Total time = 12.948s
Generate Transitions: Total time = 0.651s
mdlmod.obj : section 'ATL' (40000040) merged into '.rdata' (40000040)
msvcrt.lib(initsect.obj) : section '.rtc' (40000040) merged into
'.rdata'
(40000040)
msvcrt.lib(cinitexe.obj) : section '.CRT' (40000040) merged into
'.rdata'
(40000040)
MSVCMRT.lib(mstartup.obj) : section '.CRTMP' (40000040) merged into
'.rdata'
(40000040)
MSVCMRT.lib(mstartup.obj) : section '.CRTMA' (40000040) merged into
'.rdata'
(40000040)
MSVCMRT.lib(mstartup.obj) : section '.CRTVT' (40000040) merged into
'.rdata'
(40000040)
LINK : section '.sdata' (C0000040) merged into '.data' (C0000040)
LINK : section '.xdata' (40000040) merged into '.rdata' (40000040)
MD Finalize: Total time = 7.982s
Pass 1: Interval #1, time = 25.146s
Pass 2: Interval #2, time = 6.860s
Final: Total time = 32.006s
Final: Total time = 41.189s
Click to expand...
 
Hi Bern,

Based on my experience, the official scenarios of performing full link are
documented in the link below, you may check to see if you are falling into
one of these situations:
"/INCREMENTAL (Link Incrementally)"
http://msdn2.microsoft.com/en-us/library/4khtbfyf(VS.80).aspx

Additionally, can you add the "/VERBOSE" linker option the project setting
dialog? This will tell the linker to emit all the details of its work.
There was a time that I used "/VERBOSE" option to find out why the debug
mode application is incompatible with /SafeSEH option. You may paste the
detailed linker output here for analysis.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Is the timestamp of the .ilk updated? Perhaps it is readonly, or owned by a
different user?


I've seen that documentation and for other dlls where I've used incremental
linking whenever the linker says "LINK : performing full link" it follows
that up immediately with an explanation of why it resorted to a full link.
But, as you can see, in this case it never offers any explanation at all. I
find that very odd. I reiterate that after a perfectly successful "full
link" ustation.ilk exists but is zero bytes in length. My guess is that is
gives the linker no choice but to do a full link every time. I think the
question then is, why is the linker producing a zero length .ilk file during
an apparently successfull full link with /incremental:yes ? And why doesn't
the linker at least say something like "LINK : performing full link; the
..ilk file is truncated or corrupted." ?

Attached is the console output that you asked for. As you can see, the
linker immediately indicates that it will be doing a full link and it offers
no explanation. When I tried to post this message with the full console
output attached as a text file, it wouldn't post. So I've tried to cut it
down without removing anything that would seem to possibly be useful. I'd be
glad to try to e-mail the full console output or even put it on our ftp site
or something if you'd like. I appreciate your time and help.

Thanks,
Bern
 
Yes the timestamp of the zero length .ilk file is updated with each successful
link.

I didn't make anything in my output tree readonly nor transfer ownership
of any part of it to some other account.
 
Hi Bern ,

Thanks for your information. I will perform some research on it and get
back to you ASAP. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Bern,

Sorry for letting you wait.

I performed some review to the attached text file. Below is some
interesting output:

Invoking LINK.EXE:
-out:o:\out\1\Mstn\Bentley\MicroStation\ustation.dll -assemblydebug -WX
-OPT:NoWin98 -OPT:NOREF -OPT:NOICF -Ignore:4087 -Ignore:4089
-incremental:yes -fixed:no @o:\out\1\Mstn\build\mscore\core\link.rsp
/incremental:no
/nologo
/fullbuild
LINK : file alignment: 512, section alignment: 4096

I see /incremental being overridden with/incremental:No.

I am sure you have gone through
http://msdn2.microsoft.com/en-us/library/4khtbfyf(VS.80).aspx

Can you double check on the following list:

LINK performs a full link if any of the following situations occur:

¡¤ The incremental status (.ilk) file is missing. (LINK creates a
new .ilk file in preparation for subsequent incremental linking.)
¡¤ There is no write permission for the .ilk file. (LINK ignores
the .ilk file and links nonincrementally.)
¡¤ The .exe or .dll output file is missing.
¡¤ The timestamp of the .ilk, .exe, or .dll is changed.
¡¤ A LINK option is changed. Most LINK options, when changed
between builds, cause a full link.
¡¤ An object (.obj) file is added or omitted.
¡¤ An object that was compiled with the /Yu /Z7 option is changed.

I am suspecting write permission. Can you confirm this point? Thanks. Also,
you may use Process Monitor or FileMon from www.sysinternals.com to check
if you got any file access deny error during the compilation.

Finally, I am not sure if is it possible for you to reproduce this problem
in a little sample project? If so, please feel free to send it to me. It
will make the analysis and troubleshooting more accurate.

I will wait for your further feedback, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Jeffrey,

I'm pretty sure that none of the circumstances that you listed are the cause
here. Why do you suspect write permission? The .ilk file is being created
successfully after all (it is just zero bytes in length). If something is
messing with the permissions on the .ilk file then it is the linker itself,
it isn't me.

I propose that I bundle up the preproc'd source for one arbitrary compiland
and all of the .obj files, import libs and managed assemblies, and give you
a simple little nmake file for compiling the one compiland that I give you
source for and for linking the mixed dll. This will be large, but I could
put it into a zip file on our ftp site. If I do this, you could use it to
effectively debug the link. Do you agree?

-Bern
 
Hi Bern,

Thanks for your feedback.

Ok, you may create this sample with detailed steps to help me local
reproduce. Due to the complexity of this issue, I would recommend you send
an email to me at (e-mail address removed)(remove "online.") to discuss
this issue offline. Thanks.

I will wait for your email, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top