Antwort: Re: [Mod_gzip] mod_gzip on Mac OS X

[mod_gzip@lists.over.net]

Hi Tom,


> One thing I don't understand and haven't been able to find any
> definitive guide for is all the compiler instructions at the
> start of the call. I'm guessing that they're probably optimized
> for x86 architecture, given that's what most people will be using.
>
> I'm sure this is likely beyond the scope of this list, but would
> anyone like to comment on what these commands actually do and if
> there's anything different I might wish to do when compiling on
> a G4? Any magic switches to enable altivec processing?

first of all, apxs is nothing but a Perl script whose source
code you may read if you want.

Secondly, apxs itself is being generated during the Apache
compilation. Thus parts of this script will already be created
platform dependent, inheriting compiler and linker dependent
switches from the Apache compilation process.
You must not rely even the same apxs call to do exactly the
same thing on different platforms, but eventually this is ex-
actly what you want: apxs is trying to do what's "appropriate"
for
- this platform,
- the C compiler and
- the linker
that "configure" previously detected.

The Apache group provides a manpage documentation about apxs
to explain which options are supported in general:
     http://httpd.apache.org/docs/programs/apxs.html

Most options that Christian explicitly added to these look
dependent on using the specific C compiler, which might well
be a gcc on any platform you run your Apache on.

As for the options that Christian used in his Makefile:

# -Wall,
"All of the above -W options combined. This enables all the warnings about
 constructions that some users consider questionable, and that are easy to
 avoid (or modify to prevent the warning), even in conjunction with macros.
 This also enables some language-specific warnings described in C++ Dialect
 Options and Objective-C Dialect Options."
(from the gcc user manual - this is controlling the display of
 warnings during compilation, but has no effect on code generation.)

# -O3,
tells the C compiler to use optimizer level 3.
Definitely depends on the C compiler being used; gcc supports
level up to 9, but they are said to become increasingly
"dangerous" in a sense because they try to optimize loops
and the like, thus sometimes changing the semantics of programs.

# -fomit-frame-pointer,
"Don't keep the frame pointer in a register for functions that don't need
one. This avoids the instructions to save, set up and restore frame
pointers; it also makes an extra register available in many functions.
It also makes debugging impossible on some machines.
On some machines, such as the VAX, this flag has no effect, because
the standard calling sequence automatically handles the frame pointer
and nothing is saved by pretending it doesn't exist.
The machine-description macro FRAME_POINTER_REQUIRED controls whether
a target machine supports this flag. See Register Usage.
Enabled at levels -O, -O2, -O3, -Os."
(from the gcc user manual - this sounds like triggering some
optimization during code generation)

# -pipe
"Use pipes rather than temporary files for communication between the
various stages of compilation. This fails to work on some systems where
the assembler is unable to read from a pipe; but the GNU assembler has
no trouble."
(from the gcc user manual - this seems to speed up the compilation
process but requires an assembler able to support that type of
communication)

# -c mod_gzip.c mod_gzip_debug.c mod_gzip_compress.c
lists the set of source code files to be compiled into the
mod_gzip module.
This has been one file only back in 1.3.19.1a and earlier, but
for sake of clarity Christian and myself decided to split the
module between Apache stuff, debugging stuff and the gzip emu-
lation module.

# -o mod_gzip.so
tells the linker to create a shared object file of this name.
Thus might well be linker dependent, and thus explain why you
needed to change this on your machine.



I took these informations from
     http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/index.html


Regards, Michael