Compiling source code out of the blue

[Tomás Ó hÉilidhe]

I'd post this on a gcc newsgroup but I'd be more productive talking
to the wall.

Anyway, let's say someone throws some source code at you for a
particular program and says, "Just compile it, it works fine". Now
admittedly, I tend to have a phobia of this situation because I recall
from my Windows days the numerous times I was given code that was
supposedly "good to go", but which failed to compile for some stupid
reason. Of course I like to program, but I couldn't be bothered going
through header files looking for the dodgy definition of DWORD which is
hidden within #if blocks pertaining to the Windows version.

Anyway, pretending I have faith for a moment in receiving a program's
source code to compile to yield an executable binary, I'd just like to
ask how best to compile it "in release mode" using gcc. I don't need
errors or warnings, I just want the executable.

At the moment, I'm unzipping the zip file, opening a command prompt
in the relevant directory and doing the following:

gcc *.c -D NDEBUG -o prog.exe

I'm looking for a gcc command line sequence that does the following:

* Compiles and links all the source files (*.c) present in the current
directory.
* Applies any and all optimisations it wants.
* Doesn't give me warnings (or any output for that matter)
* Strips all the garbage out of the executable (HelloWorld shouldn't be
400 KB)

The method I'm using at the moment does the trick, but still the
executable file is a bit big (roughly 25 KB for a simple-enough program).
Also, I'd like to know that I'm getting all the optimisations that are on
offer.

I'm getting into cross-platform programming lately, compiling
something for Linux one minute and Windows the other, which is why I've
been wondering what's the best "Give Me An Executable" method of using
gcc.

And just out of curiosity, is gcc restricted mainly to normal 8-Bit
byte system, or does it have binaries for all sorts of different systems,
9-Bit ones with padding inside a sign-magnitude int perhaps?

--
Tomás Ó hÉilidhe

[Randy Howard]

On Tue, 1 Jan 2008 22:47:45 -0600, Tomás Ó hÉilidhe wrote
(in article <Xn***************************@194.125.133.14>):

Anyway, let's say someone throws some source code at you for a
particular program and says, "Just compile it, it works fine". Now
admittedly, I tend to have a phobia of this situation because I recall
from my Windows days the numerous times I was given code that was
supposedly "good to go", but which failed to compile for some stupid
reason. Of course I like to program, but I couldn't be bothered going
through header files looking for the dodgy definition of DWORD which is
hidden within #if blocks pertaining to the Windows version.

That can happen with code coming from <any platform>. It isn't fun,
because a blanket statement like "it just works fine", when taken from
code that hasn't been ported already, implies a lot about the person
giving it to you, and almost nothing about the code itself.

Anyway, pretending I have faith for a moment in receiving a program's
source code to compile to yield an executable binary, I'd just like to
ask how best to compile it "in release mode" using gcc. I don't need
errors or warnings, I just want the executable.

You don't need errors or warnings? How can you possibly support that,
/especially/ the former?

At the moment, I'm unzipping the zip file, opening a command prompt
in the relevant directory and doing the following:

gcc *.c -D NDEBUG -o prog.exe

I'm looking for a gcc command line sequence that does the following:

* Compiles and links all the source files (*.c) present in the current
directory.

Makefiles are nice for this for anything but trivially small projects.
If you are getting projects that were built with something like Visual
from MS, the project files are likely to not help you much on other
platforms, so you may have to build some of these yourself, unless you
really like invoking things manually file by file.

* Applies any and all optimisations it wants.

You want the compiler to decide the optimization settings? I'd think a
good starting point might be -O2.

* Doesn't give me warnings (or any output for that matter)

I think this is a horribly bad idea. Usually you want as many as you
can get, especially in an initial port. Later on you may decide that
some aren't going to be addressed, but a lot of broken code will
compile without error, but with meaningful warnings and still generate
a binary.

* Strips all the garbage out of the executable (HelloWorld shouldn't be
400 KB)

Many platforms have a means to do this after linking, try man strip on
UNIX systems, for example.

The method I'm using at the moment does the trick, but still the
executable file is a bit big (roughly 25 KB for a simple-enough program).
Also, I'd like to know that I'm getting all the optimisations that are on
offer.

The gcc compiler has a wide variety of optimization settings, and which
to turn on and off usually require more consideration than just "turn
them all on".

I'm getting into cross-platform programming lately, compiling
something for Linux one minute and Windows the other, which is why I've
been wondering what's the best "Give Me An Executable" method of using
gcc.

I can understand you wanting to apply the KISS principle to minimize
some of it, but I suspect you're going to cause more problems than you
solve by pursuing this path.

