I'll have to try it with rc3 and see if I get the same errors (although I
get that behavior very frequently when trying to build rpm's). I was
using (final release) ZSI-2.0 downloaded from pywebsvcs.sourceforge.net.
I'll do it tomorrow in the office and send you both.
Stan Klein
On Tue, May 2
At 05:23 PM 5/22/2007 -0400, Stanley A. Klein wrote:
>Prior to attempting the rpm build, I updated my version of setuptools to
>0.6c5 (package python-setuptools-0.6c5-1.fc5).
Would you mind emailing me the *entire* output of the bdist_rpm
operation? When I try this with 0.6c5 and the source of Z
> I have a set of extensions that use SWIG to wrap my own C++ library.
> This library, on a day-to-day basis is built against VS8 since the rest
> of our product suite is. Right now I have no way to work with this code
> using VS8 since the standard distribution is built against VS7 which
> uses
> Surely there are differences between architectures? PC uses MSI after all.
> Why can't linux be under trunk/linux and pc 86 under trunk/pcbuild8/win32PGO
> and 64 under trunk/pcbuild8/x64pgo?
That couldn't work for me. I try avoid building on a network drive, and
with local drives, I just can't
> While that is true in theory, I often find it is not the case in practice,
> generally due to the optimizer. Depending on what magic the compiler has
> done, it can be very difficult to set breakpoints (conditional or
> otherwise), inspect variable values, etc. It is useful in some cases, but
>
> I'd be happy to install Windows and the latest VisualStudio on a 64-bit
> VMware image. I just can't be responsible for day-to-day administration
> of the buildslave; Windows requires too much attention for me to do
> that.
Thanks for the offer. Perhaps Kristjan is interested in setting up a
bu
Prior to attempting the rpm build, I updated my version of setuptools to
0.6c5 (package python-setuptools-0.6c5-1.fc5).
Stan Klein
On Tue, May 22, 2007 5:03 pm, Phillip J. Eby wrote:
> At 05:01 PM 5/22/2007 -0400, Stanley A. Klein wrote:
>>Below is a typical example of the problem I encounter.
At 05:01 PM 5/22/2007 -0400, Stanley A. Klein wrote:
>Below is a typical example of the problem I encounter. I tried to build
>an RPM of ZSI-2.0 using "python setup.py bdist_rpm", and got the output
>below at the end.
What version of setuptools are you using?
On 4/24/07, "Nathan R. Yergler" wrote:
>On 4/24/07, Stanley A. Klein wrote:
>> I need to create a customized Fedora live CD with Python applications on
>> it. The live CD requires rpm's of the applications. (The issues are
>> similar to a customized Ubuntu live CD but Ubuntu requires deb's.)
>>
I recommend that those people install the official binaries. Why do
you
need to build the binaries from source, if all you want is to build
extensions?
I've been following this discussion and it seems like an appropriate
place to mention such a scenario which I have encountered myself and
It seems to be a problem with distutils currently that g++ isn't used to
link at the appropriate time. Ideally you'd split linking into C++ and C
variations, and detect whether the C++ compiler was used and use the
C++ linker if it was.
And, a bug related to this, is that you can't easily
> Someone mentioned the idea to have a bat file do it. I like
> that idea. There is already a build.bat file which will
> build whatever configuration you choose (platform and
> configuration). Extending it to subsequently copy the
> resulting binaries up one level is easy. Perhaps this is
> -Original Message-
> > > It seems the
> > > best thing might be to modify the PCBuild8 build process so the
> output
> > > binaries are in the ../PCBuild' directory - this way distutils and
> others
> > > continue to work fine. Does that sound reasonable?
>
> > I think Kristjan will ha
> -Original Message-
> Nobody proposed to ditch cross-compilation. I very much like
> cross-compilation, I do all Itanium and AMD64 in cross-compilation.
>
> I just want the *file structure* of the output to be the very same
> for all architectures, meaning that they can't coexist in a si
> -Original Message-
> From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 22, 2007 05:33
> To: Steve Holden
> Cc: Kristján Valur Jónsson; Mark Hammond; distutils-sig@python.org;
> [EMAIL PROTECTED]
> Subject: Re: Adventures with x64, VS7 and VS8 on Windows
>
> > Address
Hi Mark,
>> +1 from me.
>>
>> I think this is simply a bug introduced with the UCS4 patches in
>> Python 2.2.
>>
>> unicodeobject.h already has this code:
>>
>> #ifndef PY_UNICODE_TYPE
>>
>> /* Windows has a usable wchar_t type (unless we're using UCS-4) */
>> # if defined(MS_WIN32) && Py_UNICODE_
16 matches
Mail list logo
