post-patch blues with db3, db4, db41
Sean McNeil
sean at mcneil.com
Sat Jun 5 21:25:02 GMT 2004
On Sat, 2004-06-05 at 14:13, Michael Nottebrock wrote:
> On Saturday 05 June 2004 21:16, Sean McNeil wrote:
> > Hi,
> >
> > There are post-patch targets for these ports that are causing issues
> > with the libraries built. The target:
> >
> > post-patch:
> > @${REINPLACE_CMD} -Ee \
> > 's|-l?pthread|${PTHREAD_LIBS}|g'
> > ${WRKSRC}/${CONFIGURE_SCRIPT}
> >
> > causes the library to be linked with libpthread.so. This is a
> > dependency that we do not want. It will in turn cause issues with
> > nss_ldap and db doesn't use any threading. It is thread safe, but that
> > doesn't mean it should be linked with pthread.
>
> db links to a threads lib by default all by itself, the REINPLACE simply makes
> sure it's linked to the right lib.
Not true. The REINPLACE changes it so that the shared library is
created with -lpthread instead of -pthread. This causes the library to
include libpthread.so.1 as seen by ldd. The applications correctly link
with the pthread library (at least for db41). There is no need to have
/usr/local/lib/libdb41.so.1 require libpthread.so.1. This is wrong.
> >
> > I took out that target from my build of db41 and all is well for me.
> > With it in, nss_ldap ends up causing all sorts of bad things to happen
> > because it uses db41 (via openldap and sasl) and it in turn pulls in
> > pthread when it shouldn't.
>
> It would seem nss_ldap needs to be fixed to be threads safe.
nss_ldap is thread safe. Yet any nss* module should not itself cause
the thread library to be pulled into an application. In fact, here is a
general rule:
No shared library that does not explicitly call pthread functionality
(i.e. pthread* functions) should be linked to require libthread.
This is a simple rule that db3, db4, and db41 do not follow. Removing
the REINPLACE makes it follow the rule.
I have tested this and found that this to be true.
Sean
More information about the freebsd-ports
mailing list