Mailman 3 September 2007 - Distutils-SIG

Problem adding a new setup command..
by Etienne Robillard 27 Sep '07

27 Sep '07

Hi there, I'm a new setuptools user. I think setuptools is very good, and I'm currently using it for a personal project. [1] However, I'm experimenting a small issue when trying to use a new setup command like so: $ python setup.py install_media Distribution.parse_config_files(): reading setup.cfg options (after parsing config files): option dict for 'egg_info' command: {'tag_build': ('setup.cfg', 'p1'), 'tag_svn_revision': ('setup.cfg', '0')} options (after parsing command line): option dict for 'aliases' command: {} option dict for 'egg_info' command: {'tag_build': ('setup.cfg', 'p1'), 'tag_svn_revision': ('setup.cfg', '0')} option dict for 'install_media' command: {'args': ('command line', [])} running install_media Distribution.get_command_obj(): creating 'install_media' command object setting options for 'install_media' command: args = [] (from command line) Traceback (most recent call last): File "setup.py", line 143, in <module> zip_safe=(sys.version >= 2.5) File "/opt/python25/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/opt/python25/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/opt/python25/lib/python2.5/distutils/dist.py", line 992, in run_command cmd_obj = self.get_command_obj(command) File "/opt/python25/lib/python2.5/distutils/dist.py", line 879, in get_command_obj self._set_command_options(cmd_obj, options) File "/opt/python25/lib/python2.5/distutils/dist.py", line 919, in _set_command_options % (source, command_name, option)) distutils.errors.DistutilsOptionError: error in command line: command 'install_media' has no such option 'a rgs' Here's the setuptools.Command subclass: from setuptools import Command class install_media(Command): description = "Install app-specific media files" command_consumes_arguments = True # List of options for this command user_options = [ # Perhaps the better option is to use the '--prefix' arg. # ('with-docroot=', None, 'Install media files to this directory'), ('with-apps=', None, "Search theses subdirs for media files (comma-separated list)") ] def initialize_options(self): pass def finalize_options(self): pass def run(self): return self._find_media_files() def _find_media_files(self): pass Any insightful hints how to debug this problem? The Big Idea was to add a new setup command (named install_media) which could presumely allow things like: $ python setup.py install_media --prefix=/var/www --with-apps=foo,bar Thanks in advance, Etienne 1. http://tools.assembla.com/notmm/ ---- Etienne Robillard 7680 de jouvence, La Plaine J7M-2K9, Québec Telephone: 450-478-5026 Yahoo Messenger ID: granted14 Skype ID: incidah Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com

2 1

Re: [Distutils] What is the legal status of virtual-python.py
by Phillip J. Eby 27 Sep '07

27 Sep '07

At 08:33 PM 9/11/2007 +0300, Ignas Mikalajunas wrote: > Hello, I would like to reuse pieces of code from > http://peak.telecommunity.com/dist/virtual-python.py As far as my contributions to that code, you may consider them public domain. I suspect Ian would say the same.

1 0

setuptools fails to install package data from ZIP distribution
by Philipp von Weitershausen 27 Sep '07

27 Sep '07

Packages with Zope software typically contain lots of package data (templates, resources, translations, configuration files). Last night we had somebody with a Windows machine make distributions of some of our eggs (using python setup.py sdist) for the first time. It turns out, 'sdist' on Windows creates a ZIP file while on other platforms it creates a gzipped tarball. I find that difference in behaviour a bit disturbing. That behaviour isn't the actual root of the problem we experienced, however. These ZIP distributions were then uploaded to PyPI and other people happily started installing them. The only problem was that on Linux and MacOSX, the installed eggs no longer contained any of the package data. The distributions (the ZIP files) do contain it, but somehow setuptools fails to install it properly. Is this a known bug? Is there a reason for the different default behaviour of 'sdist' on the different platforms? -- http://worldcookery.com -- Professional Zope documentation and training

3 4

Re: [Distutils] Known working sets II [was: Eggification redux]
by Tres Seaver 25 Sep '07

