It looks as though you are using the 1.3.5 distribution which does have
problems for NetBSD.

Steinar Hamre wrote:
> Ok, everyone hates libtool for always beeing so wrong. But we still
> have to fix it. libtool -module on netbsd/elf creates an 'ar'-archive,
> and *wow* that does not work with dlopen(). So I've tried fixing
> libtool on netbsd/elf a little bit. It would be very nice if somebody
> told me if I'm doing anything awfully wrong before i send this to the
> libtool maintainers.
> 
> First,echo __ELF__ | $CC -E - | grep __ELF__is true if the the
> toolcain is *not* elf. So the first test was inversed.

This is fixed in the pkgsrc libtool.

> secondly there is no problem making and using a library named `u'
> need_lib_prefix=no
> need_version=no
> 
> LD_LIBRARY_PATH overrides the binary's RPATH
> shlibpath_overrides_runpath=yes

This is in the libtool cvs repository along with hardcode_into_libs=yes
 
> file_magic seems to be the most sensible deplibs_check_method. (better
> than unknown, anyway)

This is in pkgsrc and cvs libtool.

> The (seriosly misnamed) version_type `linux' seems to be the most
> sensible one. It's used by most elf and ecoff platforms. The only real
> alternative is `freebsd-elf'. The difference is: `linux' uses 3-digit
> versioning libfoo.so.$major.$age.$minor (major=$current-$age) whereas
> `freebsd-elf' uses 1-digit versioning libfoo.so.$current

I've not look at this one...

> $ libtool --mode=link gcc -version-info 6:1:4 [...]   will create
> libfoo.so.2.4.1 (soname libfoo.so.2)  using `version_type=linux'
> libfoo.so.6     (soname libfoo.so.6)  using `version_type=freebsd-elf'

I presume the 2 in a typo?!?

Nick