Hi Nick Hudson, you wrote:
> On Tuesday 12 February 2002 3:04 am, Klaus Heinz wrote:

> > 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?

The Introduction of Chapter 6.2:

  'NetBSD supports many different machines, with different object formats
   ...varying abilities to do shared library...
   ...thus being platform independent.'

> > 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.

I know it _can_ :). I wanted to say: do the packages which use libtool do so
because of differences between NetBSD ports or for the sake of those other
platforms (Solaris, etc.).
I guess most packages use libtool because the software itself already uses it.

Does anybody know examples where libtool was introduced during the
packaging process ?

> 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.

Ok, I can fully agree with that. If the software solves the problem of
creating libraries in its own way we use that, no use in complicating things.


The example I know best, because I am trying to update it, is text/icu.
This software does indeed support many different platforms and (Net)BSD
is among them, the new version 2.0  works out of the box, to the last
test case.
The platform dependant config file mh-bsd-gcc does provide macros
for creating shared libraries:

  SHLIB.c=        $(CC) $(DEFS) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -shared
  SHLIB.cc=       $(CXX) $(DEFS) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -shared

This assumes, the compiler on NetBSD understands '-shared', which seems
not to be the case on every NetBSD port (or older versions).

Should we use libtool here ? (If we should, this would include more work
than just redefining those two macros...)

ciao
     Klaus