Replacement for #pragma comment(exestr, "this is a string")?

  • Thread starter Thread starter chris_doran
  • Start date Start date
C

chris_doran

/COMMENT has been removed from the linker that comes with VS2005, and
use in source code of:

#pragma comment(exestr, "this is a string")

gives the message:

warning LNK4224: /COMMENT is no longer supported; ignored

and doesn't put the string in the exe file.

Has anyone found a replacement for this feature? I've just wasted time
due to someone compilinq an old version which could have been found
immediately with this facility.

Chris
 
/COMMENT has been removed from the linker that comes with VS2005, and
use in source code of:

#pragma comment(exestr, "this is a string")

gives the message:

warning LNK4224: /COMMENT is no longer supported; ignored

and doesn't put the string in the exe file.

Has anyone found a replacement for this feature? I've just wasted time
due to someone compilinq an old version which could have been found
immediately with this facility.
Click to expand...

I use a compiler flag:
/v
This embeds the string in whatever obj file is being built. The linker
leaves these strings, so they end up in the executable. (I had never
really checked, so working on this note was a good prod for me;
thanks.)

Chris
Click to expand...

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com
 
I use a compiler flag:
/v
This embeds the string in whatever obj file is being built. The linker
leaves these strings, so they end up in the executable. (I had never
really checked, so working on this note was a good prod for me;
thanks.)
Click to expand...

Thanks for the suggestion (it's capital V BTW). It works, but gives the
warning:

cl : Command line warning D9035 : option 'V' has been deprecated and
will be removed in a future release

Why are M$ so against this elementary QA feature?

That aside, I can't see a simple way of including a version number or
date with each object file of a project using /V. With exestr it was
all edited in the C file.

Other ideas appreciated.

Chris
 
Thanks for the suggestion (it's capital V BTW). It works, but gives the
warning:

cl : Command line warning D9035 : option 'V' has been deprecated and
will be removed in a future release

Why are M$ so against this elementary QA feature?

That aside, I can't see a simple way of including a version number or
date with each object file of a project using /V. With exestr it was
all edited in the C file.

Other ideas appreciated.
Click to expand...

You can either add a string as a resource or declare some const string variable.
 
Grzegorz Wróbel said:
You can either add a string as a resource or declare some const string variable.
Click to expand...

I have found that some linkers remove the static char version string because
it is not referenced. I build the same source code with several
compilers/linkers and I have found that the best solution so far (other than
#pragma comment) is to pass the static char version string as a parameter to
an inline function that returns a pointer to the string... kind of a kludge
but it forces the linkers (all that I have tried so far) to link the static
char into the exe.

This goes into each module:
static char *RCSinfo_filename_ext = MyVersion( "my text version" );

This goes into a common header file that is included in each module:
__inline CHAR *MyVersion( CHAR *versionStr )
{
return( versionStr );
} /* MyVersion */
 
SCWoods said:
I have found that some linkers remove the static char version string because
it is not referenced. I build the same source code with several
compilers/linkers and I have found that the best solution so far (other than
#pragma comment) is to pass the static char version string as a parameterto
an inline function that returns a pointer to the string... kind of a kludge
but it forces the linkers (all that I have tried so far) to link the static
char into the exe.

This goes into each module:
static char *RCSinfo_filename_ext = MyVersion( "my text version" );

This goes into a common header file that is included in each module:
__inline CHAR *MyVersion( CHAR *versionStr )
{
return( versionStr );
} /* MyVersion */
Click to expand...

I too had found that the linker optimises out unused strings and had
considered fooling it with a function call. However I'm surprised it
doesn't optimise out your unused code as well, and I expected to have
to use an extern function.

I'm currently experimenting with the "Comments" field in a resource
file associated with the whole program, but I've yet to fully automate
its updating. I don't know how/whether you can embed a resource in each
C file as Grzegorz's post implies. The advantage of the resource file
method is that you can see the list of modules in right
click/Properties/Version on the exe file instead of having to use a
string extractor. One problem is that it doesn't seem to be possible to
force a newline in the "Comments", so the display looks odd.

Chris
 
Back
Top