Cc'ing tech-pkg@, for any further discussion about pkgsrc's libtool
package.

Nick Hudson <nick.hudson@dsl.pipex.com> writes:
> On Saturday 03 November 2007 17:33:48 J.T. Conklin wrote:
>> So while Thor's right that "libfool" (heh) is wrong in suppressing the
>> libpthread dependency,
>
> This is with an explicit -lpthread?

No, this was with -pthread.  Linking with an explicit -lpthread does
record the dependency.  I'd argue that it still shouldn't be needed;
If "gcc -pthread ..." is enough to link a pthread using application,
so should "libtool --mode=link gcc -pthread ...".

While experimenting with this, I discovered the /usr/pkg/bin/libtool
script (from pkgsrc-97Q3) records the libpthread dependency; but the
libtool script integrated into application directories with libtoolize
(also from pkgsrc-97Q3) does not.  The two libtool scripts use totally
different means to link the shared library. The installed libtool just
does "gcc -shared", while the libtoolized libtool does "gcc -nostdlib
/usr/lib/crti.o /usr/lib/crtbeginS.o ...".

This lead me to check out the pkgsrc libtool -- and it appears that
this is deliberate.  The installed libtool contains fixes that will 
not be in a libtoolized version.  From manual.README:

    The "manual-*" patch files are used to maintain the pkgsrc version
    of libtool.  These files contain patches for the .m4 files in
    libtool which are used to generate libtool's own "configure"
    scripts.

    These patches are not part of the automatic patches because
    libtool also installs these .m4 files at runtime, and we want the
    "off-the-shelf" versions of those files used instead -- we do NOT
    want the modified libtool.m4 copied into third party packages for
    reproducability and GPL reasons.  So, when it comes time to update
    libtool, the following process must be used:

This sounds reasonable, but it seems that there are some patches that
really need to be pushed upstream.  Otherwise, pthread-using packages
will not have the libpthread dependencies they require, and thus won't
work properly on NetBSD systems.

    --jtc

-- 
J.T. Conklin