----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3494/#review8404 -----------------------------------------------------------
Ship it! src/sim/init.cc (line 167) <http://reviews.gem5.org/r/3494/#comment7278> FYI: this is exactly what happens in cpython/Python/importdl.c. src/sim/init.cc (line 176) <http://reviews.gem5.org/r/3494/#comment7277> make_unique<char[]> ? Looks reasonable to me. There's even a whole comment in modsupport.c about this: /* Make sure name is fully qualified. This is a bit of a hack: when the shared library is loaded, the module name is "package.module", but the module calls Py_InitModule*() with just "module" for the name. The shared library loader squirrels away the true name of the module in _Py_PackageContext, and Py_InitModule*() will substitute this (if the name actually matches). */ Also, there's a discussion with Guido here. https://mail.python.org/pipermail/python-dev/2002-August/028075.html - Nathan Binkert On June 3, 2016, 6:31 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3494/ > ----------------------------------------------------------- > > (Updated June 3, 2016, 6:31 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11519:3a81d85e6eff > --------------------------- > scons: Track swig packages when loading embedded swig code > > This patch changes how the embedded swig code is loaded to ensure that > gem5 works with swig 3.0.9. For Python 2.7 and above, swig 3.0.9 now > relies on importlib, and actually looks in the appropriate packages, > even for the wrapped C code. However, the swig wrapper does not > explicitly place the module in the right package (it just calls > Py_InitModule), and we have to take explicit action to ensure that the > swig code can be loaded. This patch adds the information to the > generated wrappers and the appropriate calls to set the context as > part of the swig initialisation. > > Previous versions of swig used to fall back on looking in the global > namespace for the wrappers (and still do for Python 2.6), but > technically things should not work without the functionality in this > patch. > > > Diffs > ----- > > src/SConscript 7e0f869f8f7e > src/sim/init.hh 7e0f869f8f7e > src/sim/init.cc 7e0f869f8f7e > > Diff: http://reviews.gem5.org/r/3494/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
