Re: [HACKERS] Examining the output of: ldd `which postgres`

2003-12-05 Thread Todd R. Eigenschink
[Up front: yes, I'm following up to a post that's nearly three months old. I can't find any more recent discussion of this issue.] [EMAIL PROTECTED] (Tom Lane) writes: > (Of course, if you can show that there's a significant penalty in > backend launch time from having useless shlibs linked in,

Re: [HACKERS] Examining the output of: ldd `which postgres`

2003-09-11 Thread Bruce Momjian
Sean Chittenden wrote: > > Backend only forks(). I think you would be better off using > > Makefile macros to _remove_ those two libraries. > > > > I see this: > > > > $(filter crypt.o getaddrinfo.o inet_aton.o snprintf.o strerror.o path.o > > thread.o, $(LIBOBJS)) > > > > Seems you need

Re: [HACKERS] Examining the output of: ldd `which postgres`

2003-09-05 Thread Tom Lane
Sean Chittenden <[EMAIL PROTECTED]> writes: >>> Is it really necessary for postgres to be linked with ncurses >>> (288K) and readline (156K)? It's .5M, not the end of the world, >>> but it seems excessive. I know the postmaster has a CLI >>> interface, but does it really require ncurses or readli

Re: [HACKERS] Examining the output of: ldd `which postgres`

2003-09-05 Thread Sean Chittenden
> > > We add those to all links, mostly because it is too confusing to > > > do it per link. It doesn't hurt anything because it is > > > dynamically linked, so doesn't take any disk space, and in fact > > > is never called. > > > > My concern wasn't for disk space, but for symbol resolution time

Re: [HACKERS] Examining the output of: ldd `which postgres`

2003-09-05 Thread Bruce Momjian
Sean Chittenden wrote: > > We add those to all links, mostly because it is too confusing to do > > it per link. It doesn't hurt anything because it is dynamically > > linked, so doesn't take any disk space, and in fact is never called. > > My concern wasn't for disk space, but for symbol resoluti

Re: [HACKERS] Examining the output of: ldd `which postgres`

2003-09-05 Thread Sean Chittenden
> > % ldd `which postgres` > > /usr/local/bin/postgres: > > libintl.so.5 => /usr/local/lib/libintl.so.5 (0x282e6000) > > libz.so.2 => /lib/libz.so.2 (0x282ef000) > > libreadline.so.4 => /lib/libreadline.so.4 (0x282fd000) > > libcrypt.so.2 => /lib/libcrypt.so.2 (0x283

Re: [HACKERS] Examining the output of: ldd `which postgres`

2003-09-05 Thread Bruce Momjian
Sean Chittenden wrote: > % ldd `which postgres` > /usr/local/bin/postgres: > libintl.so.5 => /usr/local/lib/libintl.so.5 (0x282e6000) > libz.so.2 => /lib/libz.so.2 (0x282ef000) > libreadline.so.4 => /lib/libreadline.so.4 (0x282fd000) > libcrypt.so.2 => /lib/libcrypt.

[HACKERS] Examining the output of: ldd `which postgres`

2003-09-05 Thread Sean Chittenden
% ldd `which postgres` /usr/local/bin/postgres: libintl.so.5 => /usr/local/lib/libintl.so.5 (0x282e6000) libz.so.2 => /lib/libz.so.2 (0x282ef000) libreadline.so.4 => /lib/libreadline.so.4 (0x282fd000) libcrypt.so.2 => /lib/libcrypt.so.2 (0x28325000) libm.so.2