25 Sep '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (CC'ing the Python distutils list, which is where setuptools development is discussed; maybe I should be including the catalog-sig too, but I don't read that list). Philipp von Weitershausen wrote: > (Also CCing zope3-dev where the first known working set discussion > started a while ago) > > Tres Seaver wrote: >> This is the "known good" problem. I'm pretty convinced that adding some >> kind of "PyPI subset", where gardeners for a given "package set" keep >> the list of packages / versions known to work well together, is the only >> way out of this issue. E.g., a URL like: >> >> http://pypi.python.org/pypi/release/zope3.4 >> >> would be usable as an 'index-url' for setuptools: when used this way, >> setuptools would only find / install eggs from the "gardened" set, >> rather than whatever anyone happened to have uploaded that day. >> >> If PyPI can't be tweaked to provide such a feature, we may need to come >> up with some kind of mirroring scheme which does allow it. > > This is certainly an interesting approach. I'd be curious how you would > garden this known working set. Martijn makes a pretty good case for > maintaining such working sets close to the package in question (e.g. the > grok egg, the Plone egg, etc.). I would argue that this problem is too big for "developer convenience" to drive it: we need concerted effort from the different "communities of interest" to manage the problem, in much the same way that Debian / Fedora etc. manage their various distribution releases. I see a PyPI subset implemented as follows: - Subset creator / owner defines the list of PyPI project names which are included in the subset. - For each project, the available releases known to PyPI fall into one of the following states: o 'unknown' is the default: newly-uploaded distributions start here. o 'known_good' is a terminal state: the creator / owner of the subset has blessed this version. o 'known_bad' is also a terminal state: this version won't *ever* be compatible with the others in the subset. - Other users should be able to report "works for me" / "broken" against a given distribution *for that subset.* Perhaps we can set up an RSS feed for each subset showning the "unknown" packages, so that people know they need testing. - Note that it would be possible (assuming setuptools requirements specs are sufficiently flexible) to generate a meta-egg from the "known_good" distribution list: such an egg's 'install_requires' would need to list the "known_good" values, rather than attempting to do range arithmetic. - The subset homepage would be usable as 'index_url' for setuptools, so that folks wanting to 'easy_install' a package (or drive buildout) could restrict the available packages to the "known good" versions. > I see two more solutions: > > * A versions.cfg that's loaded via HTTP. zc.buildout actually supports > this now which makes it quite appealing. Also, far as I know, all major > deployers of Zope3 that use zc.buildout for deployment use this form of > pinning egg versions right now, which means it's actually being used out > there. Locking down the file doesn't solve the problem of knowing that there are new candidate / "unknown" distributions which need testing, nor of colleting the "works for me" / "broken" information from users. A subset could certainly generate such a view, however, which would make zc.buildout integration work on a par with the 'easy_install --index-url" usecase. > * Adding version conflict resolution to zc.buildout and/or setuptools. > That way you could create meta eggs (e.g. the 'Zope' egg) with '==' > version specificers (for Grok, the 'grok' egg would function as the meta > egg as well). If this would cause version conflicts (and they often > occur in buildout due to the lack of a full dependency tree before > download), it should be possible to say which egg's versions are > authoritative. As with an apt / yum repository, a subset could harvest and export the full dependency graph information for all included distributions, assuming that setuptools was willing to use such information rather than incrementally discovering dependencies after download. I'm not sure there is much point in trying to compute such a "pickle" across the whole of PyPI, however. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+P/I+gerLs4ltQ4RAqnvAJ43njIxLFcs3CeBiPg59EsvIP+RhACg3HZT /+6YTbnB1V50SkLtYzuNeRc= =yVfp -----END PGP SIGNATURE-----

1 0

virtualenv patch
by Tres Seaver 21 Sep '07