And just out of curiosity, is gcc restricted mainly to normal 8-Bit
byte system, or does it have binaries for all sorts of different systems,
9-Bit ones with padding inside a sign-magnitude int perhaps?

http://gcc.gnu.org/install/specific.html

The above addresses some of them, but not all. It should be a good
starting point though. Google should cough up answers for a specific
processor you may have in mind.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Tomás Ó hÉilidhe]

Randy Howard <ra*********@FOOverizonBAR.netwrote in comp.lang.c:

That can happen with code coming from <any platform>. It isn't fun,
because a blanket statement like "it just works fine", when taken from
code that hasn't been ported already, implies a lot about the person
giving it to you, and almost nothing about the code itself.

I tend to be dealing with command-line programs which should be fully-
portable. For example, a program to calcuate a network card's serial
number from its MAC address.

You don't need errors or warnings? How can you possibly support that,
/especially/ the former?

Because the program is know to work perfectly. When developing my own
code, I of course make use of high warning settings... but when I'm given
source code where I'd prefer to receive a binary, I just want to compile
to an executable and be done with it.

Working with Linux, people distribute source code a lot. So much so, that
gcc comes built-in to the operating system. You think you're downloading
a binary for a program, and then when you open readme.txt, it tells you
to do:

make
make install

Makefiles are nice for this for anything but trivially small projects.
If you are getting projects that were built with something like Visual
from MS, the project files are likely to not help you much on other
platforms, so you may have to build some of these yourself, unless you
really like invoking things manually file by file.

What's a makefile? Is it a list of parameters to pass to the compiler? Is
there any standard kind of makefile, or do all compilers have a different
format?

>* Applies any and all optimisations it wants.

You want the compiler to decide the optimization settings? I'd think
a good starting point might be -O2.

Interestingly enough, I compiled by program with -O3 and now the binary
doesn't work properly... I'll look into why.

>* Doesn't give me warnings (or any output for that matter)

I think this is a horribly bad idea. Usually you want as many as you
can get, especially in an initial port. Later on you may decide that
some aren't going to be addressed, but a lot of broken code will
compile without error, but with meaningful warnings and still generate
a binary.

As I said, I would have preferred a binary but I'm left with source code,
so I just want to compile it and pretend I was given a binary to begin
with.

>* Strips all the garbage out of the executable (HelloWorld shouldn't
be 400 KB)

Many platforms have a means to do this after linking, try man strip on
UNIX systems, for example.

I've had a look at "strip" that comes with gcc. What I'm curious about
though, is why this needs to be done at all? Why fill an executable with
crap that it doesn't need? (assuming we're compiling in Release Mode of
course)

--
Tomás Ó hÉilidhe

[Kenny McCormack]

In article <Xn***************************@194.125.133.14>,
Tomás Ó hÉilidhe <to*@lavabit.comwrote:
....

>I've had a look at "strip" that comes with gcc. What I'm curious about
though, is why this needs to be done at all? Why fill an executable with
crap that it doesn't need? (assuming we're compiling in Release Mode of
course)

Compile (or, more precisely - and in this ng, you always gotta be
precise! - link) with "-s". This does the strip as part of the linking.

Note also that the default operation in most Linux-y situations is to
compile with "-g", which puts "all that crap" in there in the first
place. But linking with "-s" will remove it.

