Auto-disable shared libraries

[olly]

It'd be nice if configure could default to --disable-shared where we know shared libraries don't work. Ideally via a configure feature test if we can find a 100% reliable test (throwing an exception from a shared library?)

Richard suggests the following, as an autoconf test:

• build a library, with a function which throws an exception.
• build an application which links dynamically to the library, and calls the method.
• run the library - if the problem exists, a segfault will occur.

[olly]

I'm not totally convinced this is a good idea. Partly I worry that we won't find a 100% reliable test, in which case it will give a false sense of security.

Also I think it's perhaps better to fail if shared libraries don't work so

users report this and we can investigate why!

It was originally your idea - what are your thoughts?

[richard]

I can't remember the context of this suggestion, but it still seems like something that would be good to have a test for. I don't think any false security it might give is worse than the current approach of not dealing with the problem: at least users who come across the problem will be given an explanation by configure of what's going wrong (so the bug is shown to be at least partly the fault of their system), rather than getting an obscure failure at runtime (which would make it look like Xapian itself is flaky).

I'm guessing that this is related to the problem that we certainly used to have on Solaris, where throwing an exception across a shared library boundary caused a segfault.

A test which relies on a segfault happening isn't going to be 100% reliable, but I suspect it will fail in a good number of situations where there's a problem, and this in turn will prod us to get on with refactoring the error handling so that we only throw exceptions from public header files, and are able to support an API which doesn't use exceptions at all (which I think is the only solution when there is a problem with throwing exceptions across shared library boundaries).

[richard]

That said, I don't think this is a high priority bug in any sense - we're not exactly getting deluged with reports that there's a problem in this area now.

[olly]

The suggestions was culled from a mailing list mail ages ago - I went through filing old mailing list mail and moving potentially useful suggestions to the bug tracker.

Incidentally, the tinderbox build script has a list of cases for disabling the shared build, though I think some are just badly setup boxes or creaky old compilers. I think most of the entries only apply to boxes in the SF CF farm which no longer exists, so it's hard to verify this.

If someone's prepared to put the time in and come up with a usefully reliable test (I guess 100% reliable is hard to achieve at least in the face of as yet untried platforms) I guess we'd accept the patch. It needs to be someone with access to the platforms in question though, so I'm unassigning this as I don't!

[olly]

I'm closing with as "wontfix", since:

• This was originally an issue for GCC on Solaris (a moderately popular platform), but the shared library build now works in this case. So I'm not aware of any common platforms where this is actually an issue (or uncommon ones, but it's more likely that we wouldn't have had a report for those).

• The testsuite will exercise the throwing of exceptions across shared library boundaries, and so reveal problems.

• Nobody seems to be interested in working on this anyway.

If someone submitted patches, I'd be happy to consider them still, but I don't see any benefit in keeping this ticket open any longer.