On Tuesday 12 February 2002 3:04 am, Klaus Heinz wrote:
> Hi,
> 
> pkgsrc/Packages.txt mentions 'libtool' in chapter 6.2. My understanding
> of 'libtool' has been in the direction 'abstraction of shared library
> creation on _different_ platforms' but the text in Packages.txt
> seems to consider the NetBSD ports as different platforms.

This shouldn't be the case... which wording in particular are you referring 
to?

> Are the differences between the NetBSD ports (I guess this means a.out vs.
> ELF) big enough to warrant the introduction of 'libtool' into a package
> when the software (mainly a collection of libraries, textproc/ICU)
> already works out of the box on NetBSD (/i386) without libtool ?

Yes, unless the pkg has a different method for handling object format and 
command options. See below.

> Or is 'libtool' used in pkgsrc mainly for the non-NetBSD systems like
> Solaris, Linux and Darwin ?

No. It can be used by all OSes.

> Maybe the chapter on 'libtool' in Packages.txt could either be updated
> ('libtool is not necessary (anymore)') or more specific ('if your
> package builds shared libraries for public consumption _do_ use libtool').

I would hesitate at saying that if a pkg creates shared libraries you *must* 
use libtool. As stated above some pkgs have their own methods for dealing 
with the command and command option differences. If this exists its sometimes 
best to make use of it.

There are some pitfalls to be aware of on NetBSD, however.

	- Pre 1.4 cc -shared for a.out platforms didn't work. Use ld -Bshareable
	- Some versions of a.out NetBSD/sparc need to use an -fPIC (not -fpic)
	  c++rt0.o (see sysutils/c++rt0)
	- Some pre-1.5 toolchains mistakenly pulled in libgcc.a when using -shared.

Nick