Note: Any minute now, someone is going to post an "off topic, can't
discuss it here, blah, blah, blah" message, telling you that makefiles
(and everything else you're interested in) is verboten.

[CBFalconer]

"Tomás Ó hÉilidhe" wrote:

Randy Howard <ra*********@FOOverizonBAR.netwrote in comp.lang.c:

.... snip ...

>

>>What's a makefile? Is it a list of parameters to pass to the
compiler? Is there any standard kind of makefile, or do all
compilers have a different format?

Are you serious?

I get the feeling that makefiles are something I should know
about? I only ever give the compiler a list of source files and
viola I get my executable -- I've never needed a makefile. I
make as well look it up on Wikipedia now while we're on the topic.

Try "info make" or "man make" on your Linux or Cygwin or DJGPP
system. Maybe also Ming.

BTW, please do not remove attributions for material you quote.
Attributions are the initial lines of the form "Joe wrote:". We
have no idea who wrote "What's a makefile?".

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[pete]

Tomás Ó hÉilidhe wrote:

>
I'd post this on a gcc newsgroup
but I'd be more productive talking to the wall.

Anyway, let's say someone throws some source code at you for a
particular program and says, "Just compile it, it works fine".

Crank up the compiler warning level.
Just compile it, don't link it.
See what happens and take it from there.

--
pete

[Stephen Sprunk]

"Toms hilidhe" <to*@lavabit.comwrote in message
news:Xn***************************@194.125.133.14. ..

Randy Howard <ra*********@FOOverizonBAR.netwrote in comp.lang.c:

>You don't need errors or warnings? How can you possibly support that,
/especially/ the former?

Because the program is know to work perfectly. When developing my own
code, I of course make use of high warning settings... but when I'm given
source code where I'd prefer to receive a binary, I just want to compile
to an executable and be done with it.

"known to work perfectly" is rarely conclusive. There are a great many
programs which work fine _on a particular platform, when compiled with a
particular compiler_ but break horribly when you step outside those bounds.

IOW, a program can appear to be correct while relying on implementation- or
even undefined behavior, but that is no guarantee it will continue to work
if ported (even to a new version of the same compiler or OS).

Working with Linux, people distribute source code a lot. So much so, that
gcc comes built-in to the operating system. You think you're downloading a
binary for a program, and then when you open readme.txt, it tells you to
do:

make
make install

Add a "./configure" step at the beginning for most open source programs
these days.

>Makefiles are nice for this for anything but trivially small projects.
If you are getting projects that were built with something like Visual
from MS, the project files are likely to not help you much on other
platforms, so you may have to build some of these yourself, unless you
really like invoking things manually file by file.

What's a makefile? Is it a list of parameters to pass to the compiler? Is
there any standard kind of makefile, or do all compilers have a different
format?

A makefile is processed by the "make" command, and there is a standard
format, at least for UNIX-y systems. If a program comes with a file called
"Makefile", you can start with that and, if compiling fails, usually get it
working with minor changes. If it comes with a program called "configure",
that will build a Makefile for you -- and determine all the dependencies the
program has, adjust for your local environment, etc. If it comes with
neither, then either it's a completely trivial program or (if it comes with
"project" files) it was intended to only work on Windows. The latter is
rarely fun.

If it is a trivial program, here's a good start:

gcc -ansi -pedantic -W -Wall foo.c -o foo

or, if you're serious about not being warned of broken code:

gcc foo.c -o foo

I _always_ create Makefiles for anything larger than a single source file;
it's not tough, and the time spent is recovered within a few
modify-compile-test cycles.

>>* Applies any and all optimisations it wants.

You want the compiler to decide the optimization settings? I'd think
a good starting point might be -O2.

Interestingly enough, I compiled by program with -O3 and now the binary
doesn't work properly... I'll look into why.

That means the code is broken, though it may not show up on the author's
system. Broken code often appears to work correctly if you only use it on a
particular OS with a particular compiler; porting such code can be a
nightmare.

>>* Strips all the garbage out of the executable (HelloWorld shouldn't
be 400 KB)

Many platforms have a means to do this after linking, try man strip on
UNIX systems, for example.

I've had a look at "strip" that comes with gcc. What I'm curious about
though, is why this needs to be done at all? Why fill an executable with
crap that it doesn't need? (assuming we're compiling in Release Mode of
course)

Because you often want to debug "release" binaries when customers find
problems in the field, or when the program mysteriously crashes after you're
"done" working on it. Having that extra info there doesn't hurt
performance, so there's rarely reason to take it out.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

[andreyvul]

On Jan 2, 9:11 am, "Tomás Ó hÉilidhe" <[e-mail]:

Randy Howard <[e-mail] in comp.lang.c:

That can happen with code coming from <any platform>. It isn't fun,
because a blanket statement like "it just works fine", when taken from
code that hasn't been ported already, implies a lot about the person
giving it to you, and almost nothing about the code itself.

I tend to be dealing with command-line programs which should be fully-
portable. For example, a program to calcuate a network card's serial
number from its MAC address.

Show me an ANSI/ISO C way of getting a network card's MAC address.
*NO* OS calls, syscalls, shell scripts, calls to system(), or OS API
functions. Posix functions are maybe.

You don't need errors or warnings? How can you possibly support that,
/especially/ the former?

Because the program is know to work perfectly. When developing my own
code, I of course make use of high warning settings... but when I'm given
source code where I'd prefer to receive a binary, I just want to compile
to an executable and be done with it.

Working with Linux, people distribute source code a lot. So much so, that
gcc comes built-in to the operating system. You think you're downloading
a binary for a program, and then when you open readme.txt, it tells you
to do:

make
make install

Makefiles are nice for this for anything but trivially small projects.
If you are getting projects that were built with something like Visual
from MS, the project files are likely to not help you much on other
platforms, so you may have to build some of these yourself, unless you
really like invoking things manually file by file.

What's a makefile? Is it a list of parameters to pass to the compiler? Is
there any standard kind of makefile, or do all compilers have a different
format?

