Wholly unnecessary flame. (was Re: pyXML!)

[jay.krell at cornell.edu]

Oh, there is also the question of "ABI", how the compiler layouts out
structs and stack frames and such, but generally compilers follow
Microsoft's (or whatever the "native" vendor is) lead in order to be able to
consume windows.h (or whatever platform specific headers/shared libraries,
w/o resorting to something hacky like modifying the headers or providing
thunking libraries). And there aren't many ABI choices in C that don't have
obvious answers. ABI is more of a problem with C++..

 - Jay

-----Original Message-----
From: jay.krell at cornell.edu <jay.krell at cornell.edu>
To: Martin von Loewis <loewis at informatik.hu-berlin.de>;
python-list at python.org <python-list at python.org>
Date: Sunday, October 01, 2000 4:41 AM
Subject: Re: Wholly unnecessary flame. (was Re: pyXML!)


>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
>