[anthonyi]

I've just started out with Linux (Fedora Core 2) and have been experimenting with compiling from SRPMs. I noticed on compiling xmms that the resulting executable file is much bigger than that installed by the rpm itself.

I guess this means that I'm missing something out. I just ran the .configure, make and make install.

Can anyone help me understanding this?

Also, I want to be able to specify a particular CPU when compiling (athlon-xp). How should I accomplish this?

Any help would be much appreciated.

[taeuler]

I'm not sure about the size; it probably has to do with how dependancy and compile options are handled. Look in /etc/make.conf, for specifying a cpu. I think you should have that file, although it may be specific to the Gentoo districution. If you have it set:

CFLAGS="-march=athlon-xp -pipe -O2"
CXXFLAGS="${CFLAGS}"
CHOST="i686-pc-linux-gnu"

Those variable should be in make.conf, just change their values. Non-Gentoo users please correct me if I'm wrong about make.conf.

[anthonyi]

Hmmm...I don't seem to have a /etc/make.conf file and a quick look didn't turn one up elsewhere.

So either I'm missing one that I should have, the make config is handled elsewhere or I'm just looking in the wrong place. Would a fellow FC2 user be able to point the way?

Thanks!

[martouf]

try running 'strip' on the xmms executable, and then compare sizes again.

[anthonyi]

Thanks martouf.

'strip xmms' did the trick...although I'm not quite sure what 'strip' does, even after reading the man page? Should 'strip' be applied to all executables that I compile on my machine?

[blackpage]

gidday anthonyi

re "strip": In short, this little program deletes all symbols from executable files. What does this mean?

During the development of an application you have to go through certain stages:

a) Writing source code: In this step you write functions, declare variables and constants, create or import external modules and do a whole lot more stuff.

b) Compiling: During this step the compiler program transforms the written source code into machine readable code (called "object code"). For the next step (linking, see below), and if you want to do some debugging later on, the compiler will add symbols and/or additional debugging information to the translated source code. E.g. if you declared some variable like "int a;", the additional debug info would read like this: "<a> is a 4 byte wide integer value to be found at memory address <module start address> + <offset of variable storage section> + <offset to a>". Of course, compilers and linkers (see ©) won't write stuff like that into any object code file. But what they actually write can be later be evaluated to the above.

c) Linking/binding: After the steps (a) and (b) you have a machine-readable thingie, but this is still no executable. For this to happen you will need to launch the linker. A linker (nomen est omen) "links" together all the pieces of object-code and creates program file that can be launched from the shell.

"Relocatable" means that the operating system can load the program to any place in the memory and it will still work (that was not always the case, and programmers at my age will still remember the days of "absolute" start-code . The linker uses the additional infos from the compiler to achieve this.

As you can see, a whole lot more is done in such a cycle than just to bring some code-lines into machine readable form. In the object code and also the final executable many symbols are still included. And this is where strip comes in ...

Strip removes such additional information (e.g. line numbers, unnecessary relocation info etc.etc.) thus reducing the size of the binary file.

And to answer another one of your questions in brief: No, you don't have to do a strip on every program you compile, unless the size of the executable would suggest it.

Besides: The size of executables also depends on your optimization settings (e.g. "-O3", the best optimazation, or "-O1" for medium optimization; just check the CFLAGS/CXXFLAGS settings in your environment by doing an "env | sort" on the shell). Highly optimized binaries will always be noticably bigger than less optimized executables. It is also a thing which compiler you are using. The intel compilers for instance are legendary for their fast code, but also for their enormous executable-sizes if all optimizations are activated.

hope this helps

[anthonyi]

Excellent, thank you for that. My programming experience is limited to BASIC, Fortran and Pascal and I'd never come across this before.

I did use -O3 to compile xmms - just for fun and to see the results!

I don't have the enivronment variables you mention (ie they don't show in an 'env | sort' either as a user or root). Is that default behaviour for FC2?

Thanks to all for the assistance.

Anthony
[Edited by anthonyi on 2004-07-30 11:39:38]

[blackpage]

'lo again anthonyi,

re:CFLAGS/CXXFLAGS. That was in fact my bad there. It's basically not common to set those environment variables during OS installation, at least they are not set to anything very specific that one might consider "tweaked".

As you use these flags to globally tweak the compiler optimizations to your needs and also to your machine's specs most OS installers - if they set the env-vars at all - will stick to rather basic CFLAGS-settings that would not compromise the stability of the app or the system.

But you can of course add those entries to one of the files that define your environment. /etc/profile or /etc/bash_profile are such files where you can add the entries globally (= for all users). Other options would be the file .bashrc in your home directory.

About what to set the CFLAGS/CXXFLAGS to I can only refer to Google. An example setting for a highly optimizing setting on an AthlonXP machine would look like this ...

export CFLAGS="-march=athlon-xp -pipe -O3 -fomit-frame-pointer"
export CXXFLAGS="${CFLAGS}"


(last line means "use value of variable $CFLAGS")

hope this helps

[blackpage]

Addendum ..

Almost forgot to mention that many "make"-files contain compiler directives for optimizations ... so generally in most cases some form of optimization option is always given to the compiler regardless if you have set CFLAGS/CXXFLAGS or not.

-fin-

[martouf]

tip o'the hat to blackpage for the documentary answer

a more concise and concrete answer to "what does strip do?" is it strips out
all helpful debugging information embedded in the program image.

If all your programs are bug-free, then you can go ahead and strip them all. 8)

Either that, or when you are certain you won't be doing a postmortem on the program
even if it does crash, then you strip it.

[anthonyi]

Guys,

Excellent. Thanks again for the help; just what I needed to know!

Cheers,
Anthony