Installing apache server on Chromium OS

[satayev]

Hey,

I'm trying to get apache2 running on one of the Chrome Boxes. I figured that the old "gentoo" portage is not supported by default, so I had to add it to the PORTDIR_OVERLAY and update the ebuilds for www-servers/apache, dev-libs/apr, dev-libs/apr-util and a few other files.

In chroot, once `emerge-x86-generic www-servers/apache` is called, it tries to install dev-libs/apr first. I had some troubles fetching the tarball and configuring it, but I think I fixed that by updating the manifest and ebuild. So all these stages run smoothly: src_prepare(), src_configure(), but `emake` in src_compile() produces some errors:

libtool: compile: unable to infer tagged configuration

libtool: compile: specify a tag with `--tag'

make[1]: *** [strings/apr_cpystrn.lo] Error 1

make[1]: *** Waiting for unfinished jobs....

libtool: compile: unable to infer tagged configuration

libtool: compile: specify a tag with `--tag'

libtool: compile: unable to infer tagged configuration

libtool: compile: specify a tag with `--tag'

make[1]: *** [passwd/apr_getpass.lo] Error 1

make[1]: *** [strings/apr_snprintf.lo] Error 1

libtool: compile: unable to infer tagged configuration

libtool: compile: specify a tag with `--tag'

make[1]: *** [strings/apr_fnmatch.lo] Error 1

libtool: compile: unable to infer tagged configuration

libtool: compile: specify a tag with `--tag'

make[1]: *** [strings/apr_strings.lo] Error 1

libtool: compile: unable to infer tagged configuration

libtool: compile: specify a tag with `--tag'

make[1]: *** [strings/apr_strnatcmp.lo] Error 1

make[1]: Leaving directory `/build/x86-generic/tmp/portage/dev-libs/apr-1.4.6/work/apr-1.4.6'

make: *** [all-recursive] Error 1

I tried to update several packages in sys-devel: libtool, m4, make, autoconf, automake and wrappers. However that doesn't fix the problem as suggested on internet.

econf runs `./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu` with few more options, and I believe it does configure right.

What am I doing wrong? does emerge-x86-generic do things differently than just regular emerge?

Thank you,

-Artur

[satayev]

I wasn't very specific about my changes, also I wasn't sure if my previous work was causing the problem. So I did a clean install, and after `setup_board --board=x86-generic`, I just tried to install a single dev-libs/apr. apr-1.3.9 is in portage-stable, so I didn't need to add any other overlays. It failed again:

checking whether TCP_NODELAY and TCP_CORK can both be enabled... configure: error: in `/build/x86-generic/tmp/portage/dev-libs/apr-1.3.9/work/apr-1.3.9':

configure: error: cannot run test program while cross compiling

See `config.log' for more details

!!! Please attach the following file when seeking support:

!!! /build/x86-generic/tmp/portage/dev-libs/apr-1.3.9/work/apr-1.3.9/config.log

 * ERROR: dev-libs/apr-1.3.9 failed (configure phase):

 *   econf failed

 * 

 * Call stack:

 *     ebuild.sh, line   56:  Called src_configure

 *   environment, line 3007:  Called econf '--enable-layout=gentoo' '--enable-nonportable-atomics' '--enable-threads' '--with-devrandom=/dev/urandom'

 *     ebuild.sh, line  561:  Called die

 * The specific snippet of code:

 *   die "econf failed"

 * 

[satayev]

If I disable APR_CHECK_TCP_NODELAY_WITH_CORK, then it does pass the source configuration stage, but fails on compile:

/bin/sh /usr/bin/libtool --silent --mode=compile i686-pc-linux-gnu-gcc   -O2 -pipe -march=i686 -mfpmath=sse -mmmx -msse -msse2 -msse3 -g -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE   -I./include -I/build/x86-generic/tmp/portage/dev-libs/apr-1.3.9/work/apr-1.3.9/include/arch/unix -I./include/arch/unix -I/build/x86-generic/tmp/portage/dev-libs/apr-1.3.9/work/apr-1.3.9/include/arch/unix -I/build/x86-generic/tmp/portage/dev-libs/apr-1.3.9/work/apr-1.3.9/include  -o passwd/apr_getpass.lo -c passwd/apr_getpass.c && touch passwd/apr_getpass.lo

libtool: compile: unable to infer tagged configuration

libtool: compile: specify a tag with `--tag'

