Ubuntu 32 bit (14.04) and Modelsim_DE

[pvandoren]

When making cocotb on Ubuntu 32 bit for ModelSim_DE 10.2c i get a PyFloat_type error as referenced in issue #124

The "Work around" mention of of adding
dlopen("libpython2.7.so", RTLD_LAZY | RTLD_GLOBAL);
to ./lib/embed/gpi_embed.c before Py_Initialize(); in embed_init_python works, but requires a include at the begining.
#include <dlfcn.h>

The original code works with icarus, but seems to be an issue with ModelSim in ubuntu 14.04 (32 bit)

[stuarthodgson]

pvandoran,

Could you try tip of branch Issue#146 and see if this resolves this issues?

Thanks

Stu

[pvandoren]

Hi Stu:

Unfortunatly the changes in branch Issue#146 did not resolve the issue.

I'm still getting
ImportError: /usr/lib/python2.7/lib-dynload/_ctypes.i386-linux-gnu.so: undefined symbol: PyFloat_Type

When running with SIM=modelsim on Ubuntu 14.04 32-bit.

Thanks

Pete

[stuarthodgson]

So turns out I fixed another issue to do with 32bit python on 64bit which is not what this bug is. After trying on a full 32 bit system I see a similar error with PyExec, Can you try commit 3048ba1 please.

[pvandoren]

Ok. I'm still seeing the same error with 32-bit Ubuntu 14.04.

Pete

[potentialventures]

Thanks for testing. Ill continue over the weekend.

Stu
On 29 Aug 2014 00:37, "pvandoren" [email protected] wrote:

Ok. I'm still seeing the same error with 32-bit Ubuntu 14.04.

Pete

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

[stuarthodgson]

Hi,

I've installed a clean 32bit ubuntu 14.04 and see the error on Master. On the tip of Issue#146 its resolved for me.

Did you update to the correct commit ?

Stu

[pvandoren]

Ok. I Think it was either stale do files or work directories.

I validated I was on the correct branch and checkout, then removed all "uncommitted" files then remade the project and everything started working.

Sorry for the confusion.

I also have Riviera-Pro that I can test against, if you need someone to test those configurations.

Thanks

Pete.

Please close this once you have merged those changes into the master branch.

pvandoren@ubuntu:/opt/cocotb$ git status
On branch Issue#146
nothing to commit, working directory clean
pvandoren@ubuntu:/opt/cocotb$ git log
commit 3048ba1
Author: Stuart Hodgson [email protected]
Date: Wed Aug 27 11:19:56 2014 +0100

Issue#146: Tell modelesim to do global resolution of symbols from libgpi.so

commit a19ece8
Author: Stuart Hodgson [email protected]
Date: Wed Aug 27 11:19:07 2014 +0100

Cleanup: Initialise gState to NULL

commit ee6e54c
Author: Stuart Hodgson [email protected]
Date: Tue Aug 26 17:50:43 2014 +0100

Issue#146: Only link against libpython not the dyn-libs too

commit 2170852
Author: chiggs [email protected]
Date: Thu Aug 14 14:39:38 2014 +0100

Issue #128: Correct warnings from other gcc versions

[pvandoren]

Just a note: I tried this with Riviera-Pro 2014-02 and am seeing a similar issue. I've opened a support case with Riviera to see if they have a similar -gblso switch (I couldn't find it in the documentation)

Once they get back to me I'll open up a new case on that and let you know what I find.

Thanks

Pete

[chiggs]

I'm also seeing this on Linux mint + Riviera-PRO

[chiggs]

I think the general problem is that we either have to link against everything as we did previously (which is awkward), or ensure that our library is loaded with RTLD_GLOBAL. Modelsim provides a command line switch to use the global flag, but we can't rely on all simulators providing this or assume anything about the internal workings of the simulator.

I think on reflection simply re-loading the library before initialising Python is safe and effective. The only change required is to pass the Python version as an environment variable (assuming the shared object follows a predictable naming convention between distributions).

[stuarthodgson]

Linking with "everything" does not work on 32 bit systems. There is a
difference in the linking that means only the first library is linked in
and nothing else. Run ldd on the 32bit libs and compare to the 64 bit ones.
Python handles loading the .so libs from lib-dynload.

As you correctly point out the problem is to do with symbol resolution on
library load and some sims seemingly using RTLD_LOCAL. Reluctantly I agree
that if the sims do not provide an overrride and to catch them all we need
to do a redundant call to dlopen to load python (the dynamic linker will
already have done this once though) in libgpi.so before calling into
libcocotb.so.

I'll make these changes and push shortly. All a hack though and not nice.

On 31 August 2014 18:10, chiggs [email protected] wrote:

I think the general problem is that we either have to link against
everything as we did previously (which is awkward), or ensure that our
library is loaded with RTLD_GLOBAL. Modelsim provides a command line
switch to use the global flag, but we can't rely on all simulators
providing this or assume anything about the internal workings of the
simulator.

I think on reflection simply re-loading the library before initialising
Python is safe and effective. The only change required is to pass the
Python version as an environment variable (assuming the shared object
follows a predictable naming convention between distributions).

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

[stuarthodgson]

Fixed in 17806b2