fail to compile on standard archlinux install

[ririsoft]

Hello,

I would like to package modsecurity-apache for Archlinux but I am encountering the following issues :

./configure --prefix=/usr --with-libmodsecurity=/usr/lib
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
configure: looking for Apache module support via DSO through APXS
configure: found APXS at /usr/sbin/apxs
configure: looking for libmodsecurity
configure: error: couldn't find libmodsecurity

make DESTDIR="$pkgdir/" install
...
/usr/share/apr-1/build/libtool --mode=install install ./src/.libs/mod_security3.so /usr/lib/httpd/modules/
libtool: install: install ./src/.libs/mod_security3.so /usr/lib/httpd/modules/mod_security3.so
install: cannot create regular file '/usr/lib/httpd/modules/mod_security3.so': Permission denied
apxs:Error: Command failed with rc=65536

The workaround for configure is :

V3LIB=/usr/lib/libmodsecurity.so ./configure --prefix=/usr --with-libmodsecurity=/usr/lib

The workaround for install is to patch the makefile to remove the -i flag of the apxs command and do a manual copy to the expected destination.

Could you consider fixing the configure script, please, and honor the DESTDIR variable at make install stage ?

Thank you very much in advance !
Cheers.

[zimmerle]

Hi @ririsoft,

It seems like we have two different problems:

1. Not automatically detecting libmodsecurity

What was the path that you have used to install libmod?

2. Not being able to install mod_security3.so

Did you executed make install as root?

[zimmerle]

Closing this issue as it seems that it was already sorted by the user.

[ririsoft]

Hello,

My point is that the makefile is using a hardcoded path for the installation destination through its usage of apxs. This does not ease the work of distro packagers who cannot use make install to compile/install the package in a temporary folder at packing time. Distro packagers have to do the install steps manually in a script attached to the package recipe. They have to maintain this script at each release of modsecurity to ensure the installation steps is not missing something.

It would be really great that the makefile supports the DESTDIR variable so that packagers (and users) can install the module in an alternate directory using the command make DESTDIR="/opt/other/install/destination" install.

Sorry for the confusion, this issue is more a feature request than a bug report.

[zimmerle]

That is related to the work that @airween is doing on #51.

[airween]

@ririsoft could you check this solution before I send the PR?

https://github.com/airween/ModSecurity-apache/tree/smallfixes

You can use it:

autoreconf --install
./configure

OR with optional arguments:
./configure --with-apache=/path/to/httpd --with-apxs=/path/to/apxs

Then you can type:

make
make test

The last step configures the temporary httpd, load necessary modules, and run the tests (where the run system also configured by your configure arguments).

[ririsoft]

Hello @airween

./configure works now, thank you very much.

However I still cannot use DESTDIR or any other variable to customize the installation directory for make install in a distinct folder prefix as the one for ./configure --prefix
As a packager here is my standard workflow

autoreconf --install
./configure
make
DESTDIR=/home/foo/bar/tmp/pkg make install

./configure --prefix usage should only be used for changing the way the package is going to be installed at installation time by the distribution package manager.

DESTDIR is used at make install stage to install the files in a temporary directory which the packaging build system is going to use to build a binary tarball for the package.

DESTDIR and --prefix are two different things for a packager.

What do you think ?
Cheers.

[airween]

Hi @ririsoft

I've never used DESTDIR, but after a quick check it looks like make supports DESTDIR argument only with "install" or "uninstall" arguments:

https://www.gnu.org/prep/standards/html_node/DESTDIR.html

DESTDIR should be supported only in the install* and uninstall* targets, as those are the only targets where it is useful.

Could you try it with that way?

Regards,
a.

[ririsoft]

Hi,

Using

DESTDIR=/foo/bar make install

or

make DESTDIR=/foo/bar install

Produces the same result and fails to install. This is because apxs is used during make install and does not use the DESTDIR variable but the path from configure --prefix :

make DESTDIR=/home/ririsoft/pkgbuilds/modsecurity-apache/src/pkg install
make[1]: Entering directory '/home/ririsoft/pkgbuilds/modsecurity-apache/src/modsecurity-apache'
make  install-exec-hook
make[2]: Entering directory '/home/ririsoft/pkgbuilds/modsecurity-apache/src/modsecurity-apache'
/usr/sbin/apxs -i -n mod_security3 ./src/.libs/mod_security3.so
/usr/lib/httpd/build/instdso.sh SH_LIBTOOL='/usr/share/apr-1/build/libtool' ./src/.libs/mod_security3.so /usr/lib/httpd/modules
/usr/share/apr-1/build/libtool --mode=install install ./src/.libs/mod_security3.so /usr/lib/httpd/modules/
libtool: install: install ./src/.libs/mod_security3.so /usr/lib/httpd/modules/mod_security3.so
install: cannot remove '/usr/lib/httpd/modules/mod_security3.so': Permission denied
apxs:Error: Command failed with rc=65536
.
make[2]: *** [Makefile:640: install-exec-hook] Error 1
make[2]: Leaving directory '/home/ririsoft/pkgbuilds/modsecurity-apache/src/modsecurity-apache'
make[1]: *** [Makefile:570: install-exec-am] Error 2
make[1]: Leaving directory '/home/ririsoft/pkgbuilds/modsecurity-apache/src/modsecurity-apache'
make: *** [Makefile:515: install-am] Error 2

[zimmerle]

Hi @ririsoft,

It is actually using apxs to decide where to install. It is using the same apxs informed on the configure script. That way, we can use the installation path informed by the distro.

Do you happens to known if other Apache modules also respect DESTDIR?

[airween]

@ririsoft as @zimmerle said, this is the libapr's issue.

I'll check it soon, how could we solve this.

[airween]

I've played with the code, looked few other modules... I didn't other module, which uses apxs to build.

Anyway, I prepared this module for Debian, see this:
https://github.com/airween/ModSecurity-apache/tree/debian

All I could do that make a patch which replaces the "-i" in Makefile.am to "-c", then apxs doesn't want to install, and debuild script can install to the DESTDIR.

Please note, that the branch above (debian) based on v0.0.9-beta1 tagged state of repository.

The raw patch is here:
https://github.com/airween/ModSecurity-apache/blob/debian/debian/patches/build-fixes.patch

Hope that it helps.

[ririsoft]

All I could do that make a patch which replaces the "-i" in Makefile.am to "-c", then apxs doesn't want > to install, and debuild script can install to the DESTDIR.

This is what I am doing too. But I would prefer that the patch is included in modsecurity source code instead of letting distro packagers do it because they do not have full knowledge of what files exactly need to be installed and in which part of the source code repository they can find them after the compilation.

What I do is patch the makefile generated after configure step. I did not succeeded in patching the configure/Makefile.am with a good handling of the DESTDIR variable because of my very poor knowledge of autotools.

[airween]

Meanhile I realized, that with the -c doesn't gives the expected result, for some reason the .so is incompatible with the apache2 httpd...

apxs2 doesn't support the DESTDIR argument, or other destination than axps2 gives back (I guess).

That's the problem, and this isn't autotools issue.

I'll follow the investigate, how could I fix that.

[zimmerle]

Are the package generation process held into a fakeroot? if so, it inst point to the right directory?

[airween]

Are the package generation process held into a fakeroot?

yes (on Debian).

But may be I've found a solution (on Debian), hope that can present soon.

[drmuey]

#55 has a patch that resolves this