Yes,I was wondering what information does the program contain regarding the compiler that compiled it.
Information like compiler name,version.This is usually mentioned in about box of help(program like Vlc) menu,but my question is does compiler write any thing to .exe.
The reason i am asking this is to get information regarding the compiler by disassembling the program in any disassembler(IDA,OLLY).
Since you specifically mentioned VLC, the player is doing it in the following way: In line 50935 (at least on my VLC source package, which is 2.1.4) in the configure script there is the following statement:
cat >>confdefs.h <<_ACEOF
#define VLC_COMPILER "`$CC -v 2>&1 | tail -n 1 | sed -e 's/ *$//'`"
_ACEOF
which as you can see updates the confdefs.h file with the version of the compiler. Indeed, if you execute the statement:
$ gcc -v 2>&1 | tail -n 1 | sed -e 's/ *$//'
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
later this confdefs.h is "injected" in config.h and the line there will be 683 (for me and my compilation only, this might be different for you but you need to look after VLC_COMPILER)
/* compiler */
#define VLC_COMPILER "gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)"
And when VLC wants to print out the compiler it simply prints this string (in version.c there is the VLC_Compiler() method defined which returns this.
And to finally answer your question: I sort of remember that some (older) versions of Borland compilers (Turbo C) injected a copyright information, however I did not experience this in any recent compilers, however this does not mean that they do not. This is compiler specific, and there is nothing that makes them or stops them doing this. In the worst case you always can look at the binary via a (hex) viewer to see anything funny...
Related
I am trying to detect Solaris/SunOS version at compile time so that I can enable/disable use of port_create() and other APIs.
Is there a header identifying SunOS/Solaris version at compile time?
If no header is giving you this information, you could of course parse the output of uname and generate -D preprocessor option(s) from your build script/makefile/...
Elaborating upon the suggestion by #meaning-matters, one can make a compile-time definition, say SUN_VERSION using the output of uname -r. That actually gives a floating point number, e.g., 5.10, which you could convert into a preprocessor-comparable form using a simple sed command, e.g., this compiler option:
-DSUN_VERSION=`uname -r | sed -e 's/\.\([0-9]\{1,1\}\)$/0\1/' -e 's/\.//'`
produces 510 for 5.10, 509 for 5.9, etc.
In your source program, you could use it like this
#if SUN_VERSION >= 510
(or whatever makes sense).
Identifying the OS release in order to assert an API is available or not is risky if not doomed. You cannot assume an API will stay in future releases nor if it is available in a parallel branch (eg. Illumos vs Solaris 11 which are both reporting SunOS 5.11 as their version).
The usual way to overcome this issue is simply to check if the API is available by compiling a small test source code to figure it out. This is usually done in a script traditionally named configure that builds a Makefile and an include file tailored to your system.
To expand upon #meaning-matters answer, use GNU make, and set a variable to the OS version. Pass that variable on to the compiler using the -D command-line option.
Makefile:
OS_VERSION := $(shell uname -r)
version:
$(CC) -DOS_VERSION=$(OS_VERSION) version.c -o version
test:
echo $(OS_VERSION)
version.c:
#include <stdio.h>
#define STRINGIFY(x) #x
#define TOSTRING(x) STRINGIFY(x)
int main()
{
printf( "OS Version: " TOSTRING(OS_VERSION) "\n" );
return( 0 );
}
Output:
bash 4.1$ gmake test
echo 5.11
5.11
bash 4.1$ gmake version
cc -DOS_VERSION=5.11 version.c -o version
bash 4.1$ ./version
OS Version: 5.11
bash 4.1$
Use := (assign if not already set) to only run the uname command once.
That will show "5.10" for Solaris 10, "5.11" for Solaris 11.
I have a user report (unfortunately can't verify it due to lack of appropriate machine) that the C preprocessor (cpp) command on Mac OS X 10.6.4 doesn't remove C++/C99 double slash // comments from files it processes, no matter what option it's given. This is the gcc version:
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)
Is it possible to somehow cause it to remove such comments, as one would expect from a C++ preprocessor (this is needed because cpp is used as part of another tool).
I've found a formula that works with the cpp command: try cpp -xc++ (note the lack of spaces between -x and c++).
$ printf '/* block comment */\n// line comment\nnot a comment\n' | cpp -xc++
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"
not a comment
contrast:
$ printf '/* block comment */\n// line comment\nnot a comment\n' | cpp -x c++
i686-apple-darwin10-gcc-4.2.1: c: No such file or directory
i686-apple-darwin10-gcc-4.2.1: c++: No such file or directory
i686-apple-darwin10-gcc-4.2.1: warning: '-x -x' after last input file has no effect
i686-apple-darwin10-gcc-4.2.1: no input files
Now '-x c++' is SUPPOSED to work, and DOES work on my Linux box (with gcc 4.4, but I recall it working as long ago as gcc 2.95) so it seems that Apple broke it.
I really must reemphasize the importance of providing a complete, precise test case for questions like these. It did not occur to me yesterday to look for Apple having introduced a bug, because I know that wilx's answer should have worked, and in the absence of a precise description of what the OP's user tried, it was far more likely that they had something else on their actual command line that was negating it. If the command line and error messages I show above were provided in the original question, that would have targeted everyone's attention much more effectively.
Try adding either -x c++ or -x c -std=c99 to the command line.
One partial solution that appears to work is invoke gcc -E instead of cpp.
-E Preprocess only; do not compile, assemble or link
This indeed strips // comments on Mac OS X.
However, I'm still curious why there are problems with cpp itself.
I am used to use what to find out some version string in my program, which is normal defined as a string in the c++ code, starting with "#(#)".
Now I cannot find it in Linux. Can anyone tell me what I am supposed to do? Thanks a lot!
The what command is part of the Source Code Control System (SCCS), which is not commonly available on Linux (if there is a Linux version at all). You can try to emulate it with the strings command:
strings a.out | fgrep '#(#)'
Reimplementations of what are available in CSSC (an SCCS-to-modern version control conversion package) and in BSD (source code).
try this
strings myprogram | grep '#('
As #larsmans said, what command is part of SCCS. Here is the link to the GNU replacement for SCCS
Additionally to the mention of SCCS, ident is the equivalent for RCS (and there are quite a few tools which use the same marker as RCS, CVS being the first one of these).
The following command gives most equivalent output compared to what
strings filename | grep -o \"\"#(#).*\"\" | sed 's/^\"#(#)//' | sed 's/\"$//'
I'm trying to build Amaya. When the build failed with
error: expected unqualified-id before ‘(’ token
I ran g++ with only the preprocessor (replacing the -c option with -E) on the file that failed to compile to see what was going on. This produced an 80,000 line file, showing me that 'Blue' had been replaced by (2 << 8), which clearly explained the error. If I correct this, the file compiles fine. I guess I could live with that, but I would like to find out why this is happening.
Is there any way I can track how the preprocessor is replacing a specific string, in this case 'Blue'?
================= Update ===================
Well, I found the culprit:
> headers=`g++ [omited for brevity] -M \
../../thotlib/dialogue/AmayaClassicNotebook.cpp`
> for file in $headers ; do grep -s -H Blue $file | grep "(2 << 8)";done
/usr/local/include/gc.h:#define Blue (2 << 8)
So adding #undef Blue fixed the problem. So using this combination of -M and grep seems OK but sometimes C++ preprocessor definitions can be a real forest; I was curious whether there were some better way, some clever GNU tool maybe.
I find running
g++ ... -dD -E $file > $file.ii
to be very useful in untangling preprocessing problems. From man g++:
-dD Dump all macro definitions, at the end of preprocessing,
in addition to normal output.
If nobody comes up with anything better (based on the source line info in the preprocessed file), you could use the -M option to get a list of headers included by the source file, and search those for "Blue". I expect it's possible for some kind of obfuscation to mean that this doesn't find what you're looking for, but normally you'll turn up the definition somewhere.
What's wrong with the perennial
find /src -exec grep Blue {} /dev/null ';'
That usually works for me, at least as a first cut.
For some long errors, the gcc output is dense and has lots of line-wrapping etc. Especially when errors are subtle, it can take me 10-30 seconds of squinting to parse it with my eyes.
I've taken to pasting this in an open code-editor window to get some basic syntax highlighting and enable reformatting with regex's.
Has anyone invented a more automated method?
I use this script, called colorize:
#!/bin/bash
while read x ; do echo $x ; done \
| sed -e "s/.*error:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/.*warning:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/^\(.*\)\(required from\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In instantiation of\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In member\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
| sed -e "s/error:/\x1b[1;31m&\x1b[1;36m/" \
-e "s/warning:/\x1b[1;35m&\x1b[1;36m/" \
-e "s/note:/\x1b[1;30m&\x1b[0m/"
Then I just call it like this(using make or whatever build system):
make |& colorize
And I get color output similar to clang.
I've found colorgcc to be invaluable. By introducing coloring, it becomes much easier to mentally parse the text of gcc error messages, especially when templates are involved.
If your errors are template related, take a look at STLfilt:
http://www.bdsoft.com/tools/stlfilt.html
gccfilter does coloring & simplification of messages.
http://www.mixtion.org/gccfilter/
If you use GCC 4.9, you can add -fdiagnostics-color=auto as an additonal compilation flag. At some later version, the color has been enabled by default.
check diagcc out, you can get something like this:
If your gcc ≥ 4.9, you can use argument -fdiagnostics-color=always.
To answer your question 4 years later, clang should be mentioned here.
Here's my current hack, which mostly inserts newlines and indentation in strategic locations along with a little extra annotation, but does nothing to address STL verbosity.
Note that as currently implemented, this script does not return an error if the compiler returned one, so doing something like this will not work properly: (make && ./runApplication). This could surely be remedied by someone with better bash-fu.
#!/bin/bash
# SUBSTITUTION RULES:
# Note: All substitution rules must end in a semi-colon, inside of the closing quote
subColonSpace='s/: /:\n /g;'
subSrc='s/^src/\nsrc/;'
subError='s/error:/error:\n\n======================================\nERROR:/;'
subWarning='s/ *error: *\n/ERROR: /;'
subWarning='s/ *warning: *\n/WARNING: /;'
subNote='s/note:/\n NOTE:/g;'
subOpenTic='s/‘/\n ‘/g;'
subOpenParen='s/(/(\n /g; s/(\n *)/()/g;'
subCommaSpace='s/, /,\n /g;'
# Note: The order of these may matter
sedExpr="$subColonSpace $subSrc $subError $subWarning $subNote $subOpenTic
$subOpenParen $subCommaSpace"
makelogFile=makelog.tmp
make "$#" 2>&1 | sed "$sedExpr" | tee $makelogFile
if you like Ruby there is GilCC! GilCC is very easy to install (just copy it to the bin folder) and easy to use (just type GilCC instead of "gcc" or "make") and it works with GCC version. Unlike Perl based scripts GilCC has statistics such as # of warnings and error and compile time. You don't have to mess with .bash files and it is cross platform as long as you can run Ruby on your machine. Since it has the power of Ruby; you can make GilCC do different things such as trigger test automation, unit test or program external hardware after a successful build.
Here is the link to the download page: http://www.onlysolutionssoftware.com/gilcc/