Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix python and ruby binding build failures #3

Open
richmattes opened this issue Jun 11, 2015 · 4 comments

Comments

@richmattes
Copy link
Member

commented Jun 11, 2015

Copied from bugs 368 and 373 in SF.

368:

I am not sure if it's a problem with python filter that generates swig input file and the header; or the problem is in the new swig.

The generated C file calls "member functions" as _playerc_client_t_read when in the header file only the standard playerc_client_read is defined.

My stupid idea is to do a patch which add #define _playerc_client_t_read playerc_client_read.

The proper fix would be to write/instruct swig to use the correct "global" functions.

/build/buildd/player-3.0.2+dfsg/obj-x86_64-linux-gnu/client_libs/libplayerc/bindings/python/playercPYTHON_wrap.c: In function '_wrap_playerc_client_destroy':
/build/buildd/player-3.0.2+dfsg/obj-x86_64-linux-gnu/client_libs/libplayerc/bindings/python/playercPYTHON_wrap.c:50457:3: warning: implicit declaration of function '_playerc_client_t_destroy' [-Wimplicit-function-declaration]
/build/buildd/player-3.0.2+dfsg/obj-x86_64-linux-gnu/client_libs/libplayerc/bindings/python/playercPYTHON_wrap.c: In function '_wrap_playerc_client_set_transport':
/build/buildd/player-3.0.2+dfsg/obj-x86_64-linux-gnu/client_libs/libplayerc/bindings/python/playercPYTHON_wrap.c:50487:3: warning: implicit declaration of function '_playerc_client_t_set_transport' [-Wimplicit-function-declaration]
/build/buildd/player-3.0.2+dfsg/obj-x86_64-linux-gnu/client_libs/libplayerc/bindings/python/playercPYTHON_wrap.c: In function '_wrap_playerc_client_connect':
/build/buildd/player-3.0.2+dfsg/obj-x86_64-linux-gnu/client_libs/libplayerc/bindings/python/playercPYTHON_wrap.c:50509:3: warning: implicit declaration of function '_playerc_client_t_connect' [-Wimplicit-function-declaration]

the rest of the build log is at:
https://launchpadlibrarian.net/108812838/buildlog_ubuntu-quantal-amd64.player_3.0.2%2Bdfsg-4ubuntu1_FAILEDTOBUILD.txt.gz

373:

(Copied from rtv/Stage#42)

Full build log:
https://launchpad.net/ubuntu/+source/player/3.0.2+dfsg-4.1ubuntu1/+build/5180617

Get:349 http://ftpmaster.internal/ubuntu/ trusty/main swig2.0 amd64 2.0.10-0ubuntu2 [1153 kB]
Get:350 http://ftpmaster.internal/ubuntu/ trusty/main swig amd64 2.0.10-0ubuntu2 [6670 B]

Function `new__playerc_client_t' implicitly converted to pointer at /build/buildd/player-3.0.2+dfsg/obj-x86_64-linux-gnu/client_libs/libplayerc/bindings/python/playercPYTHON_wrap.c:50489

Function `new__playerc_client_t' implicitly converted to pointer at /build/buildd/player-3.0.2+dfsg/obj-x86_64-linux-gnu/client_libs/libplayerc/bindings/ruby/playercRUBY_wrap.c:49044

Indeed generated bindings refer to that non-existing function.

@richmattes richmattes added the bug label Jun 11, 2015
@richmattes richmattes self-assigned this Jun 11, 2015
@richmattes richmattes added this to the Release 3.1 milestone Jun 11, 2015
@rashadkm

This comment has been minimized.

Copy link

commented Jun 11, 2015

How about using a pre-generated wrapping sources for python and ruby? . With each release they can be updated and swig will no longer be a dependency for player. Good thing is, I dont want to worry about swig version changes anymore. generating wrapping sources can be done for every release. and if I want to generate it own my own, If I have proper swig which is documented on the readme or something

@gerkey

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2016

We had an OS X / brew user run across what appears to be the same problem: osrf/homebrew-simulation#76. The workaround there is to not have swig installed, which is fine, but not great.

@gerkey gerkey referenced this issue Jan 28, 2016
@richmattes

This comment has been minimized.

Copy link
Member Author

commented May 10, 2016

There have been a couple of changes to the swig generation since 3.0.2 was released. Is anyone able to re-create these issues with the latest git head?

I'm getting symbol errors when trying to import playerc from player 3.0.2:

$ python
Python 2.7.11 (default, Feb  5 2016, 01:53:41) 
[GCC 6.0.0 20160201 (Red Hat 6.0.0-0.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from playerc import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "playerc.py", line 28, in <module>
    _playerc = swig_import_helper()
  File "playerc.py", line 24, in swig_import_helper
    _mod = imp.load_module('_playerc', fp, pathname, description)
ImportError: ./_playerc.so: undefined symbol: _playerc_device_t_get_boolprop

But I'm not seeing any errors when using the latest git master branch:

$ python
Python 2.7.11 (default, Feb  5 2016, 01:53:41) 
[GCC 6.0.0 20160201 (Red Hat 6.0.0-0.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from playerc import *
>>> c = playerc_client(None, "localhost", 6665)
>>> c.connect()
playerc warning   : warning : [Player v.3.1.0-svn] connected on [localhost:6665] with sock 3

0
>>> 
@mfe7

This comment has been minimized.

Copy link

commented Jun 6, 2018

I can confirm that with 3.0.2 the symbol error occurs, but this repo's version works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.