| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Jonathan Groll <lists(at)groll(dot)co(dot)za>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Failure during initdb - creating dictionaries ... FATAL: could not access file "$libdir/libdict_snowball": No such file or directory |
| Date: | 2009-05-15 00:36:48 |
| Message-ID: | 4A0CB920.20806@postnewspapers.com.au |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tom Lane wrote:
> I don't recall the details at the moment, but I think we intentionally
> didn't adopt the .dylib extension for these files because of some subtle
> difference between them and plain shared libraries.
If I recall correctly from porting a plugin-based app to Mac OS X a few
years ago, there are issues with dlopen(...) on .dylib libraries.
I seem to remember having issues getting dylibs to resolve symbols from
the loading executable and already-loaded libraries; they wanted to
resolve all symbols as direct dependencies. I needed to use a .so to get
the library to resolve symbols in the loading application.
A quick bit of reading shows that:
- The extension doesn't matter, the OS doesn't care
- The library type, MH_DYLIB or MH_BUNDLE, is controlled by how
it's built only
- MH_DYLIB won't resolve symbols from the loading executable
and can't be unloaded, whereas MH_BUNDLE does and can.
- Most libraries on Mac OS X are MH_DYLIB
Found some info at:
under Fields, section "filetype"
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martin Gainty | 2009-05-15 00:47:58 | Re: Failure during initdb - creating dictionaries ... FATAL: could not access file "$libdir/libdict_snowball": No such file or directory |
| Previous Message | Sam Mason | 2009-05-15 00:33:15 | Re: Question on inserting non-ascii strings |