make[1]: *** [passwd/apr_getpass.lo] Error 1

make[1]: Leaving directory `/build/x86-generic/tmp/portage/dev-libs/apr-1.3.9/work/apr-1.3.9'

make: *** [all-recursive] Error 1

emake failed

 * ERROR: dev-libs/apr-1.3.9 failed (compile phase):

 *   emake failed

 * 

 * Call stack:

 *     ebuild.sh, line  56:  Called src_compile

 *   environment, line 2988:  Called die

 * The specific snippet of code:

 *       emake -j1 || die "emake failed";

 * 

[satayev]

 I was able to install dev-libs/apr  by using the libtools provided in the tarball and adding this two lines into src_configure():

export apr_cv_tcp_nodelay_with_cork=no

export ac_cv_sizeof_struct_iovec=1

 However, if I try to install with the system libtool (both 2.4-r1 and 2.4.2) it does give me the same errors:

libtool: compile: unable to infer tagged configuration

libtool: compile: specify a tag with `--tag'

Any ideas on why it fails?

[Mike Frysinger]

Re: libtool, you could try re-emerging it in the root. Otherwise, you
should use cros_portage_upgrade to pull down recent Apache pkgs rather
than the old ones in portage/.
-mike

> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Mike Frysinger]

because libtool configured for one target (the native sdk) is not
meant to be used for a different one (any cross-compiling target)

apache projects have a long history of being stupid and using the
native libtool instead of properly including it in the source
distribution

there is no short answer. i've honestly not really looked into it as
cross-compiling apache hasn't personally come up. when i wanted http
servers on embedded systems, i'd use a small http server.

along those lines, do you really need apache ? seems like overkill
for most things.
-mike

[satayev]

yes, you are right. It's possible to install dev-libs/apr with the provided libtool, but they don't provide the libtool neither for apr-util nor for apache-tools.

Apparently the system libtool for x86-generic is forced to use x86_64 linker, when you need to link m32 apache files.

The solution lmcloughlin@ suggested, was to use emerge-amd64-generic which worked fine with the fixes I provided above. So I was able to compile and install gentoo www-servers/apache for amd64-generic board. (now experiencing problems with running it on chromeboxes, but that's a different story).

well, right now we do not really need the whole apache2, but once the project grows we could benefit greatly from having it (modules, etc).

so, what http server you suggest to use? I want to know which one would install and work without problems and provide at least basic http server features.

[Alec Warner]

lighty? nginx?

It really depends on what features you actually need.

[Mike Frysinger]

On Fri, Jun 22, 2012 at 10:03 PM, satayev <sat...@google.com> wrote:
> Apparently the system libtool for x86-generic is forced to use x86_64
> linker, when you need to link m32 apache files.

i don't know what you're talking about here. the x86-generic libtool
is configured to use the correct cross-compiler
(i686-pc-linux-gnu-xxx), not the native x86_64-pc-linux-gnu, nor the
cross x86_64-cros-linux-gnu.

you can easily verify this yourself:
$ echo 'main(){}' > test.c
$ /build/x86-generic/usr/bin/libtool --mode=compile
i686-pc-linux-gnu-gcc -c test.c -o test.o
libtool: compile: i686-pc-linux-gnu-gcc -c test.c -fPIC -DPIC -o
.libs/test.o
libtool: compile: i686-pc-linux-gnu-gcc -c test.c -o test.o
>/dev/null 2>&1
$ /build/x86-generic/usr/bin/libtool --mode=link i686-pc-linux-gnu-gcc
test.o -o test
libtool: link: i686-pc-linux-gnu-gcc test.o -o test

> The solution lmcloughlin@ suggested, was to use emerge-amd64-generic which
> worked fine with the fixes I provided above. So I was able to compile and
> install gentoo www-servers/apache for amd64-generic board. (now experiencing
> problems with running it on chromeboxes, but that's a different story).

amd64 targets probably will "just work" because the native toolchain
(x86_64-pc-linux-gnu) is close enough to the cross one
(x86_64-cros-linux-gnu).

you might be able to make apr cross-compile by changing the sed in
src_configure to point to $SYSROOT/usr/bin/libtool ...
-mike