vmware view is not able to load opensc

[dontsueme]

Hello there,

today I tried to let vmware view load OpenSC as PKCS#11 module. For that you have to create the folder /usr/lib/vmware/view/pkcs11 and symlink the PKCS#11 library. Creating a symlink with the original filename does not work out for vmware view, because then it tries to access libopensc-pkcs11.so.so. So I renamed it to libopensc-pkcs11.so, which does the trick.

ln -s /usr/lib/pkcs11/opensc-pkcs11.so /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so

But then, when it tries to load the module, following error occurs:

vmware-view.log:

Sep 12 16:21:47.418: vmware-view 4357| Initializing smartcard modules
Sep 12 16:21:47.418: vmware-view 4357| Attempting to load cryptoki module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so
Sep 12 16:21:47.418: vmware-view 4357| Could not resolve C_Initialize from /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so
Sep 12 16:21:47.419: vmware-view 4357| Loaded 0 modules from /usr/lib/vmware/view/pkcs11

CoolKey, Gemalto and other pkcs#11 implementations are working fine. So, I guess, there is a problem with OpenSC.

OpenSC versions tried: 0.13.0 and 0.12.2
Version from VMware View: 2.1.0

Best regards…

[LudovicRousseau]

Can you load the same PKCS#11 in another application like Firefox?
Does it work?

[dontsueme]

Yep, OpenSC 0.12.2 and 0.13.0 do work with Firefox.

[dontsueme]

I want to add, that OpenSC 0.12.1 works.

[viktorTarasov]

I don't know how vmware-view initialize cryptoki module. Does it firstly calls C_Initialize without passing by C_GetFunctionList ?

OpenSC PKCS11 module exports only C_GetFunctionList .

[dengert]

PKCS#11 2.01 Section 10.4 C_GetFunctionList...

"C_GetFunctionList is the only Crypto function which an application may call before calling C_Initialize."
To me, this implies that at least C_Initialize should be exported. It also imply that all the entrypoints should be exported. Most callers of PKCS#11 use the C_GetFunctionList, but it sounds like Vmware-view does not.

[martinpaljak]

Then it seems like a bug for vmware-view? How/why vmware-view needs OpenSC pkcs11 module in the first place? I've only used it with USB devices...

[dengert]

On 10/21/2013 12:11 PM, Martin Paljak wrote:

Then it seems like a bug for vmware-view? How/why vmware-view needs OpenSC pkcs11 module in the first place? I've only used it with USB devices...

No. If Its OK to call C_Initialize before C_GetFunctionList then C_Initialize better have be exported.
Sounds like vmware may be linking the library, not dynamically loading a module. It may expect all entries
to be exported. It means it is not very flexible, but then again OpenSC should be flexible to
allow for linking.

