Bug 32930 - apxs cannot run from DESTDIR specified in 'make DESTDIR=xyz install'
apxs cannot run from DESTDIR specified in 'make DESTDIR=xyz install'
Status: RESOLVED WONTFIX
Product: Apache httpd-2
Classification: Unclassified
Component: Build
2.0.52
Sun Solaris
: P2 major with 1 vote (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-01-04 05:04 UTC by John Kavadias
Modified: 2012-05-01 20:22 UTC (History)
1 user (show)



Attachments
Patch for apxs program's DESTDIR support for Apache httpd 2.2.4 (5.48 KB, patch)
2007-04-26 06:59 UTC, Aron Ujvari
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Kavadias 2005-01-04 05:04:11 UTC
httpd 2.0 build has a 'regression' compared with httpd 1.3 build.

apxs for httpd 2.0 now has the --prefix=/your/required/install/location path
value embedded in it in several places.

This means that if you do this during the httpd 2.0 build:

$ configure --prefix=/your/required/install/location <other options for mod_'s>
$ make
$ make DESTDIR=/your/required/staging/location install

and then try to run apxs from within the staging location when building, say,
mod_jk as a DSO, the mod_'s build dies because apxs cannot run because it is not
actually under the /your/required/install/location directory.

This makes it impossible to provide the mod_'s as DSO's in a binary distribution
on 'ourbuildhost' but distributed to users to simply unload on their 'runtimehost'.

With httpd 1.3 we were able to run apxs successfully from within the directory
/your/required/staging/location/your/required/install/location, which resulted from:

$ make install root=/your/required/staging/location

The custom 'config' based build of httpd 1.3 supports 'root' and apxs was 'root
aware' (probably due to implementation).

The 'configure' based build of httpd 2.0 supports 'DESTDIR' (due to configure)
and apxs is not 'DESTDIR aware'.

We want to do this because the users' systems do not have build tools (ie gcc,
gmake, autoconf, libtool, all that stuff) and cannot build httpd and mod_'s from
source.

Another reason we do this is so that installing httpd and mod_'s does not take
tens of minutes (on large, fast system) to hour or more (on small system). We
take that hit at the 'factory' to make life easier for our users and support staff.
Comment 1 Paul Querna 2005-01-04 05:19:17 UTC
As a possible work around to note for this bug: You can compile apache modules
without using APXS.  Just compile them into a shared object, like a normal library.
Comment 2 Joe Orton 2005-01-04 22:02:27 UTC
Software installed in a DESTDIR root should be be expected to work correctly
until  relocated into the real $prefix.  It's really not worth increasing the
complexity of the build system to cope with this obscure case.  You can munge it
manually if you really need be; it probably just needs the path to
config_vars.mk fixing.  

Alternatively, to generate the binary modules simply build them against the
properly installed httpd on the build host.
Comment 3 Joe Orton 2005-01-04 22:03:08 UTC
s/should be be/should not be/, of course ;)
Comment 4 John Kavadias 2005-01-05 07:35:28 UTC
(In reply to comment #2)
> You can munge it manually if you really need be; it probably just needs
> the path to config_vars.mk fixing.

I tried. The prefix path is embedded in a moderate number of places in the
perl code of apxs. If I remember rightly, it is all through config_vars.mk
itself. It became a losing proposition.

The next suggestion occurred to me also. It is very pragmatic (tick).

> Alternatively, to generate the binary modules simply build them against
> the properly installed httpd on the build host.

This has the 'down side' of requiring a 'prefix correct' installation of
a 'bootstrap version' what you are currently building (httpd) in place on
the build host.
However after bootstrapping the host things should go smoothly until any
tool in the 'prefix correct' installation and required by a build becomes
out of date.

Unfortunately for me doing this in our development shop has its problems.
Oh well.

> ... not worth increasing the complexity of the build system to cope with
> this obscure case.

The complexity would all be in apxs? It may simply consist of a 'destdir'
value that is prepended to any value normally initialised to the '--prefix'
dir when apxs perl code is generated by the build.

The destdir value could be provided by a command line option, and default
to the empty string if not provided.

Without looking at all the apxs perl this idea could be all wrong, but it
has a shot.

Comment #1 is valid, but doesn't it mean that, on a mod_ by mod_ basis, you
must manually perform the work bundled in apxs?

Presumably http://httpd.apache.org/docs-2.0/dso.html contains all I need to
know.

Does it mean the underlying lib???.so for the mod_??? must be prepared with
libtool rather than just ld? (this question displays ignorance of libtool)
Comment 5 Aron Ujvari 2007-04-26 06:59:01 UTC
Created attachment 20050 [details]
Patch for apxs program's DESTDIR support for Apache httpd 2.2.4

The patch is completly backward compatible in case of DESTDIR environment
variable is not set.

DESTDIR support can be easly used by setting the DESTDIR environment variable
before calling the script. No libtool, or *.mk file modification is needed.

Since it has no downside if it is not used, please include it in the next
apache releases.

Best,
Aron Ujvari
Comment 6 Archie Cobbs 2009-06-17 14:11:29 UTC
Why won't you fix this bug?

Every Linux distribution that packages modules as RPMs (which is most of them) has to deal with this annoying bug, because as RPMs get built they install into temporary directories.

Being DESTDIR-aware is totally standard for programs that install things.

Stating that "just don't use apxs" is a valid workaround is equivalent to saying "apxs is not useful", which is not true. For example, it hides a bunch of platform-specific stuff.

A valid patch has been provided.

I don't get it.
Comment 7 Archie Cobbs 2009-06-17 14:14:24 UTC
Just to clarify my previous comment: I am referring to simply adding basic DESTDIR support, which is what the patch does. I don't really care if the installed stuff is usable within the temporary directory (that requirement is unreasonable IMHO).
Comment 8 Wim Lewis 2012-05-01 20:20:13 UTC
I too spend a fair amount of time working around this deficiency in apxs.