21 Sep '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been working with virtualenv-0.8.4 on Linux, and found two bugs when using it to built environments outside the tree containing the source Python's 'lib' directory. My setup: - I have a custom-built Python, which I use for all Zope-related work, in '~/projects/Zope/bin/python'. - I also have a "virtual" Python, built from /usr/bin/python using the old 'virtual_python.py' script, in '~/bin/python'. - I was trying to use virtualenv.py to build out new environments under '~/tmp', using the "Zope" python as the "source" Python. The bugs: - This first one causes the 'exec_prefix' search to blow up if another lib directory *is* "above" the environment; the 'lib-dyload' from the "foreign" Python ends up on sys.path. - The next one is that distutils' attempts to parse 'config/Makefile' barfs. The attached patch fixes both, by adding 'lib-dynload' and 'config' to the set of things which are copied / linked into the target environment. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8vAP+gerLs4ltQ4RArabAJ9bJvdqIMIRShDKJL2B2931KE8pEQCgoXCa eGflzC6K2yGyV8yHHgIkB+k= =DlKN -----END PGP SIGNATURE-----

1 0

virtual-python.py, sys.prefix, and Mac
by Ian Bicking 19 Sep '07

19 Sep '07

Hi all. I'm kind of giving up on workingenv, and have started working from virtual-python as a basis instead (http://pypi.python.org/pypi/virtualenv/). So the basic technique here is to copy the executable into /ENV/bin/python, and then sys.prefix will be '/ENV'. The standard Python installed on a Mac doesn't seem to do this -- the prefix remains '/opt/local/Library/Frameworks/Python.framework/Versions/2.4' regardless. (Custom built Python's on Mac work like normal.) Does anyone know a way to get the normal effect on this Mac Python? -- Ian Bicking : ianb(a)colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers

5 15

Windows Python sys.prefix
by Ian Bicking 19 Sep '07

19 Sep '07

Related to the issue I noted with sys.prefix on a Mac, moving the Python executable on Windows also doesn't seem to effect sys.prefix. How does Python on Windows determine sys.prefix? Is there a way to effect that? -- Ian Bicking : ianb(a)colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers

3 5

wxPython setup.py linking error
by Karl Kobata 18 Sep '07

18 Sep '07

Please help. I am compiling wxPython in the cygwin environment on a laptop. I have posted a similar questions with wxPython user group, but since it is a compiler/linker related problem, the help is limited. I am apparently missing libraries from GTK2/ATK/etc. required to resolve the references. What libraries are they? How can I verify that I have them? What changes or options are required to resolve the errors? What changes will I need to make to distutils to compile and link properly. Please help. karl 1) the configure files used is as follows: ../configure \ --prefix=/opt/wx/2.8 \ --enable-optimise \ --enable-debug_flag \ --with-gtk=gtk+-2.0 \ --disable-stl \ --disable-shared \ --disable-sound \ --enable-rpath=/opt/wx/2.8/lib 2) once installed I have edited the config.py file with - UNICODE = 0 - WX_CONFIG = '/opt/wx/2.8/bin/wx-config' 3) set environment variable: setenv LD_LIBRARY_PATH /opt/wx/2.8/lib setenv PATH /opt/wx/2.8/bin:$PATH 4) execute python setup.py build_ext --inplace --debug 5) when the linking starts I get a slew of unresolved variables. See below. ---------------------------------- > python setup.py build_ext --inplace --debug Preparing CORE... Preparing GLCANVAS... Preparing STC... Preparing GIZMOS... running build_ext building '_core_' extension creating build-gtk2 creating build-gtk2/temp.cygwin-1.5.24-i686-2.5 creating build-gtk2/temp.cygwin-1.5.24-i686-2.5/src creating build-gtk2/temp.cygwin-1.5.24-i686-2.5/src/gtk gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -g -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTPUT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXGTK__ -DXTHREADS -DXUSE_MTSAFE_API -Iinclude -Isrc -I/opt/wx/2.8/lib/wx/include/gtk2-ansi-debug-static-2.8 -I/opt/wx/2.8/include/wx-2.8 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/python2.5 -c src/helpers.cpp -o build-gtk2/temp.cygwin-1.5.24-i686-2.5/src/helpers.o -g -O0 cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -g -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTPUT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXGTK__ -DXTHREADS -DXUSE_MTSAFE_API -Iinclude -Isrc -I/opt/wx/2.8/lib/wx/include/gtk2-ansi-debug-static-2.8 -I/opt/wx/2.8/include/wx-2.8 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/python2.5 -c src/gtk/_core_wrap.cpp -o build-gtk2/temp.cygwin-1.5.24-i686-2.5/src/gtk/_core_wrap.o -g -O0 cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ src/gtk/_core_wrap.cpp: In function `PyObject* _wrap_GetAccelFromString(PyObject*, PyObject*, PyObject*)': src/gtk/_core_wrap.cpp:32501: warning: `wxGetAccelFromString' is deprecated (declared at /opt/wx/2.8/include/wx-2.8/wx/utils.h:571) src/gtk/_core_wrap.cpp:32501: warning: `wxGetAccelFromString' is deprecated (declared at /opt/wx/2.8/include/wx-2.8/wx/utils.h:571) g++ -shared -Wl,--enable-auto-image-base -g build-gtk2/temp.cygwin-1.5.24-i686-2.5/src/helpers.o build-gtk2/temp.cygwin-1.5.24-i686-2.5/src/gtk/_core_wrap.o -L/usr/X11R6/lib -L/opt/wx/2.8/lib -L/usr/X11R6/lib -L/usr/X11R6/lib -L/usr/lib/python2.5/config -lgtk-x11-2.0 -lgthread-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lXft -lfreetype -lXrender -lXext -lfontconfig -lpangox-1.0 -lX11 -lpango-1.0 -lm -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lSM -lexpat -lwxtiffd-2.8 -lwxjpegd-2.8 -lwxpngd-2.8 -lz -lpthread -liconv -lpython2.5 -o wx/_core_.dll /opt/wx/2.8/lib/libwx_gtk2d_aui-2.8.a /opt/wx/2.8/lib/libwx_gtk2d_xrc-2.8.a /opt/wx/2.8/lib/libwx_gtk2d_qa-2.8.a /opt/wx/2.8/lib/libwx_gtk2d_html-2.8.a /opt/wx/2.8/lib/libwx_gtk2d_adv-2.8.a /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a /opt/wx/2.8/lib/libwx_based_xml-2.8.a /opt/wx/2.8/lib/libwx_based_net-2.8.a /opt/wx/2.8/lib/libwx_based-2.8.a /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_colour.o):colour.cpp:(.text+0 x7b): undefined reference to `_gdk_colormap_free_colors' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_colour.o):colour.cpp:(.text+0 xf1): undefined reference to `_gdk_colormap_alloc_color' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_colour.o):colour.cpp:(.text+0 x7c7): undefined reference to `_gdk_color_parse' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x9c): undefined reference to `_g_source_remove' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xb2): undefined reference to `_gtk_widget_get_type' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xbd): undefined reference to `_g_type_class_peek' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xd4): undefined reference to `_g_signal_lookup' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xf7): undefined reference to `_g_signal_add_emission_hook' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x1f1): undefined reference to `_gtk_main_iteration' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x1f6): undefined reference to `_gtk_events_pending' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x2e3): undefined reference to `_gtk_widget_get_type' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x2f8): undefined reference to `_g_type_class_peek' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x316): undefined reference to `_gdk_threads_enter' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x344): undefined reference to `_gtk_events_pending' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x354): undefined reference to `_gdk_threads_leave' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x3f8): undefined reference to `_gtk_widget_get_type' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x40d): undefined reference to `_g_type_class_peek' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xd4): undefined reference to `_g_signal_lookup' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xf7): undefined reference to `_g_signal_add_emission_hook' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x1f1): undefined reference to `_gtk_main_iteration' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x1f6): undefined reference to `_gtk_events_pending' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x2e3): undefined reference to `_gtk_widget_get_type' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x2f8): undefined reference to `_g_type_class_peek' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x316): undefined reference to `_gdk_threads_enter' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x344): undefined reference to `_gtk_events_pending' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x354): undefined reference to `_gdk_threads_leave' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x3f8): undefined reference to `_gtk_widget_get_type' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x40d): undefined reference to `_g_type_class_peek' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x4c9): undefined reference to `_g_signal_lookup' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x4ec): undefined reference to `_g_signal_add_emission_hook' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x507): undefined reference to `_g_signal_lookup' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x52a): undefined reference to `_g_signal_add_emission_hook' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x53e): undefined reference to `_g_source_remove' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x578): undefined reference to `_gdk_threads_enter' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x5b1): undefined reference to `_gdk_threads_leave' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x6cb): undefined reference to `_g_idle_add_full' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x7a9): undefined reference to `_gtk_window_new' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0x7b6): undefined reference to `_gtk_widget_realize' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xa99): undefined reference to `_g_source_remove' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xb59): undefined reference to `_g_source_remove' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xc19): undefined reference to `_g_source_remove' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xcbc): undefined reference to `_gdk_visual_get_best_with_both' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xcda): undefined reference to `_gdk_colormap_new' /opt/wx/2.8/lib/libwx_gtk2d_core-2.8.a(corelib_app.o):app.cpp:(.text+0xce2): undefined reference to `_gtk_widget_set_default_colorma ........... /opt/wx/2.8/lib/libwx_based-2.8.a(baselib_zstream.o):zstream.cpp:(.text+0x40 5): undefined reference to `_inflateEnd' /opt/wx/2.8/lib/libwx_based-2.8.a(baselib_zstream.o):zstream.cpp:(.text+0x4e 5): undefined reference to `_inflateEnd' /opt/wx/2.8/lib/libwx_based-2.8.a(baselib_zstream.o):zstream.cpp:(.text+0x6a b): undefined reference to `_inflate' /opt/wx/2.8/lib/libwx_based-2.8.a(baselib_zstream.o):zstream.cpp:(.text+0xa3 9): undefined reference to `_zlibVersion' /opt/wx/2.8/lib/libwx_based-2.8.a(baselib_zstream.o):zstream.cpp:(.text+0xa5 1): undefined reference to `_zlibVersion' /opt/wx/2.8/lib/libwx_based-2.8.a(baselib_zstream.o):zstream.cpp:(.text+0xbc 5): undefined reference to `_inflateInit2_' /opt/wx/2.8/lib/libwx_based-2.8.a(baselib_zstream.o):zstream.cpp:(.text+0x12 ea): undefined reference to `_deflateInit2_' /opt/wx/2.8/lib/libwx_based-2.8.a(baselib_zstream.o):zstream.cpp:(.text+0x17 33): undefined reference to `_deflateEnd' /opt/wx/2.8/lib/libwx_based-2.8.a(baselib_zstream.o):zstream.cpp:(.text+0x18 0a): undefined reference to `_deflate' /opt/wx/2.8/lib/libwx_based-2.8.a(baselib_zstream.o):zstream.cpp:(.text+0x1a 15): undefined reference to `_deflate' collect2: ld returned 1 exit status error: command 'g++' failed with exit status 1

1 0

Export make file from distutils
by Karl Kobata 18 Sep '07

18 Sep '07

Please help. I am having a linking error porting wxPython to the laptop cygwin environment. Is there a way to get a make file exported from the setup.py file included with wxPython? Will I then be able to execute the make file instead of setup.py for my particular case. Please help. Thanks karl

2 1

How to easy_install from source package with mingw32 on Windows?
by zooko 14 Sep '07

14 Sep '07

Folks: Thank you for the various Python packaging tools! I just published a new version of a Free Software package: http://cheeseshop.python.org/pypi/zfec And I tested it with "easy_install zfec" on Windows XP, and I was disappointed to see this error message: """ error: Setup script exited with error: Python was built with version 7.1 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. """ If I download the zfec source tarball and execute """ ./setup.py install """ Then I get the same error message, but if I execute """ ./setup.py build -c mingw32 install """ Then it successfully builds and installs. (This is on Python 2.4 -- I believe that in Python 2.5 that error message has been updated to mention that mingw is an option.) So my first question is: how can I configure the zfec source package so that someone who has mingw installed and who runs "easy_install zfec" successfully builds it? A deeper question is: wouldn't it be nice if "./setup.py install" automatically used the "build -c mingw32" feature when necessary? Would anyone be interested in extending distutils to do that? Regards, Zooko

2 3