Shared library interdependencies
От | Peter Eisentraut |
---|---|
Тема | Shared library interdependencies |
Дата | |
Msg-id | Pine.LNX.4.21.0006151624180.399-100000@localhost.localdomain обсуждение исходный текст |
Ответы |
Re: Shared library interdependencies
|
Список | 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 по дате отправления: