estreams symbols for python bindings
879cc1f84fbf
Actions

Description

estreams symbols for python bindings

* It turns out that even though some platforms detect differing
  symbols for estreams, the two types do not appear to be in
  conflict.  At least they don't from the BSD/OS X side of things.
  As a consequence both versions are now included.

Tested-by: Ben McGinnes <ben@adversary.org>

Signed-off-by: Ben McGinnes <ben@adversary.org>

Details

Provenance

BenM	Authored on Sep 2 2018, 11:07 AM

Parents

rMdacb1197155c: js: key deletion after test

Branches

Unknown

Tags

Unknown

Event Timeline

BenM committed rM879cc1f84fbf: estreams symbols for python bindings (authored by BenM).Sep 2 2018, 11:07 AM

• aheinecke added a subscriber: • aheinecke.Sep 6 2018, 12:21 PM

• aheinecke added inline comments.

/src/gpgme.def
276	Hi Ben, This broke the normal (autogen.sh --build-w32) Windows build: Cannot export _gpgme_data_new_from_estream: symbol not defined I do not understand what makes this necessary for you (and only for this one function), so I don't know how to fix it myself. Could you please check if you can find a way it works for you without the _gpgme_data_new_from_estream export? Thanks, Andre

• werner added a subscriber: • werner.Sep 6 2018, 12:33 PM

• werner added inline comments.

/src/gpgme.def
276	Actually the previous commit which added the _estream* function is questionable. In general the underscore prefix is used for internal functions and needed to keep the namespace clean. On modern ELF platform this is not really needed because we can control with the vers file which symbols to export. But there are platforms which don't support vers things and thus we stick to the underscore prefix for internal symbols. There is an exception of course: Sometimes we need access to internal functions which are not part of the API but of the ABI - for example macros like puc. And also some language bindings may need it. In the latter case this should be prominently explained in the def and vers file as well as in the code.

Right, which is exactly the issue I was trying to solve by adding both versions.

The problem is including the estream symbol without the preceding underscore (i.e. the original patch from Jasper Spaans) is that it resulted in the python module produced on OS X (and possibly other BSD based systems) believing that gpg.gpgme exists or should exist and subsequently trying to import it into gpg.core since it does not (and should not) exist, that fails and the entire module produces an import error. There are two ways this can work on OS X:

By including an equivalent symbol with the underscore preceding it.
By not including any of the changes regarding estreams from either Jasper or myself.

I'd favour the latter, except that apparently it that doesn't work on Ubuntu, which apparently *needs* the entry without the underscores, even though it will break OS X. While OS X either needs the underscore version to offset the no underscore version, is fine with the underscore version on its own and is also fine with none of them).

One other point. Rolling back to commit 138e1dde027338358a8da19ff8592b7369494534 and testing GPG4win and the Outlook plugin is definitely worth trying since every commit since then has been either part of the JS bindings, documentation updates and/or these estreams updates, nothing else. That commit is after the estreams addition which allegedly caused problems on Ubuntu in the first place, but didn't raise errors elsewhere. So I'd like to know if that's because I was the only one running that commit revision on live systems or if it's because Jasper is the only one to have encountered an error in the first place.

FreeBSD is fine with no estreams updates to the python bindings or just Jasper's update or just my previous update with the underscores, but not this attenmpt to cover both OS X and Ubuntu.

I suspect both NetBSD and OpenBSD will have similar results, but do not have either available to test with right now. It's possible there will be similar issues on System V OSes.