A couple of platform compatibility issues...

Jeremy Herbison herbie at autobotcity.net
Sun Jan 5 15:08:08 PST 2003

The difference between -O3 and -O2 is mostly that -O3 unrolls all loops of
known length at compile time, resulting in larger but sometimes faster
binaries. The thing is, most well-written software (such as the linux kernel
for instance) tends to use inline functions where necessary anyhow, so even
with -O2 those functions are inlined as the developers intend. My assumption
is that some packages do not use any inline funtions in the source code, so
they often benefit from -O3, and many of these infact use -O3 by default (I
know for a fact that openssl is like this and runs MUCH faster with -O3.
mysql also recommends compiling with -O3). As a rule I therefore personally
compile with -O2 unless a package defaults to -O3.

Since we don't recommend anything other than default compile flags though,
lets just not mess with this one k? :)

"Kelledin" <kelledin+LFS at skarpsey.dyndns.org> wrote in message
news:200301051620.48624.kelledin+LFS at skarpsey.dyndns.org...
On Sunday 05 January 2003 05:44 am, Greg Schafer wrote:
> I agree that the shared lib needs to be compiled with -fPIC
> and thus don't object to your proposal.
> But I will say that the current build instructions are not
> quite kosher. Look at any libtool using package. Libtool might
> be a "piece of crap" but at least it does the right thing:-
>   code for shared *.so libs gets compiled with -fPIC
>   code for static *.a archives gets compiled normally (ie:
> without -fPIC) in other words, the same object file gets
> compiled twice
> Keeping that in mind, I'm sure the zlib instructions could be
> made a bit more "correct".

Possibly...but it would probably involve either specifying a
long-ass CFLAGS on the make command line, or compiling zlib
twice.  Considering that libtool takes the latter approach, we
probably should do the same thing...

> On a side note, I note that some people (Debian for instance)
> go out of their way to compile all their shared libs with
> -D_REENTRANT. I always thought -D_REENTRANT was related to
> threading. What are your thoughts on that?

AFAIK, -D_REENTRANT doesn't fix anything platform-specific--if it
fixes or breaks something on one platform, it will generally do
the same thing on another platform.  So unless -D_REENTRANT (or
lack thereof) breaks something, we should just let the original
maintainer decide if it's necessary.

> On another side note, the zlib package defaults its
> optimization to -O3 which is probably not good with latest
> gcc's (at least according to my very unscientific
> decompression tests :-)

Hmmm...does it just hurt performance in some cases, or does it
actually introduce erroneous behavior?  I've been letting zlib
build with -O3 for a while now with no problems...but I'm not in
the habit of benchmarking it.

"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list