[geos-devel] geos-2.2.0 / FreeBSD 4

strk at refractions.net strk at refractions.net
Fri Jan 6 09:51:59 EST 2006

On Thu, Jan 05, 2006 at 11:38:56PM +0100, Eric Faurot wrote:
> On 12/30/05, strk at refractions.net <strk at refractions.net> wrote:
> Sorry for answering that late.
> > Mm... my libtool responds with:
> > libtool: invalid tag name: CXX c++
> >
> > Does this have to do with the "do not force use of your libtool"
> > request below ? Note that the `libtool' script is NOT shipped
> > with GEOS package, only the ltmain.sh script, as reccommended
> > in the libtool info page.
> OpenBSD provides its own libtool that we really want to use.
> I thought I saw a LIBTOOL=$(topbuildir)/libtool or something like that,
> but I must have dreamed...

mmm.. you're right, no dreams. It's in aclocal.m4:

	# Always use our own libtool.
	LIBTOOL='$(SHELL) $(top_builddir)/libtool'

Don't know the rationale of this. Maybe the fact that
"our own" libtool is generated... anyone else's experience ?

> > > The corrolary is that postgis 1.1.0 now fails because it uses the capi
> > > and the liblwgeom.so is incorrectly linked, so postgres cannot dlopen it
> > > (undefined reference to C++ symbols)...
> >
> > Maybe OpenBSD *needs* to explicitly link libstdc++ ?
> > I think we can safely always include libstdc++ link in postgis
> > build scripts... they would not hurt.
> > Could you check that adding -lstdc++ in SHLIB_LINK line of lwgeom/Makefile
> > (around line 46) fixes the problem ?
> -lstdc++ works, but I also need -lm. I can live with that, though.
> FYI, you can find the ports at:
> http://ekyo.nerim.net/openbsd/ports/geos.tgz
> http://ekyo.nerim.net/openbsd/ports/postgis.tgz
> There are a few other patches that you might want to integrate into
> your tree, but IMHO, it is generaly better to let packagers write small
> patches than making the configure process too complicated.

Well, I think it's good for builders to have a working build method.
It's not only packagers, but also final user (I build from sources a lot!).

Chances are there's a way to explicitly define dependencies and let
libtool decide wheter to pass that info to the linker or not...

Again, help is welcome.


More information about the geos-devel mailing list