On Sun Jun 28 4:25 , ThomasK sent:
>>> This brings me to a next hotspot. ;-) I have seen, that there was a >>> discussion about python extension. In the moment it's commented out in >>> makefiles and, if python modul will be built, then it's not usable: an >>> import error raises, because of an missing symbol! (I havn't really >>> analysed, why, because it looks so, that nobody use this in the moment) >> >> I think that there is a missing -liberty on a link line somewhere. > >Hm ... no. libiberty will be linked. But, I took a short look on >Makefile in src directory (as I see, Makefile.am in src/python will not >be used at all, right?), _pysimulavr.so will not get all object files to >link together. So it's no wonder, if there are missed symbols. On my >tests I linked against src/.libs/libsim.a and also libbfd, libiberty and >libstdc++. The LIBIBERTY variable never gets set. Take a look at a portion of my new improved Makefile: > # Python bindings > #------ > _pysimulavr.so: pysimulavr_wrap.cpp simulavr $(libsim_la_OBJECTS) $(libsim_la_DEPENDENCIES) > $(CXXLINK) -I$(srcdir) $(PYTHON_CPPFLAGS) -fPIC -shared $< \ > $(libsim_la_OBJECTS) $(libsim_la_LIBADD) $(LIBS) \ > -lbfd $(LIBIBERTY) -lc -lm -lncurses \ > -o $@ $(NonPortableDarwin_GXX_Flags) > true $(LIBIBERTY) Its output: > true The result is the same whether I make it from the src directory or make from the top. In the future, I'll do all my makes with --warn-undefined-variables. >> The minimal goal would be to be able to use the simulator as a python module. >> Informative examples would also be good things. >> One might rewrite the standalone executable in python. >> >> I'm working on it, but my C++/python expertise isn't yet. >> The swig site looks like it might be more helpful than my Programming Python >> book. > >Means, that you want to get the simulation core as python module to use >it, for example, to control steps/simulatur run and to show current RAM >content in a GUI (or what else)? Right? This should be possible with not I'm not so much interested in GUIs as the ability to write unit tests, preferably on multi-processor systems. That said, I've no objection to others using my work to write GUIs. >so much effort. On the opposite, Onno's problem to connect verilog >simulation with simulavr isn't so easy because of time synchronisation >problem. He needs a grandmother clock. He could call it Mrs. Ogg. >I'll try some ideas in my testbench, make the code a little bit more >clean and documented and then I can send it to you for trying (by mail >to your mail address or wherelse?) The address below is fine. Code that involves verilog wouldn't be much use to me though. -- Michael Hennebry [email protected] "War is only a hobby." ---- Msg sent via CableONE.net MyMail - http://www.cableone.net _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
