FAQ
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.

Search Discussions

  • Garrett Rooney at Jul 26, 2005 at 8:30 pm

    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
  • Steve johnson at Jul 26, 2005 at 8:34 pm

    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?
  • Garrett Rooney at Jul 26, 2005 at 8:35 pm

    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
  • Steve johnson at Jul 26, 2005 at 8:32 pm
    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 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.
  • Garrett Rooney at Jul 26, 2005 at 8:37 pm

    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
  • Steve johnson at Jul 26, 2005 at 8:47 pm
    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 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
  • Garrett Rooney at Jul 26, 2005 at 8:50 pm

    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
  • Steve johnson at Jul 26, 2005 at 9:11 pm

    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.
  • Garrett Rooney at Jul 26, 2005 at 9:29 pm

    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
  • Steve johnson at Jul 27, 2005 at 2:14 pm

    --- Garrett Rooney 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
  • Garrett Rooney at Jul 28, 2005 at 3:20 pm

    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-dev-return-88-apmail-lucene-c-dev-archive=www.apache.org@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:
    List-Unsubscribe:
    List-Post:
    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: <20050729184213.60608.qmail@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 <aces4me@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: <42EA7026.9010400@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 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupc-dev @
categorieslucene
postedJul 26, '05 at 8:04p
activeJul 28, '05 at 3:20p
posts12
users2
websitelucene.apache.org

2 users in discussion

Steve johnson: 6 posts Garrett Rooney: 6 posts

People

Translate

site design / logo © 2021 Grokbase