ns_server shouldn't use the path to the modules memcached should load...

trond@storm:2006> pfexec pargs 2890 ~
2890: ./bin/memcached/memcached -X ./bin/memcached/stdin_term_handler.so -p 11210 -E
argv[0]: ./bin/memcached/memcached
argv[1]: -X
argv[2]: ./bin/memcached/stdin_term_handler.so
argv[3]: -p
argv[4]: 11210
argv[5]: -E
argv[6]: ./bin/bucket_engine/bucket_engine.so
argv[7]: -B
argv[8]: binary
argv[9]: -r
argv[10]: -c
argv[11]: 10000
argv[12]: -e
argv[13]: admin=_admin;default_bucket_name=default;auto_create=false
argv[14]:

On Solaris we would have the 32 bit libraries installed in "lib" and the 64-bit version of the same library would be installed in "lib/64" (that's a symbolic link to amd64/sparcv9 etc). We add a "linker runtime path" in our binaries (supported on Solaris and Linux) when we build memcached, so it should be able to locate the correct binary at runtime even if you start it with "./memcached -E ep.so". Mac OSX don't support this, so we would have to export DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH in the membase startup script. The runtime linker on windows will search the same directory as the binary.

THis would work on Solaris/Linux and Windows: memcached -X stdin_term_handler.so -p 11210 -E bucket_engine.so -B binary -r -c 100000 -e admin=........