GNU Make is standard on GNU/Linux distributions.
If in doubt, write a GNU make compatible makefile.

An example:
# Makefile for Tower of Hanoi
# (C)2007 Andrey Vul
# GPL
CFLAGS = -Wall #Enable every single warning
OPTIMIZE_CFLAGS = -O3 -fomit-frame-pointer #speed optimization
CC = gcc #make will be using the gcc compiler

all: towerofhanoi #make (all)

#Remove object files, nano backups and ultraedit-32 backups
clean: #make clean
-rm *.o *~ *.bak

towerofhanoi: compile #linking phase, compile is a prerequisite target
$(CC) *.o -o $@

compile: #create object files
$(CC) $(CFLAGS) $(OPTIMIZE_CFLAGS) -c *.c
#I'm making this up to show an example
install: #make install
cp hanoi /usr/local/bin

>

* Applies any and all optimisations it wants.

You want the compiler to decide the optimization settings? I'd think
a good starting point might be -O2.

Interestingly enough, I compiled by program with -O3 and now the binary
doesn't work properly... I'll look into why.

-O3 is risky. If the code crashes, use -O2.

* Doesn't give me warnings (or any output for that matter)

I think this is a horribly bad idea. Usually you want as many as you
can get, especially in an initial port. Later on you may decide that
some aren't going to be addressed, but a lot of broken code will
compile without error, but with meaningful warnings and still generate
a binary.

As I said, I would have preferred a binary but I'm left with source code,
so I just want to compile it and pretend I was given a binary to begin
with.

The code crashes because you used void* and inputted a float instead
of a struct. The compiler would have warned you about this, but you
chose to disable warnings.

>

* Strips all the garbage out of the executable (HelloWorld shouldn't
be 400 KB)

Many platforms have a means to do this after linking, try man strip on
UNIX systems, for example.

I've had a look at "strip" that comes with gcc. What I'm curious about
though, is why this needs to be done at all? Why fill an executable with
crap that it doesn't need? (assuming we're compiling in Release Mode of
course)

Because it will be far easier to debug.

[Randy Howard]

On Thu, 3 Jan 2008 13:25:14 -0600, andreyvul wrote
(in article
<96**********************************@i72g2000hsd. googlegroups.com>):

On Jan 2, 9:11 am, "Tomás Ó hÉilidhe" <[e-mail]:

>Randy Howard <[e-mail] in comp.lang.c:

>>That can happen with code coming from <any platform>. It isn't fun,
because a blanket statement like "it just works fine", when taken from
code that hasn't been ported already, implies a lot about the person
giving it to you, and almost nothing about the code itself.

I tend to be dealing with command-line programs which should be fully-
portable. For example, a program to calcuate a network card's serial
number from its MAC address.

Show me an ANSI/ISO C way of getting a network card's MAC address.
*NO* OS calls, syscalls, shell scripts, calls to system(), or OS API
functions. Posix functions are maybe.

Yes, but that's not what he wrote. He may have meant that, but what he
wrote seems to imply that

int calc_serialnumber(const char *MAC_Address);

could be all that is required, employing some algorithm to extract
serial number from the MAC Address string passed to it.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Gordon Burditt]

That can happen with code coming from <any platform>. It isn't fun,

because a blanket statement like "it just works fine", when taken from
code that hasn't been ported already, implies a lot about the person
giving it to you, and almost nothing about the code itself.

I tend to be dealing with command-line programs which should be fully-
portable. For example, a program to calcuate a network card's serial
number from its MAC address.

Show me an ANSI/ISO C way of getting a network card's MAC address.
*NO* OS calls, syscalls, shell scripts, calls to system(), or OS API
functions. Posix functions are maybe.

printf() followed by fgets(). Or look at argv[]. The post did not
say the network card in question is one connected to this computer,
and even if it is, you can prompt for the MAC address.

Presumably if you CAN calculate a network card's serial number from
its MAC address, there's either a database of them or there's some
formula for brand X (it is likely that the person using the program
works for the manufacturer or distributor of Brand X network cards)
network cards that relates the two.

[Tomás Ó hÉilidhe]

go***********@burditt.org (Gordon Burditt) wrote in comp.lang.c:

Presumably if you CAN calculate a network card's serial number from
its MAC address, there's either a database of them or there's some
formula for brand X (it is likely that the person using the program
works for the manufacturer or distributor of Brand X network cards)
network cards that relates the two.

Exactly, there's a particular brand of ADSL router where the MAC
address can be determined from the serial, and vice versa. I don't actually
work for the manufacturer though.

--
Tomás Ó hÉilidhe