Created attachment 57533 [details] [review]
fixes the bug

does this still happen with later releases?

Sorry for the delay: Yes, this bug still happens in gnome-vfs-2.13.91. I made a patch that works for me. I will attach it in a minute.

Created attachment 59475 [details] [review]
Patch for missing neon-implementations

The new attachment adds the ne_xml_request.c and renames the fake implementation of 'ne_ssl_ctx_trustcert' to 'ne_ssl_context_trustcert' in file 'imported/neon/ne_gnomevfs.c' as required by neon-0.25.x

uhm I'd say Galeon should be modified to comply.
can you update Galeon, please, and see if this still happens?

(In reply to comment #5)
> uhm I'd say Galeon should be modified to comply.
> can you update Galeon, please, and see if this still happens?

I am sorry, but I dont understand what you mean. Galeon is at version 2.0.0, so it should be up to date. After emerging gnome-vfs-2.13.91 and reemerging galeon-2.0.0 the problem still exists.

Please tell me if you need anymore information.

New testcase for the console afinados:
$ gnomevfs-cat http://www.gnome.org

(process:21917): libgnomevfs-WARNING **: Cannot load module `/usr/lib/gnome-vfs-2.0/modules/libhttp.so' (/usr/lib/gnome-vfs-2.0/modules/libhttp.so: undefined symbol: ne_xml_dispatch_request)

So either:
A. It only happens to me cause I use a hardened system.
B. It is a critical bug and the patch above should be applied immediately.

Cheers

I am compiling as well from source, and I have no problems here.

changing product to gnome-vfs

nazgul@dragonscale:~$ gnomevfs-cat http://www.gnome.org
HTTP:[0x804c7d8] do_open {in +++}
HTTP:[0x804c7d8] [Session Pool] Searching (0) {in neon_session_pool_lookup}
HTTP:[0x804c7d8] [Session] new connection www.gnome.org, 80 {in http_acquire_connection}
HTTP:[0x804c7d8] neon_setup_headers {in +++}
HTTP:[0x804c7d8] neon_setup_headers {in ---}
HTTP:[0x804c7d8] [GET] No error, 0, 200 {in http_transfer_start_read}
HTTP:[0x804c7d8] neon_return_headers {in +++}
HTTP:[0x804c7d8] neon_return_headers {in ---}
HTTP:[0x804c7d8] do_open {in ---}
HTTP:[0x804c7d8] [read] bytes read 1023 {in do_read}
<?xml version="1.0" encoding="UTF-8"?>
....


please run the following command 
 ldd -d /usr/lib/gnome-vfs-2.0/modules/libhttp.so

it yields for me

$ ldd -d /opt/gnome2/lib/gnome-vfs-2.0/modules/libhttp.so
        linux-gate.so.1 =>  (0xffffe000)
        libgobject-2.0.so.0 => /opt/gnome2/lib/libgobject-2.0.so.0 (0xb7f7a000)
        libgconf-2.so.4 => /opt/gnome2/lib/libgconf-2.so.4 (0xb7f49000)
        libORBit-2.so.0 => /opt/gnome2/lib/libORBit-2.so.0 (0xb7ef7000)
        libgmodule-2.0.so.0 => /opt/gnome2/lib/libgmodule-2.0.so.0 (0xb7ef4000)
        libgthread-2.0.so.0 => /opt/gnome2/lib/libgthread-2.0.so.0 (0xb7ef0000)
        libglib-2.0.so.0 => /opt/gnome2/lib/libglib-2.0.so.0 (0xb7e69000)
        libxml2.so.2 => /opt/gnome2/lib/libxml2.so.2 (0xb7d56000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7d45000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7d31000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d0f000)
        libgnomevfs-2.so.0 => /opt/gnome2/lib/libgnomevfs-2.so.0 (0xb7cb2000)
        libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7caf000)
        librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7ca6000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c94000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b66000)
        libpopt.so.0 => /lib/libpopt.so.0 (0xb7b5e000)
        /lib/ld-linux.so.2 (0x80000000)
        libbonobo-2.so.0 => /opt/gnome2/lib/libbonobo-2.so.0 (0xb7b08000)
        libbonobo-activation.so.4 => /opt/gnome2/lib/libbonobo-activation.so.4 (0xb7af4000)
        libhowl.so.0 => /opt/gnome2/lib/libhowl.so.0 (0xb79ce000)
        libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb79bb000)
        libORBitCosNaming-2.so.0 => /opt/gnome2/lib/libORBitCosNaming-2.so.0 (0xb79b7000)

rajas: How did ne_xml_dispatch_request get invoked? I can only see it being invoked by ne-locks.c:ne_lock and ne-locks.c:ne_lock_refresh, and none of them seems to be used by GnomeVFS.

(In reply to comment #8)

Sorry for the delay.

ldd yields:

$ ldd -d /usr/lib/gnome-vfs-2.0/modules/libhttp.so
        linux-gate.so.1 =>  (0xffffe000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7ea7000)
        libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb7e69000)
        libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb7e02000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7dfd000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7df7000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7d5b000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7d3e000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7cb6000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7c8e000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7c89000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7c85000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb7c71000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7b09000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7b05000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7af7000)
        libm.so.6 => /lib/libm.so.6 (0xb7ad4000)
        libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0xb7a56000)
        libutil.so.1 => /lib/libutil.so.1 (0xb7a52000)
        librt.so.1 => /lib/librt.so.1 (0xb7a48000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7a35000)
        libc.so.6 => /lib/libc.so.6 (0xb7915000)
        libpopt.so.0 => /usr/lib/libpopt.so.0 (0xb790c000)
        /lib/ld-linux.so.2 (0x80000000)
        libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0xb7897000)
        libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 (0xb787d000)
        libgnutls.so.12 => /usr/lib/libgnutls.so.12 (0xb77f1000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7798000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7793000)
        libavahi-glib.so.1 => /usr/lib/libavahi-glib.so.1 (0xb778e000)
        libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xb7781000)
        libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xb776e000)
        libORBitCosNaming-2.so.0 => /usr/lib/libORBitCosNaming-2.so.0 (0xb7767000)
        libnsl.so.1 => /lib/libnsl.so.1 (0xb7751000)
        libdbus-1.so.2 => /usr/lib/libdbus-1.so.2 (0xb7714000)

(In reply to comment #9)
> rajas: How did ne_xml_dispatch_request get invoked?

I don't know what function it invoked. I am sorry, but I am not *that* much involved in C-programming  and Gnome. ;) But I can find out if you tell me how.

Created attachment 69441 [details] [review]
gnome-vfs-2.14.2-http_module-undef-neon-symbols.patch

Here is a patch from Martin Schlemmer <azarah@nosferatu.za.org> to fix the undefined symbols problem.  See comments in the patch for more information.

Thanks!

Thanks for the patch. It works for me. Next time I will bug the gentoos directly. Seems to work faster that way. Nevertheless: Thank you.

This has been fixed in gnome-vfs...

sure? e.g. ne_stubs.c isn't in gnome-vfs/imported/neon/Makefile.am

Is this still an issue?

closing as incomplete. please reopen if this is still an issue.