Wholly unnecessary flame. (was Re: pyXML!)

[jay.krell at cornell.edu]

Huh? I need to look into this. The other Win32 compilers/linkers really
generate/consume different import libraries? Visual C++ actually changed the
format from VC5 to VC6. The old format was like coincidental goop/magic that
drove the linker just like "traditional" libraries, sort of fooling it into
generating import tables; it was way oversized. The new format is basically
just a list of strings, as you might expect, though it still I think has too
much of the normal .obj/.lib format about it, and funky things you could do
with the old format you can no longer do -- I had a tool working that would
generate import libs such that you could link to malloc in msvcrt.dll as
msvcrt_malloc, or any arbitrary symbol, rather than simply malloc. This is
because the old format seperated the symbol the linker looks for in the
"normal" process from the strings the linker sticks in the binary. The new
format does not allow for this.

** All you need to generate an import .lib with Visual C++ is to run lib.exe
over a .def file. No compilation or linking needs to take place! ** If all
the other Win32 tool suites support like "lib -def:foo.def"... I should look
into this..ie: I wish I was more familiar with the other Win32 tool options,
but I tried CodeWarrior and did not like the IDE..

 ..Jay

-----Original Message-----
From: Martin von Loewis <loewis at informatik.hu-berlin.de>
Newsgroups: comp.lang.python
To: python-list at python.org <python-list at python.org>
Date: Sunday, October 01, 2000 2:58 AM
Subject: Re: Wholly unnecessary flame. (was Re: pyXML!)


>"Chui Tey" <teyc at bigfoot.com> writes:
>
>> is there any reason why gcc on unix could not cross compile for windows
and
>> mac? Building for x86 linux, Windows and Mac would cover 90% of all
users.
>
>For Windows, there is indeed no reason. I use gcc as a cross-compiler
>(host=Solaris, target=i386-pc-mingw) myself. The only drawback is that
>the resulting import library for python.dll won't be VC++
>compatible.
>
>Likewise, it can't link the VC++-generated pythonxy.lib that comes
>with your typical binary Windows distribution. So you can't use the
>cross gcc to build extension modules. If you have some C++ sources in
>your project (e.g. for use with ActiveX) you essentially have to give
>up: gcc's C++ implementation is not binary compatible with
>Microsoft's.
>
>As for the Mac: which version? I believe gcc does not support 68k
>Macs, and using it on PPC MacOS 8 or 9 is tricky. gcc is the default
>compiler on MacOS X, but Apple had made some modifications. They did
>publish those, but they are not part of gcc yet. Stan Shebs of Apple
>is working on integrating them into gcc 3.
>
>Regards,
>Martin
>--
>http://www.python.org/mailman/listinfo/python-list