Re: optimisation??
Horvath Akos Peter wrote:
> I've seen quite a couple of packages, and was not too happy when I see
> the -O2 -g cflags, with which was compiled.
>
> 1. Why do you use the -g flag? A simple user will NEVER debug a binary.
> But wants it to run fast and be small. Because of the -g flag gcc will be
> unable to perform some optimisations, and this does not make sny sense
> since all binaries will be stripped - undebuggable with -g too.
The -g is there to aid developers debug their package when they're building
it. As you note the files are stripped prior to going into a .deb.
The gcc man page explicitly says that gcc unlike most compilers does not
disable any optimizations when -g is used.
> 2. Why use just -O2? The egcs people have been working for years to make
> the compiler better. For us (too). -O6 makes faster binaries.
-O2 is documented as being all optimizations that don't involve time/space
tradeoffs. Higher -O levels have been known to generate invalid or buggy code.
> 3. Why don't you use the -fomit-frame-pointer flag? The reasons are the
> same as in 1.
-fomit-frame-pointer is documented as making debugging impossible.
> 4. What is the reason behind chmod -x the shared libs? With it, the so-s
> will be un-ldd-able -> dephelper have hard time to find out the
> dependencies, and nobody will be able to find out, what shared libs is
> needed by another. I do not see any reason to make this. I use chmod +x
> {,/usr}/lib/* after every update, and my system works perfectly.
ldd works on non-executable .so files with no difficulty. There's a warning.
Actually running a shared library directly tends to cause an immediate core
dump, so it's pretty silly to put an executable flag on it.
> 5. I think it would be better if the debian/rules had a new target rule,
> named config. -> no need to rerun the configure script if whenever
> somebody wants to rebuild a .deb more than once.
This can be accomplished other ways, like using stamp files. Many packages
do. Anyway configure scripts cache their results so there's little overhead
to running them a second time.
> 6. Why are static libs in the -dev packages? Nobody needs static
> libraries. It is an archaic thing, and (except in very interesting
> situations) are not needed. (Or should gone to some -static packages).
Consider if you're building something on a system and want to move it over
to a system running a different incomaptible libc, and you're in a hurry. Or
if you want to throw a few programs on a disk and know they'll work even if
you FUBAR your system.
For that matter, consider if you're a commercial software company and want
to make one binary that will work on all linuxes. The sad fact is using
static libraries can still be seen as a decent compromise in that situation.
They've in the -dev packages because nobody much has to install the -dev
packages.
> 7. My opinion: the most correct solution would be if the debian/rules
> could handle CFLAGS and CXXFLAGS environment variables even if the
> standard compilation scripts did not handle them - but would use -O6
> -fomit-frame-pointer as default.
Do you propose that we rewrite the standard compilation scripts of every
package in debian? Even modifying them all to use CFLAGS would be a large
task. I suggest you look at the pentium-builder package for a hack that
allows you to force flags be turned on no matter what. (Oh yeah, and _read_
the gcc man page and thing for a second before throwing out so many
questions that are answered in it.)
--
see shy jo
Reply to: