Documentation for supported platforms and specific build instructions?

[FriendFX]

I guess I was a bit too optimistic after reading the Pre-requisites section in the documentation which simply mentions

• Python 2.6+
• Python-dev packages
• A Verilog simulator

Having found that cocotb uses Makefiles to run the examples, I thought I could get this to work under my existing Cygwin (64bit, under Win 7) environment, since I had used that in the past to run ModelSim simulations. I was also able to build the latest iverilog in this environment and have a Python 2.7 installation within Cygwin.

So I installed additional requisites (such as autoconf, gcc and a bunch of others), cloned the "endian_swapper" example and ran make. Unfortunately, I couldn't get past the following errors:

$ make make results.xml make[1]: Entering directory '/home/friendfx/cocotb/examples/endian_swapper/tests' cd ../cosim && make make[2]: Entering directory '/home/friendfx/cocotb/examples/endian_swapper/cosim' gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -I/usr/include/python2.7 -c io.c -o io_module.o gcc: error: unrecognized command line option ‘-fstack-protector-strong’ Makefile:9: recipe for target 'io_module.o' failed make[2]: *\ [io_module.o] Error 1 make[2]: Leaving directory '/home/friendfx/cocotb/examples/endian_swapper/cosim' Makefile:65: recipe for target 'hal' failed make[1]: [hal] Error 2 (ignored) iverilog -o sim_build/sim.vvp -D COCOTB_SIM=1 /home/friendfx/cocotb/examples/endian_swapper/tests/../hdl/endian_swapper.sv make -C /home/friendfx/cocotb/lib/embed make[2]: Entering directory '/home/friendfx/cocotb/lib/embed' gcc -Werror -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wall -Wno-unused-parameter -fno-common -g -DDEBUG -fpic -DPYTHON_SO_LIB=libpython2.7.so -shared -Xlinker -export-dynamic -L/usr/lib -o /home/friendfx/cocotb/build/libs/x86_64/libcocotb.so /home/friendfx/cocotb/build/obj/x86_64/gpi_embed.o -ldl -lpython2.7 -L/home/friendfx/cocotb/build/libs/x86_64 /usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/bin/ld: warning: --export-dynamic is not supported for PE+ targets, did you mean --export-all-symbols? /home/friendfx/cocotb/build/obj/x86_64/gpi_embed.o: In function embed_sim_init': /home/friendfx/cocotb/lib/embed/gpi_embed.c:126: undefined reference togpi_get_root_handle' /home/friendfx/cocotb/lib/embed/gpi_embed.c:126:(.text+0x12b): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `gpi_get_root_handle'

It was only then that I came across the discussion in Issue #144 which asks for "Windows Makefile support" and looks quite a bit more daunting to me than the "Pre-requisites" in the documentation had suggested.

Long story short, is there a document somewhere which platforms are supported or cocotb has been tested with? Additionally, could someone point me to the "method of compiling/linking against the 32-bit libraries on a 64-bit Linux platform" mentioned in Issue #144, and something equivalent for other environments?

From that discussion, my questions would include:

• Do I have to use a 32 bit platform?
• Do I need to use specific Python or simulator versions?
• What simulator-specific pre-requisites do I need?
• Which environment variables do I need to set/modify so the build system can find everything it needs?

[jmorarity]

I am also interested in some build documentation. I have been successfully running with Elgorwi's Windows fork for many months and was excited to jump back to the main branch after I saw Issue #144 had been reintegrated and closed.

However, I have so far not been able to get a Windows build to run successfully from the current head/tip.

It appears that (from inspection of source) since 'uname' is being used and the os match is looking for mingw that "msys" is the proper environment to run the make script from (slight difference from the elgorwi branch).

I further deduced (by trial and error and code inspection) that for my system I'd need to specify the make parameters as: make SIM=modelsim MODELSIM_PATH=/c/Mentor/modelsim_dlx_10.2c PYTHON_DIR=/c/Python27

Then, to make the Makefile compatible with my system I changed the extra libdirs line in makefiles/simulators/Makefile.modelsim to: EXTRA_LIBDIRS := -L$(MODELSIM_PATH)/win32pe This was only necessary because I don't use the free version of ModelSim ... an enhancement would be to make this automatically detect the version name or to specify it on the command line as well. I also changed the includes line in lib/fli/Makefile for good measure, since it was left hardcoded to some other version of modelsim: INCLUDES += -I$(MODELSIM_PATH)/include

After making these changes and running the aforementioned make command in an msys shell, I found that libraries were successfully built, but the simulations were erroring out due to an inability to find them.

Loading libvpi.dll

\ Error: (vsim-3193) Load of "libvpi.dll" failed: File not found.

#

\ Error: (vsim-PLI-3002) Failed to load PLI object file "libvpi.dll".

I manually descended into _examples\endian_swapper\tests\simbuild, added the just-built libraries to the windows path, and invoked ModelSim.

export PATH=$PATH:../../../../build/libs/i686
vsim -c -do runsim.do

Now, 'libvpi.dll' is found, but I encounter a seg fault:

Model Technology ModelSim DE vlog 10.2c Compiler 2013.07 Jul 18 2013

-- Compiling module endian_swapper_sv

#

Top level modules:

endian_swapper_sv

vsim -onfinish exit -pli libvpi.dll endian_swapper_sv

Attempting stack trace sig 11

Signal caught: signo [11]

PARTIAL STACK TRACE ONLY, anomaly 2

vsim_stacktrace.vstf written

Current time Mon Dec 29 09:40:10 2014

ModelSim Stack Trace

Program = vsim

Id = "10.2c"

Version = "2013.07"

Date = "Jul 18 2013"

Platform = win32pe

--> START OF USERCODE

0 0x6fc89111: 'ZNSsC1EPKcRKSaIcE + 0x39' in 'c:\python27\gnuplot\binary\libstdc++-6.dll'

1 0x0a041eb6: 'handle_vpi_callback + 0x145' in 'c:\repos\cocotb_tst\src\build\libs\i686\libvpi.dll'

<-- END OF USERCODE

2 0x0058d486: '<unknown (@0x58d486)>'

3 0x0058d619: '<unknown (@0x58d619)>'

4 0x0058d9a6: '<unknown (@0x58d9a6)>'

5 0x006afa2e: '<unknown (@0x6afa2e)>'

6 0x006b2553: '<unknown (@0x6b2553)>'

7 0x0098f801: '<unknown (@0x98f801)>'

8 0x1000cb1f: 'TclInvokeStringCommand + 0x8f' in 'c:\mentor\modelsim_dlx_10.2c\win32pe\tcl85.dll'

9 0x100473b5: 'Tcl_ExprObj + 0x1605' in 'c:\mentor\modelsim_dlx_10.2c\win32pe\tcl85.dll'

10 0x100462b5: 'Tcl_ExprObj + 0x505' in 'c:\mentor\modelsim_dlx_10.2c\win32pe\tcl85.dll'

11 0x1000f6a9: 'TclEvalObjEx + 0x2f9' in 'c:\mentor\modelsim_dlx_10.2c\win32pe\tcl85.dll'

End of Stack Trace

* Fatal: (SIGSEGV) Bad pointer access. Closing vsimk. * Fatal: vsimk is exiting with code 211. (Exit codes are defined in the ModelSim messages appendix of the ModelSim User's Manual.)

I'm assuming I'm still missing some prerequisite windows library paths. Can you please post them here or in a formal documentation update?

[stuarthodgson]

Hi,

We are close to making a release with windows support, issue#144 was the first step to this but as you note the documentation needs to be updated and a few other fixes as well. Windows is quite different to Linux so has been a learning curve for us.

We are planning to get the documentation resolved with what env vars need to be set too.

The segfault that you see is an issue relating to the refactoring of the gpi layer that only manifests it's self on the non free versions of Modelsim. This needs to be resolved before the release to.

Thanks for your patience.

Stu

[stuarthodgson]

@jmorarity

I'm hoping that you can help me out based on a couple of your comments above. One of the things that has been gating the release of 1.0 (with windows support) that lots of people want is to be sure that modlesim (paid for) works properly. This is proving somewhat frustrating as It does not appear to me that we have a point in time where we ever worked.

However your comment above makes me think that, on windows at least uisng elgorwi's fork that modelsim 10.2c works. So can you possibly answer the following questions.

1. What changeset of cocotb where you using for the last few months with the version of modelsim that worked.
2. Is it possible for you to try 10.3.c of modelsim (this is what I have a license on linux for).

Also rather than

"I manually descended into examples\endian_swapper\tests\sim_build, added the just-built libraries to the windows path, and invoked ModelSim."

Simply add the build folder to the windows path. You then do not need to copy libs around. You should also then be able to use the makefile rather than run vsim manually. I am trying to understand if your error is what I see. At the moment I am not sure.

Stu

[jmorarity]

I would love to help, but I can't yet run 10.3c as it requires an update of our license server which needs to be scheduled. I can probably get this done within the next week or two.

As for my current version of Cocotb, I didn't exactly do a stellar job of historical documentation, so I can't tell you exactly what I'm running at the moment but it is very close to this commit. Here are the notes I saved for getting it to build properly:

Build log:

Downloaded and installed pythonxy w/ 32-bit MinGW. Downloaded and installed 32-bit Cygwin.

Build in Cygwin, but w/ libraries linked to pythonxy and mingw dirs:

export MTI_HOME=/c/Mentor/modelsim_dlx_10.2c export MINGW_HOME=/c/pythonxy/MinGW32-xy export MODULE=test_endian_swapper export PYTHONPATH=/c/pythonxy/Python27/Lib:/c/pythonxy/Python27/DLLs:~/cocotb_win/build/libs/i686:~/cocotb_win:~/cocotb_win/cocotb:~/cocotb_win/examples/endian_swapper/tests export PATH=/c/cocotb_win/build/libs/i686:/c/cocotb_win/cocotb:/c/MinGW/mingw32/bin:/c/MinGW/bin:/bin:/>c/pythonxy/Python27

export SIM_ROOT=~/cocotb_win cd cocotb_win/examples/endian_swapper/tests make SIM=modelsim

If I get some time later this week, I can try updating to the head of elgorwi/cocotb and see if that works for me too (modelsim 10.2c) as it has one more merge from potentialventures/cocotb master so should be less of a divergence from what you're currently working with.

[jmorarity]

@stuarthodgson

I also acknowledge that this would work:

Simply add the build folder to the windows path. You then do not need to copy libs around. You should also then be able to use the makefile rather than run vsim manually.

But in a perfect world I wouldn't have to break causality rules and add a directory to my path that doesn't exist yet to get the make to run. :)

[stuarthodgson]

It would be nice if windows allowed per session search paths to. But hey ho.

I thought about modifying the users path to have the build location in it but thought people would object to this too. On 31 Dec 2014 17:22, "J.Morarity" notifications@github.com wrote:

@stuarthodgson https://github.com/stuarthodgson

I also acknowledge that this would work:

Simply add the build folder to the windows path. You then do not need to copy libs around. You should also then be able to use the makefile rather than run vsim manually.

But in a perfect world I wouldn't have to break causality rules and add a directory to my path that doesn't exist yet to get the make to run. :)

— Reply to this email directly or view it on GitHub https://github.com/potentialventures/cocotb/issues/164#issuecomment-68455719 .

[jmorarity]

A nice self-documenting solution to the build lib dependency problem might be to generate it inside the example simulation file itself. For instance, at the top of the autogenerated runsim.do file, you could also write a line set env(PATH) "$env(PATH);...\\build\\libs\\i686" which would be the tcl syntax to append the requisite libs dir to the windows path in the underlying cmd shell. It would not persist outside of the modelsim invocation, so I don't think you'd get any user complaints.

I went ahead and checked out the head of https://github.com/elgorwi/cocotb/branches/Win, rebuilt and simulated the endian test and a custom tb I've created. Everything worked, except I had to change the line CC = $(shell cygpath -u "$(MTI_HOME)/gcc-4.2.1-mingw32vc9/bin/gcc.exe") to CC = $(shell cygpath -u "$(MINGW_HOME)/bin/gcc.exe") because I do not have any such MinGW distribution in my ModelSim directory structure nor have I found that it is required.

I'm using gcc version 4.8.1 that comes with the "msys: MINGW32_NT-6.1" distribution.

[stuarthodgson]

@jmorarity

I've push a changeset that means the PATH does not need to be set explicitly. It's similar to your solution but not sim dependent, The fact that my system has a path with both spaces and () in it made this not work before and could not see wood for the trees.

I would very much appreciate it if you could test your working change set with 10.3.c when you get a chance while I try and get hold of a windows install of 10.2/10.3 to test against the current master as well.

Stu

[stuarthodgson]

@jmorarity

Regarding your segfault, we have just fixed one with modelsim on Branch Issue#188. Not sure if this is what you where seeing though. Could test? on whatever version you have?

[jmorarity]

No change for me on 10.2c or 10.3d. Still builds but seg faults.

vsim -c -do runsim.do 2>&1 | tee sim.log Reading C:/Mentor/modelsim_dlx_10.3d/tcl/vsim/pref.tcl

10.3d

do runsim.do

Model Technology ModelSim DE vlog 10.3d Compiler 2014.10 Oct 7 2014

Start time: 21:53:46 on Jan 15,2015

vlog -timescale 1ns/100ps -mfcu "+acc=rmb" -sv c:/repos/pycosim_trunk/cocotb_tst2/src/examples/endian_swapper/tests/../hdl/endian_swapper.sv

-- Compiling module endian_swapper_sv

#

Top level modules:

endian_swapper_sv

End time: 21:53:46 on Jan 15,2015, Elapsed time: 0:00:00

Errors: 0, Warnings: 0

Attempting stack trace sig 11

Signal caught: signo [11]

PARTIAL STACK TRACE ONLY, anomaly 2

vsim_stacktrace.vstf written

Current time Thu Jan 15 21:53:47 2015

ModelSim Stack Trace

Program = vsim

Id = "10.3d"

Version = "2014.10"

Date = "Oct 7 2014"

Platform = win32pe

--> START OF USERCODE

0 0x6fc89111: 'ZNSsC1EPKcRKSaIcE + 0x39' in 'c:\python27\gnuplot\binary\libstdc++-6.dll'

1 0x66681ee9: 'handle_vpi_callback + 0x178' in 'c:\repos\pycosim_trunk\cocotb_tst2\src\build\libs\i686\libvpi.dll'

<-- END OF USERCODE

2 0x00575e06: '<unknown (@0x575e06)>'

3 0x00575fdb: '<unknown (@0x575fdb)>'

4 0x0057637b: '<unknown (@0x57637b)>'

5 0x006b3045: '<unknown (@0x6b3045)>'

6 0x006b4b99: '<unknown (@0x6b4b99)>'

7 0x009bdfc2: '<unknown (@0x9bdfc2)>'

8 0x1000cb1f: 'TclInvokeStringCommand + 0x8f' in 'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

9 0x100473b5: 'Tcl_ExprObj + 0x1605' in 'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

10 0x100462b5: 'Tcl_ExprObj + 0x505' in 'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

11 0x1000f6a9: 'TclEvalObjEx + 0x2f9' in 'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

End of Stack Trace

vsim -c -do "runsim.do"

Start time: 21:53:46 on Jan 15,2015

Loading libvpi.dll

make[1]: Leaving directory `/c/repos/pycosim_trunk/cocotb_tst2/src/examples/endian_swapper/tests'

[stuarthodgson]

This is a bit strange

0 0x6fc89111: 'ZNSsC1EPKcRKSaIcE + 0x39' in

'c:\python27\gnuplot\binary\libstdc++-6.dll'

1 0x66681ee9: 'handle_vpi_callback + 0x178' in

'c:\repos\pycosim_trunk\cocotb_tst2\src\build\libs\i686\libvpi.dll'

It looks from this that your build is picking up the stdc++ lib from your python gnuplot installation rather than from mingw.

Can you modify the PATH to place /bin ahead of the python installation?

make clean make

Stu

On 16 January 2015 at 06:04, J.Morarity notifications@github.com wrote:

No change for me on 10.2c or 10.3d. Still builds but seg faults.

vsim -c -do runsim.do 2>&1 | tee sim.log Reading C:/Mentor/modelsim_dlx_10.3d/tcl/vsim/pref.tcl

10.3d

do runsim.do

Model Technology ModelSim DE vlog 10.3d Compiler 2014.10 Oct 7 2014

Start time: 21:53:46 on Jan 15,2015

vlog -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

c:/repos/pycosim_trunk/cocotb_tst2/src/examples/endian_swapper/tests/../hdl/ endian_swapper.sv

-- Compiling module endian_swapper_sv

#

Top level modules:

endian_swapper_sv

End time: 21:53:46 on Jan 15,2015, Elapsed time: 0:00:00

Errors: 0, Warnings: 0

Attempting stack trace sig 11

Signal caught: signo [11]

PARTIAL STACK TRACE ONLY, anomaly 2

vsim_stacktrace.vstf written

Current time Thu Jan 15 21:53:47 2015

ModelSim Stack Trace

Program = vsim

Id = "10.3d"

Version = "2014.10"

Date = "Oct 7 2014"

Platform = win32pe

--> START OF USERCODE

0 0x6fc89111: 'ZNSsC1EPKcRKSaIcE + 0x39' in

'c:\python27\gnuplot\binary\libstdc++-6.dll'

1 0x66681ee9: 'handle_vpi_callback + 0x178' in

'c:\repos\pycosim_trunk\cocotb_tst2\src\build\libs\i686\libvpi.dll'

<-- END OF USERCODE

2 0x00575e06: ''

3 0x00575fdb: ''

4 0x0057637b: ''

5 0x006b3045: ''

6 0x006b4b99: ''

7 0x009bdfc2: ''

8 0x1000cb1f: 'TclInvokeStringCommand + 0x8f' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

9 0x100473b5: 'Tcl_ExprObj + 0x1605' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

10 0x100462b5: 'Tcl_ExprObj + 0x505' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

11 0x1000f6a9: 'TclEvalObjEx + 0x2f9' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

End of Stack Trace

vsim -c -do "runsim.do"

Start time: 21:53:46 on Jan 15,2015

Loading libvpi.dll

make[1]: Leaving directory `/c/repos/pycosim_trunk/cocotb_tst2/src/examples/endian_swapper/tests'

— Reply to this email directly or view it on GitHub https://github.com/potentialventures/cocotb/issues/164#issuecomment-70212204 .

[jmorarity]

Ok, So that strange error was indeed the wrong "libstdc++-6.dll" being pulled (from Python extras rather than MinGW). It's a bit concerning how dependent it is on the runtime path order though. A search of my computer brings up 10 different locations for "libstdc++-6.dll" .. everything from MinGW and Python to Xilinx and Mathworks tools. Would it not be better to statically link it, so the proper version is at least bound to the Cocotb DLL after being built?

The good news of course is that I'm up and running with the latest version! I still had to make a couple of small edits to build and run my custom sims. I'm going to attempt to put together a pull request for those items ... but bear with me, I'm a GitHub virgin :)

On Fri Jan 16 2015 at 1:03:56 AM Stuart Hodgson notifications@github.com wrote:

This is a bit strange

0 0x6fc89111: 'ZNSsC1EPKcRKSaIcE + 0x39' in

'c:\python27\gnuplot\binary\libstdc++-6.dll'

1 0x66681ee9: 'handle_vpi_callback + 0x178' in

'c:\repos\pycosim_trunk\cocotb_tst2\src\build\libs\i686\libvpi.dll'

It looks from this that your build is picking up the stdc++ lib from your python gnuplot installation rather than from mingw.

Can you modify the PATH to place /bin ahead of the python installation?

make clean make

Stu

On 16 January 2015 at 06:04, J.Morarity notifications@github.com wrote:

No change for me on 10.2c or 10.3d. Still builds but seg faults.

vsim -c -do runsim.do 2>&1 | tee sim.log Reading C:/Mentor/modelsim_dlx_10.3d/tcl/vsim/pref.tcl

10.3d

do runsim.do

Model Technology ModelSim DE vlog 10.3d Compiler 2014.10 Oct 7 2014

Start time: 21:53:46 on Jan 15,2015

vlog -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

c:/repos/pycosim_trunk/cocotb_tst2/src/examples/endian_swapper/tests/../hdl/

endian_swapper.sv

-- Compiling module endian_swapper_sv

#

Top level modules:

endian_swapper_sv

End time: 21:53:46 on Jan 15,2015, Elapsed time: 0:00:00

Errors: 0, Warnings: 0

Attempting stack trace sig 11

Signal caught: signo [11]

PARTIAL STACK TRACE ONLY, anomaly 2

vsim_stacktrace.vstf written

Current time Thu Jan 15 21:53:47 2015

ModelSim Stack Trace

Program = vsim

Id = "10.3d"

Version = "2014.10"

Date = "Oct 7 2014"

Platform = win32pe

--> START OF USERCODE

0 0x6fc89111: 'ZNSsC1EPKcRKSaIcE + 0x39' in

'c:\python27\gnuplot\binary\libstdc++-6.dll'

1 0x66681ee9: 'handle_vpi_callback + 0x178' in

'c:\repos\pycosim_trunk\cocotb_tst2\src\build\libs\i686\libvpi.dll'

<-- END OF USERCODE

2 0x00575e06: ''

3 0x00575fdb: ''

4 0x0057637b: ''

5 0x006b3045: ''

6 0x006b4b99: ''

7 0x009bdfc2: ''

8 0x1000cb1f: 'TclInvokeStringCommand + 0x8f' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

9 0x100473b5: 'Tcl_ExprObj + 0x1605' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

10 0x100462b5: 'Tcl_ExprObj + 0x505' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

11 0x1000f6a9: 'TclEvalObjEx + 0x2f9' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

End of Stack Trace

vsim -c -do "runsim.do"

Start time: 21:53:46 on Jan 15,2015

Loading libvpi.dll

make[1]: Leaving directory `/c/repos/pycosim_trunk/cocotb_tst2/src/examples/endian_swapper/tests'

— Reply to this email directly or view it on GitHub < https://github.com/potentialventures/cocotb/issues/164#issuecomment-70212204>

.

— Reply to this email directly or view it on GitHub https://github.com/potentialventures/cocotb/issues/164#issuecomment-70225829 .

[potentialventures]

On 18 Jan 2015 07:04, "J.Morarity" notifications@github.com wrote:

Ok, So that strange error was indeed the wrong "libstdc++-6.dll" being pulled (from Python extras rather than MinGW). It's a bit concerning how dependent it is on the runtime path order though.

Well, not really. A valid question is wy does python bring in it's own libc.

A search of my computer

brings up 10 different locations for "libstdc++-6.dll" .. everything from MinGW and Python to Xilinx and Mathworks tools. Would it not be better to statically link it, so the proper version is at least bound to the Cocotb DLL after being built?

I'll need to look into how windows works in that regard. On Linux its just put the location of the lib in the rpath. Windows is different though.

The good news of course is that I'm up and running with the latest version!

This is great. Now means we can pull documentation together and do a release soon.

I still had to make a couple of small edits to build and run my

custom sims. I'm going to attempt to put together a pull request for those items ... but bear with me, I'm a GitHub virgin :)

Bear with us we are windows virgins.

Stu

On Fri Jan 16 2015 at 1:03:56 AM Stuart Hodgson notifications@github.com

wrote:

This is a bit strange

0 0x6fc89111: 'ZNSsC1EPKcRKSaIcE + 0x39' in

'c:\python27\gnuplot\binary\libstdc++-6.dll'

1 0x66681ee9: 'handle_vpi_callback + 0x178' in

'c:\repos\pycosim_trunk\cocotb_tst2\src\build\libs\i686\libvpi.dll'

It looks from this that your build is picking up the stdc++ lib from your python gnuplot installation rather than from mingw.

Can you modify the PATH to place /bin ahead of the python installation?

make clean make

Stu

On 16 January 2015 at 06:04, J.Morarity notifications@github.com wrote:

No change for me on 10.2c or 10.3d. Still builds but seg faults.

vsim -c -do runsim.do 2>&1 | tee sim.log Reading C:/Mentor/modelsim_dlx_10.3d/tcl/vsim/pref.tcl

10.3d

do runsim.do

Model Technology ModelSim DE vlog 10.3d Compiler 2014.10 Oct 7 2014

Start time: 21:53:46 on Jan 15,2015

vlog -timescale 1ns/100ps -mfcu "+acc=rmb" -sv

c:/repos/pycosim_trunk/cocotb_tst2/src/examples/endian_swapper/tests/../hdl/

endian_swapper.sv

-- Compiling module endian_swapper_sv

#

Top level modules:

endian_swapper_sv

End time: 21:53:46 on Jan 15,2015, Elapsed time: 0:00:00

Errors: 0, Warnings: 0

Attempting stack trace sig 11

Signal caught: signo [11]

PARTIAL STACK TRACE ONLY, anomaly 2

vsim_stacktrace.vstf written

Current time Thu Jan 15 21:53:47 2015

ModelSim Stack Trace

Program = vsim

Id = "10.3d"

Version = "2014.10"

Date = "Oct 7 2014"

Platform = win32pe

--> START OF USERCODE

0 0x6fc89111: 'ZNSsC1EPKcRKSaIcE + 0x39' in

'c:\python27\gnuplot\binary\libstdc++-6.dll'

1 0x66681ee9: 'handle_vpi_callback + 0x178' in

'c:\repos\pycosim_trunk\cocotb_tst2\src\build\libs\i686\libvpi.dll'

<-- END OF USERCODE

2 0x00575e06: ''

3 0x00575fdb: ''

4 0x0057637b: ''

5 0x006b3045: ''

6 0x006b4b99: ''

7 0x009bdfc2: ''

8 0x1000cb1f: 'TclInvokeStringCommand + 0x8f' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

9 0x100473b5: 'Tcl_ExprObj + 0x1605' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

10 0x100462b5: 'Tcl_ExprObj + 0x505' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

11 0x1000f6a9: 'TclEvalObjEx + 0x2f9' in

'c:\mentor\modelsim_dlx_10.3d\win32pe\tcl85.dll'

End of Stack Trace

vsim -c -do "runsim.do"

Start time: 21:53:46 on Jan 15,2015

Loading libvpi.dll

make[1]: Leaving directory

`/c/repos/pycosim_trunk/cocotb_tst2/src/examples/endian_swapper/tests'

— Reply to this email directly or view it on GitHub <

https://github.com/potentialventures/cocotb/issues/164#issuecomment-70212204>

.

— Reply to this email directly or view it on GitHub < https://github.com/potentialventures/cocotb/issues/164#issuecomment-70225829>

.

— Reply to this email directly or view it on GitHub.