Shared library interdependencies

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Shared library interdependencies
Дата
Msg-id Pine.LNX.4.21.0006151624180.399-100000@localhost.localdomain
обсуждение исходный текст
Ответы Re: Shared library interdependencies  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
When the libpq shared library is linked on my system it looks like this:

ld -Bdynamic -shared -soname libpq.so.2.1 -o libpq.so.2.1 fe-auth.o
fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o pqexpbuffer.o
dllist.o pqsignal.o   -lcrypt -lc

Now if I build a Kerberos IV enabled version it looks like

ld -Bdynamic -shared -soname libpq.so.2.1 -o libpq.so.2.1 fe-auth.o
fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o pqexpbuffer.o
dllist.o pqsignal.o   -lcrypt -lkrb -ldes -lc

Note that the relevant Kerberos libraries are specified so the user
doesn't have to remember linking his libpq programs against Kerberos.

My question is, shouldn't libpq be linked against *all* the libraries that
are detected at configure time? Imagine that libpq uses something from,
say, -lbsd. We'd never know because psql links against -lbsd so everything
is resolved but the end user may not know that and fail to link his
programs against -lbsd. I guess what I'm saying is, there seems to be a
double standard of -lcrypt, -lc, -lkrb, and -ldes versus all other
libraries.

Any library guru care to enlighten me?

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vince Vielhaber
Дата:
Сообщение: Re: commit the contrib clean up
Следующее
От: Lamar Owen
Дата:
Сообщение: Re: Mandrake RPMS, was "Building PostgreSQL 7.0.1 documentation"