libtool, OpenBSD, plugins, large breakage

[Marc Espie]

[Note the crosspost. Yep, this is an utterly messy problem. Yep, I'm fed up
of having to deal with a bazillion versions of that huge nightmare called
libtool which does never work right on some OSes...]

I'm not sure kde makes consistent use of -module and -avoid-version with
respect to libtool.

I think I will need to introduce a new version_type specifically for
OpenBSD.

The issue is that all shared libraries *must* be of the form
libfoobar.so.<major>.<minor>

otherwise, -lfoobar won't work. And no, we won't change that. We use that
model even on ELF systems, it's perfectly sane and working.

Now, plugins are another story. A module that is just meant to be dlopened
can be named module.so, without any problem.

It becomes interesting, because style plugins (for instance) can either be
built correctly  as plugin.so, which gets libraries to break (e.g., the
dcopserver `module' is built with -module -avoid-version, and then linked
with -ldcopserver -> ouch), or built incorrectly, as libplugin.so.0.0,
and then libraries work (but qt3 doesn't find the plugins until patched
to handle *.so.*, and it might be that libltdl and other parts of kde do
not as well).

I really would like to know what the solution is.  Specifically, what's
the deal with -module -avoid-version ?  Either I need to have a way to
differentiate with stuff that will be used with dlopen, or linked in as 
a library, or if I don't, things are going to be very, very messy with
respect to symbolic links.

My understanding of the problem so far is that kde abuses -module
-avoid-version, and that, correctly, I should get libfoo.so.0.0 if
-avoid-version is specified, and foo.so is -avoid-version -module is
specified... then a module is only used through dlopen, and so for.

Am I correct ?

How to go about fixing libtool ? Looks to me that the best way is to
have version_type=openbsd, and handle things quite a lot like sunos,
except for this very important thing.