i'm trying to get borland's free commandline compiler
working with a sample module i'm testing with.
everything goes fine in the compile, but the linker is
giving me the following error:
Error: 'D:\PYTHON\LIBS\PYTHON20.LIB' contains invalid
OMF record, type 0x21 (possibly COFF)
ok, sounds like the python20.lib is incompatible with
borland's compiler (??). if so, that seems like a big
pain. does anyone have the steps needed to get this
compiler working? i've not found any help from the
docs or source yet. i'm guessing i'll need to recompile
python with borland? (i didn't think that was an option?)
perhaps i'm better off going with cygnus or mingw? what
is the most common free win32 compiler for use with distutils?
In ccompiler, you have this code in gen_lib_options:
for lib in libraries:
(lib_dir, lib_name) = os.path.split (lib)
if lib_dir:
lib_file = compiler.find_library_file ([lib_dir], lib_name)
if lib_file:
lib_opts.append (lib_file)
else:
compiler.warn ("no library file corresponding to "
"'%s' found (skipping)" % lib)
else:
lib_opts.append (compiler.library_option (lib))
Note that you aren't passing "debug" to compiler.find_library_file, so the
debug libraries will never get used. Also note that msvccompiler doesn't
provide for passing the debug flag to library_option, so it doesn't do the
proper name mangling (adding _d) for the library name. I'm guessing you'll
need to make gen_lib_options get passed the debug flag, and then make it
pass that flag on to the compiler methods. No clue what to do for non-vc++
compilers (or even if they need debug flags).
Enjoy,
Mike
> Update of /cvsroot/python/distutils/distutils/command
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv31686
>
> Modified Files:
> build_ext.py
> Log Message:
> Removed the implib_dir instance variable because it is unused.
>
> Removed get_ext_libname() because it is unused.
>
> Fixed get_libraries() to append an '_d' to the python debug
> import library. If MSVC is used, do not add 'pythonxx.lib' to
> the list of libraries, because this is handled better
> by a pragma in config.h.
>
> This should fix bug #115595, but it needs some more testing.
>
>
> Index: build_ext.py
> ===================================================================
> RCS file: /cvsroot/python/distutils/distutils/command/build_ext.py,v
> retrieving revision 1.66
> retrieving revision 1.67
> diff -C2 -r1.66 -r1.67
> *** build_ext.py 2000/09/25 01:41:15 1.66
> --- build_ext.py 2000/09/28 19:28:35 1.67
> ***************
> *** 159,163 ****
> if os.name == 'nt':
> self.library_dirs.append (os.path.join(sys.exec_prefix,
'libs'))
> - self.implib_dir = self.build_temp
> if self.debug:
> self.build_temp = os.path.join (self.build_temp,
"Debug")
> --- 159,162 ----
> ***************
> *** 544,556 ****
> return apply (os.path.join, ext_path) + so_ext
>
> - def get_ext_libname (self, ext_name):
> - # create a filename for the (unneeded) lib-file.
> - # extensions in debug_mode are named 'module_d.pyd' under
windows
> - ext_path = string.split (ext_name, '.')
> - if os.name == 'nt' and self.debug:
> - return apply (os.path.join, ext_path) + '_d.lib'
> - return apply (os.path.join, ext_path) + '.lib'
> -
> -
> def get_export_symbols (self, ext):
> """Return the list of symbols that a shared extension has to
> --- 543,546 ----
> ***************
> *** 574,580 ****
> # config.h that MSVC groks. The other Windows compilers all
seem
> # to need it mentioned explicitly, though, so that's what we do.
> ! if sys.platform == "win32":
> ! pythonlib = ("python%d%d" %
> ! (sys.hexversion >> 24, (sys.hexversion >> 16) & 0xff))
> # don't extend ext.libraries, it may be shared with other
> # extensions, it is a reference to the original list
> --- 564,576 ----
> # config.h that MSVC groks. The other Windows compilers all
seem
> # to need it mentioned explicitly, though, so that's what we do.
> ! # Append '_d' to the python import library on debug builds.
> ! from distutils.msvccompiler import MSVCCompiler
> ! if sys.platform == "win32" and \
> ! not isinstance(self.compiler, MSVCCompiler):
> ! template = "python%d%d"
> ! if self.debug:
> ! template = template + '_d'
> ! pythonlib = (template %
> ! (sys.hexversion >> 24, (sys.hexversion >> 16) &
0xff))
> # don't extend ext.libraries, it may be shared with other
> # extensions, it is a reference to the original list
>
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins(a)python.org
> http://www.python.org/mailman/listinfo/python-checkins
> Details: I have successfully compiled and installed Python 2.0b2 on
> my Mac OS X system, but I am having trouble building the current
> Python/XML CVS version. During the linking stage, I get a warning
> and an error:
I assume that your Python build does not include the pyexpat module,
right? If it did, PyXML should not attempt to build it itself.
Since building is controlled by distutils, I've cc'ed this to the
distutils-sig. Since likely fixes will also need to appear in Python
2.0, it would be good if we resolve this within the next week.
> cc -bundle -prebind build/temp.darwin-1.2-Power Macintosh-2.0/extensions/pyexpat.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmltok/xmltok.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmltok/xmlrole.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/xmlfile.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/xmlwf.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/codepage.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlparse/xmlparse.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlparse/hashtable.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/unixfilemap.o -o build/lib.darwin-1.2-Power Macintosh-2.0/_xmlplus/parsers/pyexpat.so
I guess I need some help in resolving this, as I have no MacOS X myself.
Can you spot anything that is incorrect in this command line?
> /usr/bin/ld: warning -prebind has no effect with -bundle
What is the intended effect of -prebind and -bundle? Where do these
options come from, anyway? Grepping the distutils sources, I see no
mentioning of them, so what magic finds those options?
> /usr/bin/ld: Undefined symbols:
> _PyArg_ParseTuple
> _PyArg_ParseTupleAndKeywords
> ...*removed a few dozen more symbols*...
It's certainly the case that these symbols are undefined - we are
building an extension module, after all. On MacOS X, the compiler is
gcc, right? Normally, you'll have to pass -shared to the compiler
to have it build shared libraries.
I notice that Python's configure.in has two alternatives for building
extension modules on next/*: If dyld is used, then the options are
"-bundle -prebind", otherwise they are "-nostdlib -r". Do you use
WITH_DYLD? Can you try linking the module with "-nostdlib -r"?
Thanks,
Martin
> For detailed info, follow this link:
> http://sourceforge.net/bugs/?func=detailbug&bug_id=115544&group_id=6473
Hi all --
I have just completed one pass over the Distutils source to enforce one
minor coding convention: whitespace next to the open parentheses when
calling a function (or other callable). Anyone hacking on the Distutils
needs to know about this convention, which is slightly odd but quite
defensible (IMHO):
* when *defining* a callable, use a space:
def foo ():
...
def foo (arg1, arg2, ...):
...
class SubThing (Thing):
...
* corollary: for long functions that need a "# end"-style line,
it looks like this:
def foo ():
# > 40 lines of code (say)
# foo ()
because the "# foo ()" line is part of the definition
* when *using* a callable, no space:
foo()
thing.foo()
foo(2, "hello")
this.that.get_something().foo.name_of_long_method(
arg1, arg2, arg3, ...)
Rationale: this makes it trivial (grep-wise) to distinguish between
*definition* and *use*. I *know* what Guido's coding standard says, but
the problem with "def foo()" is that you can't search for use only
without a negative lookbehind to exclude "def" lines... and my "grep"
doesn't have negative lookbehind.
Anyways, that's the Distutils convention as of tonight. Please respect
it when hacking on the code! (And please fix deviance if you submit
patches: I've only fixed up distutils/*.py, excluding *ccompiler.py
because of a pending patch. distutils/command/*.py is still to go; I
can only do so much brain-dead search 'n replace work at once.)
Greg
--
Greg Ward gward(a)python.net
http://starship.python.net/~gward/
Python Distribution Utilities
release 0.9.3
September 26, 2000
The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules and (ultimately) applications.
The Distutils are a standard part of Python 2.0; if you are running 2.0
(or one of the 1.6 alpha releases that preceded it), you don't need to
install the Distutils separately. This release is primarily so that you
can add the Distutils to a Python 1.5.2 installation -- you will then be
able to install modules that require the Distutils, or use the Distutils
to distribute your own modules.
Version 0.9.3 is identical to the Distutils code included with Python
2.0b2.
More information is available at the Distutils web page:
http://www.python.org/sigs/distutils-sig/
and in the README.txt included in the Distutils source distribution.
You can download the Distutils from
http://www.python.org/sigs/distutils-sig/download.html
Trivial patches can be sent to me (Greg Ward) at gward(a)python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig(a)python.org.
Greg
--
Greg Ward gward(a)python.net
http://starship.python.net/~gward/
Hi all --
I've just checked in Rene's rather hefty patch to collapse a bunch of
mostly-redundant 'link_*()' methods in the various CCompiler classes
into one 'link()'. This is big enough to warrant a whole new code
snapshot, so I put one out: two-and-a-half releases in one day, a
personal record! ;-)
It works for me building a few things on my Linux box; please try it out
on other platforms (especially with a variety of compilers on Windows)
and let me know how it goes. Thanks.
Oh yeah:
http://www.python.org/sigs/distutils-sig/download.html#snapshot
Greg
--
Greg Ward gward(a)python.net
http://starship.python.net/~gward/
In my package, I have two places which carry version information: in
the setup.py, when passing the version= keyword argument to setup, and
in the package's __init__, to allow runtime access to the available
version.
I'd like these to be synchronized, having the information only in a
single place, and fetching it from there in the other. Is there any
mechanism in distutils to facilitate such synchronization?
One approach would be a autoconf-style replacement mechanism, where I
put
version_info = distutils.version.StrictVersion(@VERSION@)
into the Python source, and
version = version_string,
substitute = {'VERSION': repr(version_string)}
into setup.py. 'build', 'sdist', etc would update the string
appropriately.
Any comments?
TIA,
Martin
Hi all --
I think I've fixed all the problems Marc-André pointed out with config
files last week, specifically:
* options in config files can now be spelled either "foo-bar" (like on
the command line, minus the leading "--") or "foo_bar" (like in
the code)
* negative alias options are now respected, eg. "quiet=1" is the same
as "verbose=0"
Plus I fixed a bug nobody had reported:
* boolean options now work: previously, "force=0" resulted in an
attribute 'force' being set to the string "0", which of course
is true. As an extra bonus, you can now use a variety of sensible
representations of true and false: yes, y, t, true, 1, on for true,
and no, n, f, false, 0, off for false.
And added a feature that was supposed to be in there from the beginning,
but I just plain forgot about:
* a "[global]" section where you can set global options; currently,
only 'verbose' and 'dry-run' are supported here (and of course
'quiet', since it's the opposite of 'verbose')
As soon as I've checked everything in, I'll put out a new code
snapshot. Please give it a try and let me know if config files now work
as you'd expect them to work.
Greg
--
Greg Ward gward(a)python.net
http://starship.python.net/~gward/
Python Distribution Utilities
release 0.9.3
September 26, 2000
The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules and (ultimately) applications.
The Distutils are a standard part of Python 2.0; if you are running 2.0
(or one of the 1.6 alpha releases that preceded it), you don't need to
install the Distutils separately. This release is primarily so that you
can add the Distutils to a Python 1.5.2 installation -- you will then be
able to install modules that require the Distutils, or use the Distutils
to distribute your own modules.
Version 0.9.3 is identical to the Distutils code included with Python
2.0b2.
More information is available at the Distutils web page:
http://www.python.org/sigs/distutils-sig/
and in the README.txt included in the Distutils source distribution.
You can download the Distutils from
http://www.python.org/sigs/distutils-sig/download.html
Trivial patches can be sent to me (Greg Ward) at gward(a)python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig(a)python.org.
Greg
--
Greg Ward gward(a)python.net
http://starship.python.net/~gward/
