I'm configuring with `./configure --prefix=/usr/local/Cellar/postgresql/8.4.0`, without sudo. I hawe chowned /usr/local so that I don't need to sudo it. I'm getting the following error when running `initdb` after successfully compiling postgresql
Here's the full output.
augustl@honk:~$ initdb -D /usr/local/Cellar/postgresql/8.4.0/defaultdb
The files belonging to this database system will be owned by user "augustl".
This user must also own the server process.
The database cluster will be initialized with locales
COLLATE: C
CTYPE: UTF-8
MESSAGES: C
MONETARY: C
NUMERIC: C
TIME: C
The default database encoding has accordingly been set to UTF8.
initdb: could not find suitable text search configuration for locale UTF-8
The default text search configuration will be set to "simple".
creating directory /usr/local/Cellar/postgresql/8.4.0/defaultdb ... ok
creating subdirectories ... ok
selecting default max_connections ... 20
selecting default shared_buffers ... 2400kB
creating configuration files ... ok
creating template1 database in /usr/local/Cellar/postgresql/8.4.0/defaultdb/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... FATAL: could not load library "/usr/local/Cellar/postgresql/8.4.0/lib/ascii_and_mic.so": dlopen(/usr/local/Cellar/postgresql/8.4.0/lib/ascii_and_mic.so, 10): Symbol not found: _check_encoding_conversion_args
Referenced from: /usr/local/Cellar/postgresql/8.4.0/lib/ascii_and_mic.so
Expected in: /usr/local/Cellar/postgresql/8.4.0/bin/postgres
in /usr/local/Cellar/postgresql/8.4.0/lib/ascii_and_mic.so
STATEMENT: CREATE OR REPLACE FUNCTION ascii_to_mic (INTEGER, INTEGER, CSTRING, INTERNAL, INTEGER) RETURNS VOID AS '$libdir/ascii_and_mic', 'ascii_to_mic' LANGUAGE C STRICT;
child process exited with exit code 1
initdb: removing data directory "/usr/local/Cellar/postgresql/8.4.0/defaultdb"
augustl@honk:~$
I found something on google about the file ascii_and_mic.so not existing, but that's not the case here; the file does indeed exist. Googling _check_encoding_conversion_args doesn't yield any results.