A simple test would be to build pkcs11-spy with C_Initialize and C_GetFunctionList exported and see,
if pkcs11-spy would work. (Or build opensc-pkcs11 with both exported and see how far vmware gets.

—
Reply to this email directly or view it on GitHub #183 (comment).

Douglas E. Engert [email protected]
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

[martinpaljak]

Yes, re-reading the latest PKCS#11 v2.30, which does not make it more clear, it feels like C_GetFunctionList is a convenience function that just happens to be used by most software currently known, but which is not mandatory to be used for querying the entry points. So yes, indeed it seems like reverting the export file is the right action..

[viktorTarasov]

On Mon, Oct 21, 2013 at 8:27 PM, Doug Engert [email protected]:

On 10/21/2013 12:11 PM, Martin Paljak wrote:

Then it seems like a bug for vmware-view? How/why vmware-view needs
OpenSC pkcs11 module in the first place? I've only used it with USB
devices...

No. If Its OK to call C_Initialize before C_GetFunctionList then
C_Initialize better have be exported.

Only C_Initialize or all the C_* functions of PKCS#11 ?

[martinpaljak]

All of this: 5a23069

[dengert]

On 10/22/2013 3:07 AM, Martin Paljak wrote:

All of this: 5a23069 5a23069

Should pkcs11-spy.exports also be updated?
Without the updated list, vmware could not use spy.

—
Reply to this email directly or view it on GitHub #183 (comment).

Douglas E. Engert [email protected]
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

[martinpaljak]

All PKCS#11 module exports. The change was inspired by another change somewhere I can't find at the moment..

[frankmorgner]

could someone check if #340 fixes the problem?

[dengert]

In #183 there were some requests to try some other tests, Have these been tried?
It has been over a year since the bug report, has vmware view changed?

In #183 the bug reporter (dontsueme) said he has to change the symlink, as vmware view would
add lib.s0. That sounds very strange, and how was vmware view loading the module?

PKCS#11 are modules, which may be different then shared libs. modules are meant
to be loaded dynamically. So how is vmware view loading the module?
Whey does it require lib.so

Reverting all of the changes does not sounds like the correct solution.
May be allowing C_Initialize and C_GetFunctionList to exported would be all that is needed.

Goolge'ing for vmware view PKCS#11
has a lot of posting, including:

https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770

Note it says get vmware to fix their dynamic load code.

Reverting all of the changes does not sounds like the correct solution.
Maybe allowing C_Initialize and C_GetFunctionList to exported would be all that is needed.
As suggested by the above.

Or maybe better still, create a libopensc-pkcs11.so as a share lib, with all the exports,
but don't change opensc-pkcs11.so?

On 12/19/2014 4:32 AM, Frank Morgner wrote:

could someone check if #340 #340 fixes the problem?

—
Reply to this email directly or view it on GitHub #183 (comment).

Douglas E. Engert [email protected]

[frankmorgner]

The standard itself is really not clear about it. However, the official pkcs11.h (see http:https://www.cryptsoft.com/pkcs11doc/STANDARD/include/v230/ ) defines the following:

/* ==============================================================
 * Define the "extern" form of all the entry points.
 * ==============================================================
 */

#define CK_NEED_ARG_LIST  1
#define CK_PKCS11_FUNCTION_INFO(name) \
  extern CK_DECLARE_FUNCTION(CK_RV, name)

/* pkcs11f.h has all the information about the Cryptoki
 * function prototypes. */
#include "pkcs11f.h"

While I hate all those macros, I think this means that all functions in pkcs11f.h are defined here. If I am not mistaken, then OpenSC's internal pkcs11.h does the same. As consequence, the symbols should also be exported by the shared pkcs11 library (thus, it should be exported by pkcs11-spy, too).

[dengert]

Is there anyone on this list that can try vmware client?

On 12/19/2014 2:37 PM, Frank Morgner wrote:

The standard itself is really not clear about it. However, the official |pkcs11.h| (see http:https://www.cryptsoft.com/pkcs11doc/STANDARD/include/v230/ ) defines the following:

Yes, the standards including the Oasis 2.40 drafts are very vague.

In the 2.30 header files:
http:https://www.cryptsoft.com/pkcs11doc/STANDARD/include/v230/

it has:

/* Before including this file (pkcs11.h) (or pkcs11t.h by

• itself), 6 platform-specific macros must be defined. These
• macros are described below, and typical definitions for them
• are also given. Be advised that these definitions can depend
• on both the platform and the compiler used (and possibly also
• on whether a Cryptoki library is linked statically or
• dynamically).

Note that it talks about dynamic vs static, but does not say what to do.
The standards including the Oasis 2.40 drafts appears to leave it up to the PKCS#11 vendor.

|/* ==============================================================

• Define the "extern" form of all the entry points.
• ==============================================================
  */

#define CK_NEED_ARG_LIST 1
#define CK_PKCS11_FUNCTION_INFO(name)
extern CK_DECLARE_FUNCTION(CK_RV, name)

/* pkcs11f.h has all the information about the Cryptoki

• function prototypes. */
  #include "pkcs11f.h"
  |

While I hate all those macros, I think this means that all functions in |pkcs11f.h| are defined here. If I am not mistaken, then OpenSC's internal |pkcs11.h| does the same. As consequence, the symbols
should also be exported by the shared pkcs11 library (thus, it should be exported by pkcs11-spy, too).

Before we go ahead an expose all of the entry points because vmware view has a problem,
can we get someone to try the latest vmware client again with these cases:

(1) latest version of vmware client and using the symlink as opensc-pkcs11.so -> opensc-pkcs11.so
Only C_GetFunctionList is exported.

(2) latest version of vmware client and using the symlink as libopensc-pkcs11.so -> opensc-pkcs11.so
Only C_GetFunctionList is exported.

(3) latest version of vmware client and using the symlink as opensc-pkcs11.so -> opensc-pkcs11.so
C_GetFunctionList and C_Initialize are exported.

(4) latest version of vmware client and using the symlink as libopensc-pkcs11.so -> opensc-pkcs11.so
C_GetFunctionList and C_Initialize are exported.

(5) latest version of vmware client and using the symlink as opensc-pkcs11.so -> opensc-pkcs11.so
All functions are exported.

(6) latest version of vmware client and using the symlink as libopensc-pkcs11.so -> opensc-pkcs11.so
All functions are exported.

(1) and (2) are reported to fail as of last year.

https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770

I suspect that the vmware view code is loading the modules and looking for C_Initialize. If it does not
find it, it tries again by adding lib.so to what ever name was found in their pkcs11 directory.

If (3) works, then go with that.

If (4) works, then go with that, same as (3) for OpenSC its the same thing. Just that vmware has a strange
way of loading modules.

If it takes (5) or (6) then we go with that.

—
Reply to this email directly or view it on GitHub #183 (comment).

Douglas E. Engert [email protected]

[dontsueme]

Hello there,

I wasn't aware, that the discussion was still ongoing, because I had the impression at one point, that the symbols are just going to be exported again. But well, I had to update OpenSC to 0.15.0 and was running in the same problem two years ago. At least I still could easily revert the patch myself. And after reading this thread here, I'm still having troubles to understand, why those symbols aren't exported anymore. There seems to be no explanation except "because we won't".

@dengert
VMware Horizon View for Linux is downloadable here: https://my.vmware.com/web/vmware/details?downloadGroup=VIEWCLIENTS_LINUX_34&productId=421&rPId=8308 . Please test what you need to test, so the bug report can closed finally.

I also have checked 6 other PKCS#11 implementations from various vendors, like coolkey and they are fine with exporting those symbols. No really, they all look like this: https://gist.github.com/dontsueme/91ca9a0d0eff6c9ed990

So why are the OpenSC developers against it?

[frankmorgner]

@dontsueme could you check whether exporting C_Initialize additionally is sufficient?

[dontsueme]

@frankmorgner
with C_Initialize added, i get

Could not resolve C_Finalize from /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so

[dontsueme]

(1) latest version of vmware client and using the symlink as opensc-pkcs11.so -> opensc-pkcs11.so
Only C_GetFunctionList is exported

vmware-view 18814| Initializing smartcard modules
vmware-view 18814| Attempting to load cryptoki module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so
vmware-view 18814| Could not open module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so: /usr/lib/vmware/view/pkcs11/libopensc-pkcs11
vmware-view 18814| Loaded 0 modules from /usr/lib/vmware/view/pkcs11

(2) latest version of vmware client and using the symlink as libopensc-pkcs11.so -> opensc-pkcs11.so
Only C_GetFunctionList is exported.

vmware-view 19265| Initializing smartcard modules
vmware-view 19265| Attempting to load cryptoki module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so
vmware-view 19265| Could not resolve C_Finalize from /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so
vmware-view 19265| Loaded 0 modules from /usr/lib/vmware/view/pkcs11

(3) latest version of vmware client and using the symlink as opensc-pkcs11.so -> opensc-pkcs11.so
C_GetFunctionList and C_Initialize are exported.

vmware-view 20650| Initializing smartcard modules
vmware-view 20650| Attempting to load cryptoki module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so
vmware-view 20650| Could not open module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so: /usr/lib/vmware/view/pkcs11/libopensc-pkcs11
vmware-view 20650| Loaded 0 modules from /usr/lib/vmware/view/pkcs11

(4) latest version of vmware client and using the symlink as libopensc-pkcs11.so -> opensc-pkcs11.so
C_GetFunctionList and C_Initialize are exported.

vmware-view 21106| Initializing smartcard modules
vmware-view 21106| Attempting to load cryptoki module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so
vmware-view 21106| Could not resolve C_Finalize from /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so
vmware-view 21106| Loaded 0 modules from /usr/lib/vmware/view/pkcs11

(5) latest version of vmware client and using the symlink as opensc-pkcs11.so -> opensc-pkcs11.so
All functions are exported.

vmware-view 6955| Initializing smartcard modules
vmware-view 6955| Attempting to load cryptoki module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so
vmware-view 6955| Could not open module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so: /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.
vmware-view 6955| Loaded 0 modules from /usr/lib/vmware/view/pkcs11

(6) latest version of vmware client and using the symlink as libopensc-pkcs11.so -> opensc-pkcs11.so
All functions are exported.

vmware-view 7364| Initializing smartcard modules
vmware-view 7364| Attempting to load cryptoki module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so
vmware-view 7364| Loaded 1 modules from /usr/lib/vmware/view/pkcs11

and because people are going to ask for sure:

(7) C_GetFunctionList, C_Initialize and C_Finalize are exported.

vmware-view 7787| Initializing smartcard modules
vmware-view 7787| Attempting to load cryptoki module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so
vmware-view 7787| Loaded 1 modules from /usr/lib/vmware/view/pkcs11

BUT be aware, that I can't test (7) completely. Even if it was loaded, I can't say for sure, that it won't fail later. (6) is tested and known to work.

[dengert]

How about a compromise, in addition to building the opensc-pkcs11.so as a MODULE, change the Makefile to also build a libopensc-pkcs11.so as a SHARED LIBRARY with the PKCS#11 routines exported, to accomadate programs that don't know how to get entry points from a dynamicly loaded MODULE.

The main reason PKCS#11 implementations are module, as it allows an application such as NSS to load multiple implementations, at the same time.

Also...
Is the vmware-client is open source? (I can't find it.)

https://communities.vmware.com/message/2483258

As best as I can tell, he is installing the 32 bit version on a 64 bit system, and the only bundle I could fine was:
https://download3.vmware.com/software/view/viewclients/CART15Q1/VMware-Horizon-Client-3.4.0-2769709.x86.bundle

Are you running 32 or 64 bit?

[dontsueme]

Hi dengert.

Did you acknowledge, that all other PKCS#11 implementation do export those symbols and they do work fine with firefox for instance?

I have tested on a 32bit only installation and as far as I know is the VMware View client not opensource (anymore). The self extracting tar should have both versions (x86/x86_64) included.

So, if you want to create two shared libraries, one with all symbols exported and one only reduced to the bare minimum (so the intention that it should only be used as a module is clear), would be fine for me, as long as you support both versions.

[dontsueme]

The source of an older version of the client is available (vmware view open client). Here for instance: http:https://packages.ubuntu.com/en/precise/x11/vmware-view-open-client

Here is the part, that loads the module:
https://github.com/dontsueme/vmware-view-open-client/blob/master/gtk/cryptoki.cc#L681

Which seems like a quite sane implementation to me.

Edit: created a mirror: https://github.com/dontsueme/vmware-view-open-client
Edit2: the forced lib*.so filename just comes from a poor use of g_module_build_path(). Nothing to worry about.

[dengert]

This appears to show how it finds the name of the module:
https://developer.gnome.org/glib/stable/glib-Dynamic-Loading-of-Modules.html

Could this be an issue with a LD_LIBRARY_PATH needing to be set?
especially if you tried building 0.15.0

ldd would show what libraries it needs.

[dengert]

If I am readind the C++ correctly:
Only c_Initialize, C_GetFuncList, and C_Finalize need to be exported.

GetFuncs is gotten via:
g_module_symbol(mModule, "C_GetFunctionList", (gpointer *)&cGetFuncs)) {

funcs is gotten via:
rv = cGetFuncs(&funcs);

and
mFuncs = func;
Other routines are called by:
mFuncs.C_ (...)

g_module_symbol says it uses dlopen,so it is still not clear why g_module_symbol even needs these exported if it is calling dlsym. The only difference I see is Vmware is using the G_MODULE_BIND_LOCAL flag, which should map to the dlopen RTLD_LOCAL which says "This is the converse of RTLD_GLOBAL, and the default if neither flag is specified."

Actually trying to use opensc-spy might also help, as it shows the PKCS#11 calls as they are made.

OpenSC also have an issue if C_getSotLists is not called befire an attempt to use a slot is made.
It might be related. Spy would show this.

Please checkout LD_LIBRARY_PATH to make sure you are not having an issue when loading mismatched opensc-pkcs11, libopenssc.so and openssl's libcrypto.so.

[dengert]

On 8/27/2015 8:30 AM, dontsueme wrote:

Hi dengert.

Did you acknowledge, that all other PKCS#11 implementation do export those symbols and they do work fine with firefox for instance?

I heard you said that.

Did you acknowledge that OpenSC also works fine with other applications that don't need the symbols exported?
This still sounds like a VMware issue, but it is not obvious WHY.

I have tested on a 32bit only installation and as far as I know is the VMware View client not opensource (anymore). The self extracting tar should have both versions (x86/x86_64) included.

So, if you want to create two shared libraries, one with all symbols exported and one only reduced to the bare minimum (so the intention that it should only be used as a module is clear), would be
fine for me, as long as you support both versions.

That was an idea and it looks like once the module is created, the support issues would be next to nothing.
Does someone (you?) want to submit changes to do this?

I did not hear from any other developers if that is acceptable. Its OK with me.

—
Reply to this email directly or view it on GitHub #183 (comment).

Douglas E. Engert [email protected]

[dontsueme]

Did you acknowledge that OpenSC also works fine with other applications that don't need the symbols exported?

Doesn't matter. Now you have one case that doesn't.

This still sounds like a VMware issue, but it is not obvious WHY.

Look, I gave you the implementation. It clearly uses g_module_symbol () for C_Initialize, C_GetFunctionList and C_Finalize, which states that it looks for exported symbols and you are still asking, why it needs them? It needs them, because it is implemented that way. Because every other vendor has exported those symbols and it worked in their test cases. It's obvious, that the chance that someone is actually using them, if they are there, is actually quite high. Just acknowledge that. It's not a subject, that can be discussed away. We can't change that.

Does someone (you?) want to submit changes to do this?

I want to revert that patch, that removed those symbols from being exported, because there is no explanation, why linking should be forbidden. If someone wants to use the OpenSC PKCS#11 implementation exclusively, then let them.

Please checkout LD_LIBRARY_PATH to make sure…

It's hardcoded:
https://github.com/dontsueme/vmware-view-open-client/blob/master/gtk/window.cc#L860
https://github.com/dontsueme/vmware-view-open-client/blob/master/gtk/cryptoki.cc#L147

They just look for files in one path, that are ending with *.so and load, what survives a simple sanity check.

[dengert]

@frankmorgner (or other developers)
Any comments on two modules, one with no exports and a libopensc-pkcs11 built with all pkcs#11 functions exported?

It looks like just changes to the Makefile.am and an extra exports file to create the extra lib. Not clear if it should still be a module or not.

I am not getting very far trying to build the vmware-client from source, or installing it.
Only the old version is open source.
@dontsueme is not the only user trying to get vmware to use OpenSC.

[martinpaljak]

I don't think that sloppy implementation should be encouraged, but it also doesn't hurt to export two more functions (C_GetFunctionList, C_Initialize and C_Finalize) if that would make an application work and user satisfied. And the vendor notified. What about this ?

[dengert]

Yes, I thing that would work for vmware-client.
@dontsueme what do you think?

If that will not work, can try this patch:
dengert@1432c3b

It builds versions of the 3 modules with the name lib* with all the PKCS#11 symbols.

So this could also be used with simple PKCS#11 coe that does not use the C_GetFunctionList, but just uses the export routines directly.

[frankmorgner]

@dengert I am opting for exporting everything, see #340 . I don't see why or how this would do any harm (the only argument so far was "the standard says so")...

But I don't understand why we would need libopensc-pkcs11.la and opensc-pkcs11.la

[dengert]

@frankmorgner
Having two was a compermise.

The main idea was if there were issues with some OS with having all the entry points exported,
opensc-pkcs11.so would only export the C_GetFunctionList. And for programs like the vmware-client or other simple application that just wanted to call the PKCS#11 funtions directly, we would have libopensc-pkcs11.so

I am OK with exporting all the PKCS#11 entrypoints, or just the 3 that @martinpaljak suggested
and forget the extra modules.

In eiter case, we should also export the entry points in pks11-spy too.

[frankmorgner]

What would be the advantage if we kept a library with a single entry point? Having two libraries with the same functionality and only minor technical differences only creates confusion...

[dengert]

It needs at least 3 entrypoints for vmware-client. Yes confusion is an issue. I agree with @martinpaljak add the 3 entry points.

The only reason to have two versions of the module would be if some OS has some issue with loading modules and needs a real shared lib. That does not appear to be the case with vmware,
as best as I can tell.

Any example of problems with modules occured when I was building OpenSC for Solaris10 a few years ago. It turned out libtool was not building modules correctly on Solaris It needed:

$ cat libtool.diff.2.2.6
--- ,libtool Mon Jun 8 16:04:31 2009
+++ libtool Mon Jun 8 16:13:01 2009
@@ -314,7 +314,7 @@

Commands used to build a loadable module if different from building

a shared archive.

-module_cmds=""
+module_cmds="$archive_cmds ${wl}-B ${wl}direct ${wl}-z ${wl}defs"
module_expsym_cmds=""

Whether we are building with GNU ld or not.

[martinpaljak]

So to close a long thread, #537 should be sufficient?

[frankmorgner]

Yes!

@dengert the issue on Solaris 10 should be addressed separately when it occurs today (I don't know if maybe libtool has solved this already).

[pspacek]

Hi!

Unfortunatelly I'm late to the party, but there is another application which does not work if all symbols are not exported: ISC BIND 9.10.

BIND is simply calling dlsym for all symbols, see e.g.:
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=lib/isc/unix/pk11_api.c;h=9ccb959cb5edb5ebc5240d2d847c876776fd55f3;hb=HEAD#l146

I would say that at least spy.so should be benevolent and export everything, so spy can be easily used for debugging applications even if the opensc decides not to export everything.

[pspacek]

I should add that BIND works if I add all C_* functions to export file and rebuild opensc.

[frankmorgner]

lol, if you had told us earlier, the discussion could have been two years shorter!

[pspacek]

LOL. Anyway, is there any chance to get all symbols exported? BIND is typically used with high-end HSMs so I guess that other vendors simply export everything (as was mentioned somewhere in the thread), otherwise BIND could not work with other PKCS#11 libs.

[frankmorgner]

@pspacek If you still need it, please open a PR. But I think the better solution would be to submit a patch to BIND so that it behaves compliant to PKCS#11!

[pspacek]

@frankmorgner Given BIND's lifecycle it is going to take years to get the patch to versions used in wild, not speaking about uncertainity of that effort.

Can you point me to particular chapter in PKCS#11 standard which says that this is ilegal? That might help to convince upstream to make the change, but I'm not able to find such statement in the docs. It seems that whole C_GetFunctionList thingy is more for convenience than a hard requirement.

[frankmorgner]

Sorry, I preemptively adopted other's people opinions, though I should have known better. I already pointed out that the pkcs11 headers indeed define all functions as extern, see #183 (comment). So exporting them would be the right idea. If you want that fixed, please open a PR (I was already waiting more than half a year in #340 without any response...).

[dengert]

Yes it looks like #340 wold work for Vmware and BIND. If there are issues with adding the exports, we can still do the two versions of a libs somthing like: dengert@1432c3b

[dengert]

Looks like #340 will solve the VMware and BIND issues. If that cuases an issue with other software, we can still do two versions of the libs one with and one without all the symbols exported.

[pspacek]

@dengert , finally I found time to prepare PR, please see #590.