clisp: nolibsigsegv variant does not disable libsigsegv

[ryandesign (Ryan Carsten Schmidt)]

In r15727 a nolibsigsegv variant was added to try to fix #5880 and #6084, but this variant does not actually prevent the use of libsigsegv if it is already installed. (Greg already knew this when he added it as seen in ticket 5880 comment 5 and ticket 6084 comment 5.)

In r61269 a platform darwin 10 section was added which does the same thing as the nolibsigsegv variant on Snow Leopard. Do we remember why this was done? It seems to build fine with libsigsegv. If this was done because clisp builds 32-bit only and we did not want to force users to manually build dependencies universal, then this is no longer a problem because MacPorts 1.9+ does so automatically (now that I have fixed clisp in r69484 to indicate its supported architectures).

The implication of this is that if a Snow Leopard user installs libsigsegv and then clisp (or, perhaps less commonly, if a Leopard or Tiger user installs libsigsegv and then installs clisp with the +nolibsigsegv variant), clisp will link with libsigsegv anyway but will not declare a dependency on it, thus allowing the user to later uninstall libsigsegv and encounter problems like #25496.

clisp @2.48_1 builds fine for me with libsigsegv on Snow Leopard x86_64, Leopard ppc, Tiger ppc and Tiger i386. I propose removing the platform darwin 10 section and the nolibsigsegv variant (so that libsigsegv support is always enabled) and increasing the revision to push this change out to everyone.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

I propose removing the platform darwin 10 section and the nolibsigsegv variant (so that libsigsegv support is always enabled) and increasing the revision to push this change out to everyone.

Done in r74017 (maintainer timeout).