You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@lucene.apache.org by steve johnson <ac...@yahoo.com> on 2005/07/26 22:04:24 UTC
Starting from scratch
I've tried so many permutations that I decided to
start again from scratch building a mod_mbox/lucene4c
development environment.
new httpd ver 2.0.54 (built with the apr that comes
with the tarball)
new apr ver 1.1.1 (built w
--enable-experimental-libtool)
new apr-util 1.1.2
new version of mod_mbox (which seems to work when
tested)
now I try to build the gcj-backend branch of lucene4c
with my apr version 1.1.1 and I get this error
message.
Can not find suitable object file for
src/util/exception.lo
make[1]: *** [src/util/exception.lo] Error 1
make[1]: Leaving directory `/myth/steve/lucene4c'
make: *** [all] Error 2
I know I have build lucene4c without error in the past
(mod_mbox wouldn't build against it but lucene4c built
without error). What the heck am I doing wrong?
Sept 1 is coming up fast and I have yet to get a
working environment built that I can test any changes in.
Re: Starting from scratch
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
steve johnson wrote:
>
>>Try the trunk, not the gcj-backend branch. Also,
>>since you have two
>>different versions of APR involved, it's possible
>>you're picking up the
>>version that wasn't built with
>>--enable-experimental-libtool, which
>>would mean you're using the wrong version of
>>libtool.
>>
>>-garrett
>>
>
>
> So the java wrapper stuff is in the trunk now?
Yes.
-garrett
Re: Starting from scratch
Posted by steve johnson <ac...@yahoo.com>.
>
> Try the trunk, not the gcj-backend branch. Also,
> since you have two
> different versions of APR involved, it's possible
> you're picking up the
> version that wasn't built with
> --enable-experimental-libtool, which
> would mean you're using the wrong version of
> libtool.
>
> -garrett
>
So the java wrapper stuff is in the trunk now?
Re: Starting from scratch
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
steve johnson wrote:
> I've tried so many permutations that I decided to
> start again from scratch building a mod_mbox/lucene4c
> development environment.
>
> new httpd ver 2.0.54 (built with the apr that comes
> with the tarball)
This is a likely source of problems. If httpd uses one version of APR
and mod_mbox and lucene4c uses another it is likely not going to work well.
> new apr ver 1.1.1 (built w
> --enable-experimental-libtool)
>
> new apr-util 1.1.2
>
> new version of mod_mbox (which seems to work when
> tested)
>
> now I try to build the gcj-backend branch of lucene4c
> with my apr version 1.1.1 and I get this error
> message.
Try the trunk, not the gcj-backend branch. Also, since you have two
different versions of APR involved, it's possible you're picking up the
version that wasn't built with --enable-experimental-libtool, which
would mean you're using the wrong version of libtool.
-garrett
Re: Starting from scratch with lucene4c/mod_mbox
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
> Stack trace
>
> #0 0xb71a83b0 in _Jv_RegisterClassHookDefault () from
> /usr/lib/libgcj.so.6
> #1 0xb71a8958 in _Jv_RegisterClasses () from
> /usr/lib/libgcj.so.6
> #2 0xb7cac7a1 in frame_dummy () from
> /usr/local/lucene4c/lib/liblucene4c.so
> #3 0xb7cac428 in _init () from
> /usr/local/lucene4c/lib/liblucene4c.so
> #4 0xb7ff61ce in _dl_catch_error () from
> /lib/ld-linux.so.2
> #5 0xb7ff62ba in _dl_init () from /lib/ld-linux.so.2
> #6 0xb7edd2b2 in _dl_open () from /lib/tls/libc.so.6
> #7 0xb7ff6016 in _dl_catch_error () from
> /lib/ld-linux.so.2
> #8 0xb7edced6 in _dl_open () from /lib/tls/libc.so.6
> #9 0xb7f0b038 in dlopen () from /lib/tls/libdl.so.2
> #10 0xb7ff6016 in _dl_catch_error () from
> /lib/ld-linux.so.2
> #11 0xb7f0b4a6 in dlerror () from /lib/tls/libdl.so.2
> #12 0xb7f0afe4 in dlopen () from /lib/tls/libdl.so.2
> #13 0xb7fa32c3 in apr_dso_load (res_handle=0xbffff888,
> path=0x8115da0
> "/usr/local/apache2/modules/mod_mbox.so",
> pool=0x80bc0a8)
> at dso.c:138
> #14 0x0807e010 in load_module (cmd=0xbffffa58,
> dummy=0xbffff910,
> modname=0x8115d78 "mbox_module",
> filename=0x8115d88 "modules/mod_mbox.so")
> at mod_so.c:240
> #15 0x08080cb6 in invoke_cmd (cmd=0x80a77c0,
> parms=0xbffffa58,
> mconfig=0xbffff910, args=0x80ff1da "") at
> config.c:797
> #16 0x0808155e in ap_build_config_sub (p=Variable "p"
> is not available.
> ) at config.c:1335
> #17 0x080819ce in ap_build_config (parms=0xbffffa58,
> p=0x80bc0a8,
> ---Type <return> to continue, or q <return> to quit---
> temp_pool=0x80fd1a8, conftree=0x80b2c48) at
> config.c:1127
> #18 0x080820d0 in process_resource_config_nofnmatch
> (s=0x80c0800, fname=Variable "fname" is not available.
> )
> at config.c:1513
> #19 0x08082438 in ap_process_resource_config
> (s=0x80c0800,
> fname=0x80f8d00
> "/usr/local/apache2/conf/httpd.conf",
> conftree=0x80b2c48,
> p=0x80bc0a8, ptemp=0x80fd1a8) at config.c:1549
> #20 0x08082c1f in ap_read_config (process=0x80bc0a8,
> ptemp=0x80fd1a8,
> filename=0x80a8416 "conf/httpd.conf",
> conftree=0x80b2c48) at config.c:1892
> #21 0x08084beb in main (argc=2, argv=0xbffffcf4) at
> main.c:589
>
Well, if it's crashing inside _Jv_RegisterClassHookDefault, then perhaps
looking at that function in the GCC source would give us a clue what is
going wrong. I don't actually have time to look myself, at least not
right now, but if you find anything interesting there please let me
know. Other than that I'm running out of ideas, this may not be a
problem that can be solved without me actually poking around at it
myself, and if so I probably won't get to spend much time with it until
this weekend.
-garrett
From c-dev-return-88-apmail-lucene-c-dev-archive=www.apache.org@lucene.apache.org Fri Jul 29 22:41:42 2005
Return-Path: <c-...@lucene.apache.org>
Delivered-To: apmail-lucene-c-dev-archive@www.apache.org
Received: (qmail 82131 invoked from network); 29 Jul 2005 18:42:15 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 29 Jul 2005 18:42:15 -0000
Received: (qmail 33360 invoked by uid 500); 29 Jul 2005 18:42:15 -0000
Mailing-List: contact c-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <ma...@lucene.apache.org>
List-Unsubscribe: <ma...@lucene.apache.org>
List-Post: <ma...@lucene.apache.org>
List-Id: <c-dev.lucene.apache.org>
Reply-To: c-dev@lucene.apache.org
Delivered-To: mailing list c-dev@lucene.apache.org
Received: (qmail 33347 invoked by uid 99); 29 Jul 2005 18:42:15 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Jul 2005 11:42:15 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [68.142.200.107] (HELO web30404.mail.mud.yahoo.com) (68.142.200.107)
by apache.org (qpsmtpd/0.29) with SMTP; Fri, 29 Jul 2005 11:42:07 -0700
Received: (qmail 60610 invoked by uid 60001); 29 Jul 2005 18:42:13 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
b=p8bLm2TyYHgc6RsAxjWG4/nh9hpYz5nEXdWRa1ws6T6oqRo8shLcB/J6SvyrLqnrvRLfoozh08lzroKTzyvvyAO6FhUM3pSyXQndqd9VemK33mIkFOwboMpNZ7yomd2UZVIEn/TkCeXVJtNGVo898K9wfLr63vjc2UGN5Yw8xfs= ;
Message-ID: <20...@web30404.mail.mud.yahoo.com>
Received: from [216.151.52.59] by web30404.mail.mud.yahoo.com via HTTP; Fri, 29 Jul 2005 11:42:13 PDT
Date: Fri, 29 Jul 2005 11:42:13 -0700 (PDT)
From: steve johnson <ac...@yahoo.com>
Reply-To: aces4me@yahoo.com
Subject: Re: Starting from scratch with lucene4c/mod_mbox
To: c-dev@lucene.apache.org
In-Reply-To: <42...@electricjellyfish.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
Well, given the issues I've had so far (and I've got
20+ years and as first a C developer then a UNIX
sysadmin) a college kid with minimal linux experience
has got 0.0000 chance of ever making this stuff work.
While I would love to wash my hands of this I have a
vested interest in seeing the student finish this
work. And while the odds seem slim at this point they
would be zero if I wasn't doing what I'm tring to do.
The real problem here is that this project was allowed
to be considered as a SoC project as it really isn't
ready to be worked on by the SoC target audience. As
this is the first attempt to do anything like this
(SoC not mod_mbox/lucene4c) It isn't surprising that
there are a few bumps in the process. The timing for
this couldn't have been worse either with the SoC
timeframe intersecting with the move from a straight C
to a java wrapper implementation for lucene4c.
Probably if either one had been 2 months earlier or
later most of this trouble would have been avoided.
The final solution may be a request to google to
extend the SoC timeline to allow the lucene4c/mod_mbox
combination to get mature enough to do some
development on it.
I ain't bitching(much) just frustrated
Steve
--- Garrett Rooney <ro...@electricjellyfish.net>
wrote:
> steve johnson wrote:
>
> > Not to sound more like a moron than I have to, but
> I'm
> > not a developer, I'm a sysadmin. I'm trying to
> set up
> > a development environment for someone new to
> > linux/opensource to do some work this summer.
> While
> > I'm up to building packages and hacking
> configurations
> > (and maybe the odd header file or two) , pawing
> thru
> > gcj source is outside my area of competence.
> > It pains me to see a great opportunity like the
> google
> > SoC go down the toilet because I can't build a
> working
> > copy of mod_mbox with lucene4c.
>
> I hate to break it to you, but if the person who's
> actually doing the
> SoC work can't get the stuff he's supposed to be
> working on to compile
> and run, then how can he possibly be expected to do
> the work? And even
> if he can't get it to run, why isn't he the one
> asking these questions?
>
> I'm sorry this isn't easier for you to get running,
> but if someone is
> getting paid to work on this stuff, then perhaps
> they should be the one
> working on it, and not you.
>
> -garrett
>
Re: Starting from scratch with lucene4c/mod_mbox
Posted by steve johnson <ac...@yahoo.com>.
--- Garrett Rooney <ro...@electricjellyfish.net>
wrote:
> Well, the only reason you need the trunk version of
> APR for Lucene4C is
> that Paul fixed some problems with jlibtool in the
> trunk and those fixes
> aren't available in a released version yet. You
> could try copying the
> trunk's version of jlibtool.c over to the older APR,
> build that APR with
> --enable-experimental-libtool, then build
> everything from scratch
> using that version of APR. I can't recall if
> anything in Lucene4C
> enforces the use of a current version of APR, but if
> it does it probably
> isn't hard to work around.
>
> -garrett
>
I built lucene4c with the apr that comes with the
httpd tarball (with the jlibtool.c from the trunk).
No change in symptoms. Stack trace looks very
similar. here is the data:
ldd mod_mbox.so
libexpat.so.1 =>
/usr/lib/libexpat.so.1 (0xb7fc7000)
liblucene4c.so =>
/usr/local/lucene4c/lib/liblucene4c.so (0xb7e21000)
libapr-0.so.0 =>
/usr/local/apache2/lib/libapr-0.so.0 (0xb7e00000)
librt.so.1 => /lib/tls/librt.so.1 (0xb7dfa000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7dd8000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1
(0xb7dab000)
libnsl.so.1 => /lib/tls/libnsl.so.1
(0xb7d97000)
libpthread.so.0 => /lib/tls/libpthread.so.0
(0xb7d87000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7d84000)
libaprutil-0.so.0 =>
/usr/local/apache2/lib/libaprutil-0.so.0 (0xb7d70000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7c3b000)
libgcj.so.6 => /usr/lib/libgcj.so.6
(0xb6b70000)
libgcc_s.so.1 => /lib/libgcc_s.so.1
(0xb6b64000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6b52000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
(0x80000000)
ldd liblucene4c.so
libgcj.so.6 => /usr/lib/libgcj.so.6
(0xb6d82000)
libapr-0.so =>
/usr/local/apr/.libs/libapr-0.so (0xb6d60000)
librt.so.1 => /lib/tls/librt.so.1 (0xb6d5a000)
libm.so.6 => /lib/tls/libm.so.6 (0xb6d38000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1
(0xb6d0b000)
libnsl.so.1 => /lib/tls/libnsl.so.1
(0xb6cf7000)
libpthread.so.0 => /lib/tls/libpthread.so.0
(0xb6ce8000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb6ce4000)
libgcc_s.so.1 => /lib/libgcc_s.so.1
(0xb6cd9000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6cc7000)
libc.so.6 => /lib/tls/libc.so.6 (0xb6b92000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
(0x80000000)
Stack trace
#0 0xb71a83b0 in _Jv_RegisterClassHookDefault () from
/usr/lib/libgcj.so.6
#1 0xb71a8958 in _Jv_RegisterClasses () from
/usr/lib/libgcj.so.6
#2 0xb7cac7a1 in frame_dummy () from
/usr/local/lucene4c/lib/liblucene4c.so
#3 0xb7cac428 in _init () from
/usr/local/lucene4c/lib/liblucene4c.so
#4 0xb7ff61ce in _dl_catch_error () from
/lib/ld-linux.so.2
#5 0xb7ff62ba in _dl_init () from /lib/ld-linux.so.2
#6 0xb7edd2b2 in _dl_open () from /lib/tls/libc.so.6
#7 0xb7ff6016 in _dl_catch_error () from
/lib/ld-linux.so.2
#8 0xb7edced6 in _dl_open () from /lib/tls/libc.so.6
#9 0xb7f0b038 in dlopen () from /lib/tls/libdl.so.2
#10 0xb7ff6016 in _dl_catch_error () from
/lib/ld-linux.so.2
#11 0xb7f0b4a6 in dlerror () from /lib/tls/libdl.so.2
#12 0xb7f0afe4 in dlopen () from /lib/tls/libdl.so.2
#13 0xb7fa32c3 in apr_dso_load (res_handle=0xbffff888,
path=0x8115da0
"/usr/local/apache2/modules/mod_mbox.so",
pool=0x80bc0a8)
at dso.c:138
#14 0x0807e010 in load_module (cmd=0xbffffa58,
dummy=0xbffff910,
modname=0x8115d78 "mbox_module",
filename=0x8115d88 "modules/mod_mbox.so")
at mod_so.c:240
#15 0x08080cb6 in invoke_cmd (cmd=0x80a77c0,
parms=0xbffffa58,
mconfig=0xbffff910, args=0x80ff1da "") at
config.c:797
#16 0x0808155e in ap_build_config_sub (p=Variable "p"
is not available.
) at config.c:1335
#17 0x080819ce in ap_build_config (parms=0xbffffa58,
p=0x80bc0a8,
---Type <return> to continue, or q <return> to quit---
temp_pool=0x80fd1a8, conftree=0x80b2c48) at
config.c:1127
#18 0x080820d0 in process_resource_config_nofnmatch
(s=0x80c0800, fname=Variable "fname" is not available.
)
at config.c:1513
#19 0x08082438 in ap_process_resource_config
(s=0x80c0800,
fname=0x80f8d00
"/usr/local/apache2/conf/httpd.conf",
conftree=0x80b2c48,
p=0x80bc0a8, ptemp=0x80fd1a8) at config.c:1549
#20 0x08082c1f in ap_read_config (process=0x80bc0a8,
ptemp=0x80fd1a8,
filename=0x80a8416 "conf/httpd.conf",
conftree=0x80b2c48) at config.c:1892
#21 0x08084beb in main (argc=2, argv=0xbffffcf4) at
main.c:589
Re: Starting from scratch with lucene4c/mod_mbox
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
steve johnson wrote:
>
>>Well, first off, one is linked against libapr-0.so
>>and one is linked
>>with libapr-1.so, that's probably a bad thing...
>>I'd suggest making
>>sure everything is linked against one or the other,
>>and trying again.
>>
>>-garrett
>>
>
> Ok, seems reasonable but I'm not sure how it can be
> done. httpd won't build with the version of apr that
> lucene4c requires. And mod_mbox builds with apxs which
> uses the same libraries as httpd. Even if I could
> rebuild mod_mbox with the version lucene4c wants I
> would probably end up in the same situation because of
> the version difference between the httpd and mod_mbox.
Well, the only reason you need the trunk version of APR for Lucene4C is
that Paul fixed some problems with jlibtool in the trunk and those fixes
aren't available in a released version yet. You could try copying the
trunk's version of jlibtool.c over to the older APR, build that APR with
--enable-experimental-libtool, then build everything from scratch
using that version of APR. I can't recall if anything in Lucene4C
enforces the use of a current version of APR, but if it does it probably
isn't hard to work around.
-garrett
Re: Starting from scratch with lucene4c/mod_mbox
Posted by steve johnson <ac...@yahoo.com>.
>
> Well, first off, one is linked against libapr-0.so
> and one is linked
> with libapr-1.so, that's probably a bad thing...
> I'd suggest making
> sure everything is linked against one or the other,
> and trying again.
>
> -garrett
>
Ok, seems reasonable but I'm not sure how it can be
done. httpd won't build with the version of apr that
lucene4c requires. And mod_mbox builds with apxs which
uses the same libraries as httpd. Even if I could
rebuild mod_mbox with the version lucene4c wants I
would probably end up in the same situation because of
the version difference between the httpd and mod_mbox.
Re: Starting from scratch with lucene4c/mod_mbox
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
steve johnson wrote:
> mod_mbox.so
> /myth/steve/mod_mbox_l/trunk/module-2.0/.libs/mod_mbox.so
> liblucene4c.so =>
> /usr/local/lucene4c/lib/liblucene4c.so (0xb7e4f000)
> libapr-0.so.0 =>
> /usr/local/apache2/lib/libapr-0.so.0 (0xb7e2d000)
> librt.so.1 => /lib/tls/librt.so.1 (0xb7e1a000)
> libm.so.6 => /lib/tls/libm.so.6 (0xb7df8000)
> libcrypt.so.1 => /lib/tls/libcrypt.so.1
> (0xb7dcb000)
> libnsl.so.1 => /lib/tls/libnsl.so.1
> (0xb7db7000)
> libpthread.so.0 => /lib/tls/libpthread.so.0
> (0xb7da8000)
> libdl.so.2 => /lib/tls/libdl.so.2 (0xb7da4000)
> libaprutil-0.so.0 =>
> /usr/local/apache2/lib/libaprutil-0.so.0 (0xb7d90000)
> libexpat.so.1 => /usr/lib/libexpat.so.1
> (0xb7d70000)
> libc.so.6 => /lib/tls/libc.so.6 (0xb7c3b000)
> libgcj.so.6 => /usr/lib/libgcj.so.6
> (0xb6b70000)
> libapr-1.so => /usr/local/apr/lib/libapr-1.so
> (0xb6b4c000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1
> (0xb6b41000)
> libz.so.1 => /usr/lib/libz.so.1 (0xb6b2f000)
>
>
> liblucene.so
>
> libgcj.so.6 => /usr/lib/libgcj.so.6 (0xb6d82000)
> libapr-1.so => /usr/local/apr/lib/libapr-1.so
> (0xb6d5e000)
> librt.so.1 => /lib/tls/librt.so.1 (0xb6d58000)
> libcrypt.so.1 => /lib/tls/libcrypt.so.1
> (0xb6d2b000)
> libpthread.so.0 => /lib/tls/libpthread.so.0
> (0xb6d1c000)
> libdl.so.2 => /lib/tls/libdl.so.2 (0xb6d19000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1
> (0xb6d0e000)
> libm.so.6 => /lib/tls/libm.so.6 (0xb6ceb000)
> libz.so.1 => /usr/lib/libz.so.1 (0xb6cd9000)
> libc.so.6 => /lib/tls/libc.so.6 (0xb6ba4000)
> libexpat.so.1 => /usr/lib/libexpat.so.1
> (0xb6b84000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2
> (0x80000000)
Well, first off, one is linked against libapr-0.so and one is linked
with libapr-1.so, that's probably a bad thing... I'd suggest making
sure everything is linked against one or the other, and trying again.
-garrett
Re: Starting from scratch with lucene4c/mod_mbox
Posted by steve johnson <ac...@yahoo.com>.
mod_mbox.so
/myth/steve/mod_mbox_l/trunk/module-2.0/.libs/mod_mbox.so
liblucene4c.so =>
/usr/local/lucene4c/lib/liblucene4c.so (0xb7e4f000)
libapr-0.so.0 =>
/usr/local/apache2/lib/libapr-0.so.0 (0xb7e2d000)
librt.so.1 => /lib/tls/librt.so.1 (0xb7e1a000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7df8000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1
(0xb7dcb000)
libnsl.so.1 => /lib/tls/libnsl.so.1
(0xb7db7000)
libpthread.so.0 => /lib/tls/libpthread.so.0
(0xb7da8000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7da4000)
libaprutil-0.so.0 =>
/usr/local/apache2/lib/libaprutil-0.so.0 (0xb7d90000)
libexpat.so.1 => /usr/lib/libexpat.so.1
(0xb7d70000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7c3b000)
libgcj.so.6 => /usr/lib/libgcj.so.6
(0xb6b70000)
libapr-1.so => /usr/local/apr/lib/libapr-1.so
(0xb6b4c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1
(0xb6b41000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6b2f000)
liblucene.so
libgcj.so.6 => /usr/lib/libgcj.so.6 (0xb6d82000)
libapr-1.so => /usr/local/apr/lib/libapr-1.so
(0xb6d5e000)
librt.so.1 => /lib/tls/librt.so.1 (0xb6d58000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1
(0xb6d2b000)
libpthread.so.0 => /lib/tls/libpthread.so.0
(0xb6d1c000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb6d19000)
libgcc_s.so.1 => /lib/libgcc_s.so.1
(0xb6d0e000)
libm.so.6 => /lib/tls/libm.so.6 (0xb6ceb000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6cd9000)
libc.so.6 => /lib/tls/libc.so.6 (0xb6ba4000)
libexpat.so.1 => /usr/lib/libexpat.so.1
(0xb6b84000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
(0x80000000)
--- Garrett Rooney <ro...@electricjellyfish.net>
wrote:
> steve johnson wrote:
> > Update:
> >
> > By using the trunk version of apr I got lucene4c
> to
> > build. By deleting the liblucene4c.la file I got
> > mod_mbox to build using lucene4c. Now when I
> start
> > the httpd it dumps core. Here is a stack trace.
> Any
> > suggestions about next steps would be appreciated.
>
> Well, it seems to be failing to dlopen mod_mbox.so,
> likely reasons for
> this might be a failure to link in necessary
> libraries, maybe the C++
> runtime (libstdc++) or the java runtime (i forget
> the name for this).
> Running ldd on mod_mbox.so might be interesting, as
> would running it on
> liblucene4c.so.
>
> -garrett
>
Re: Starting from scratch with lucene4c/mod_mbox
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
steve johnson wrote:
> Update:
>
> By using the trunk version of apr I got lucene4c to
> build. By deleting the liblucene4c.la file I got
> mod_mbox to build using lucene4c. Now when I start
> the httpd it dumps core. Here is a stack trace. Any
> suggestions about next steps would be appreciated.
Well, it seems to be failing to dlopen mod_mbox.so, likely reasons for
this might be a failure to link in necessary libraries, maybe the C++
runtime (libstdc++) or the java runtime (i forget the name for this).
Running ldd on mod_mbox.so might be interesting, as would running it on
liblucene4c.so.
-garrett
Re: Starting from scratch with lucene4c/mod_mbox
Posted by steve johnson <ac...@yahoo.com>.
Update:
By using the trunk version of apr I got lucene4c to
build. By deleting the liblucene4c.la file I got
mod_mbox to build using lucene4c. Now when I start
the httpd it dumps core. Here is a stack trace. Any
suggestions about next steps would be appreciated.
[Switching to Thread -1210235808 (LWP 30968)]
0xb71a83b0 in _Jv_RegisterClassHookDefault () from
/usr/lib/libgcj.so.6
(gdb) bt
#0 0xb71a83b0 in _Jv_RegisterClassHookDefault () from
/usr/lib/libgcj.so.6
#1 0xb71a8958 in _Jv_RegisterClasses () from
/usr/lib/libgcj.so.6
#2 0xb7cac7a1 in frame_dummy () from
/usr/local/lucene4c/lib/liblucene4c.so
#3 0xb7cac41c in _init () from
/usr/local/lucene4c/lib/liblucene4c.so
#4 0xb7ff61ce in _dl_catch_error () from
/lib/ld-linux.so.2
#5 0xb7ff62ba in _dl_init () from /lib/ld-linux.so.2
#6 0xb7edd2b2 in _dl_open () from /lib/tls/libc.so.6
#7 0xb7ff6016 in _dl_catch_error () from
/lib/ld-linux.so.2
#8 0xb7edced6 in _dl_open () from /lib/tls/libc.so.6
#9 0xb7f0b038 in dlopen () from /lib/tls/libdl.so.2
#10 0xb7ff6016 in _dl_catch_error () from
/lib/ld-linux.so.2
#11 0xb7f0b4a6 in dlerror () from /lib/tls/libdl.so.2
#12 0xb7f0afe4 in dlopen () from /lib/tls/libdl.so.2
#13 0xb7fa32d3 in apr_dso_load (res_handle=0xbffff868,
path=0x8116168
"/usr/local/apache2/modules/mod_mbox.so",
pool=0x80bc0a8) at dso.c:138
#14 0x0807e010 in load_module (cmd=0xbffffa38,
dummy=0xbffff8f0,
modname=0x8116140 "mbox_module",
filename=0x8116150 "modules/mod_mbox.so")
at mod_so.c:240
#15 0x08080cb6 in invoke_cmd (cmd=0x80a77c0,
parms=0xbffffa38, mconfig=0xbffff8f0,
args=0x80ff1da "") at config.c:797
#16 0x0808155e in ap_build_config_sub (p=Variable "p"
is not available.
) at config.c:1335
#17 0x080819ce in ap_build_config (parms=0xbffffa38,
p=0x80bc0a8, temp_pool=0x80fd1a8,
conftree=0x80b2c48) at config.c:1127
#18 0x080820d0 in process_resource_config_nofnmatch
(s=0x80c0800, fname=Variable "fname" is not available.
) at config.c:1513
#19 0x08082438 in ap_process_resource_config
(s=0x80c0800,
---Type <return> to continue, or q <return> to quit---
fname=0x80f8d00
"/usr/local/apache2/conf/httpd.conf",
conftree=0x80b2c48, p=0x80bc0a8,
ptemp=0x80fd1a8) at config.c:1549
#20 0x08082c1f in ap_read_config (process=0x80bc0a8,
ptemp=0x80fd1a8,
filename=0x80a8416 "conf/httpd.conf",
conftree=0x80b2c48) at config.c:1892
#21 0x08084beb in main (argc=2, argv=0xbffffcd4) at
main.c:589
--- steve johnson <ac...@yahoo.com> wrote:
> I've tried so many permutations that I decided to
> start again from scratch building a
> mod_mbox/lucene4c
> development environment.
>
> new httpd ver 2.0.54 (built with the apr that comes
> with the tarball)
>
> new apr ver 1.1.1 (built w
> --enable-experimental-libtool)
>
> new apr-util 1.1.2
>
> new version of mod_mbox (which seems to work when
> tested)
>
> now I try to build the gcj-backend branch of
> lucene4c
> with my apr version 1.1.1 and I get this error
> message.
>
> Can not find suitable object file for
> src/util/exception.lo
> make[1]: *** [src/util/exception.lo] Error 1
> make[1]: Leaving directory `/myth/steve/lucene4c'
> make: *** [all] Error 2
>
> I know I have build lucene4c without error in the
> past
> (mod_mbox wouldn't build against it but lucene4c
> built
> without error). What the heck am I doing wrong?
>
> Sept 1 is coming up fast and I have yet to get a
> working environment built that I can test any
> changes in.
>
Re: Starting from scratch with lucene4c/mod_mbox
Posted by steve johnson <ac...@yahoo.com>.
Update:
By using the trunk version of apr I got lucene4c to
build. By deleting the liblucene4c.la file I got
mod_mbox to build using lucene4c. Now when I start
the httpd it dumps core. Here is a stack trace. Any
suggestions about next steps would be appreciated.
[Switching to Thread -1210235808 (LWP 30968)]
0xb71a83b0 in _Jv_RegisterClassHookDefault () from
/usr/lib/libgcj.so.6
(gdb) bt
#0 0xb71a83b0 in _Jv_RegisterClassHookDefault () from
/usr/lib/libgcj.so.6
#1 0xb71a8958 in _Jv_RegisterClasses () from
/usr/lib/libgcj.so.6
#2 0xb7cac7a1 in frame_dummy () from
/usr/local/lucene4c/lib/liblucene4c.so
#3 0xb7cac41c in _init () from
/usr/local/lucene4c/lib/liblucene4c.so
#4 0xb7ff61ce in _dl_catch_error () from
/lib/ld-linux.so.2
#5 0xb7ff62ba in _dl_init () from /lib/ld-linux.so.2
#6 0xb7edd2b2 in _dl_open () from /lib/tls/libc.so.6
#7 0xb7ff6016 in _dl_catch_error () from
/lib/ld-linux.so.2
#8 0xb7edced6 in _dl_open () from /lib/tls/libc.so.6
#9 0xb7f0b038 in dlopen () from /lib/tls/libdl.so.2
#10 0xb7ff6016 in _dl_catch_error () from
/lib/ld-linux.so.2
#11 0xb7f0b4a6 in dlerror () from /lib/tls/libdl.so.2
#12 0xb7f0afe4 in dlopen () from /lib/tls/libdl.so.2
#13 0xb7fa32d3 in apr_dso_load (res_handle=0xbffff868,
path=0x8116168
"/usr/local/apache2/modules/mod_mbox.so",
pool=0x80bc0a8) at dso.c:138
#14 0x0807e010 in load_module (cmd=0xbffffa38,
dummy=0xbffff8f0,
modname=0x8116140 "mbox_module",
filename=0x8116150 "modules/mod_mbox.so")
at mod_so.c:240
#15 0x08080cb6 in invoke_cmd (cmd=0x80a77c0,
parms=0xbffffa38, mconfig=0xbffff8f0,
args=0x80ff1da "") at config.c:797
#16 0x0808155e in ap_build_config_sub (p=Variable "p"
is not available.
) at config.c:1335
#17 0x080819ce in ap_build_config (parms=0xbffffa38,
p=0x80bc0a8, temp_pool=0x80fd1a8,
conftree=0x80b2c48) at config.c:1127
#18 0x080820d0 in process_resource_config_nofnmatch
(s=0x80c0800, fname=Variable "fname" is not available.
) at config.c:1513
#19 0x08082438 in ap_process_resource_config
(s=0x80c0800,
---Type <return> to continue, or q <return> to quit---
fname=0x80f8d00
"/usr/local/apache2/conf/httpd.conf",
conftree=0x80b2c48, p=0x80bc0a8,
ptemp=0x80fd1a8) at config.c:1549
#20 0x08082c1f in ap_read_config (process=0x80bc0a8,
ptemp=0x80fd1a8,
filename=0x80a8416 "conf/httpd.conf",
conftree=0x80b2c48) at config.c:1892
#21 0x08084beb in main (argc=2, argv=0xbffffcd4) at
main.c:589
--- steve johnson <ac...@yahoo.com> wrote:
> I've tried so many permutations that I decided to
> start again from scratch building a
> mod_mbox/lucene4c
> development environment.
>
> new httpd ver 2.0.54 (built with the apr that comes
> with the tarball)
>
> new apr ver 1.1.1 (built w
> --enable-experimental-libtool)
>
> new apr-util 1.1.2
>
> new version of mod_mbox (which seems to work when
> tested)
>
> now I try to build the gcj-backend branch of
> lucene4c
> with my apr version 1.1.1 and I get this error
> message.
>
> Can not find suitable object file for
> src/util/exception.lo
> make[1]: *** [src/util/exception.lo] Error 1
> make[1]: Leaving directory `/myth/steve/lucene4c'
> make: *** [all] Error 2
>
> I know I have build lucene4c without error in the
> past
> (mod_mbox wouldn't build against it but lucene4c
> built
> without error). What the heck am I doing wrong?
>
> Sept 1 is coming up fast and I have yet to get a
> working environment built that I can test any
> changes in.
>