Robin Becker added the comment:
for what it's worth I tried reverse patching
https://hg.python.org/cpython/rev/63ae310b60ff/
and
https://hg.python.org/cpython/rev/2f77a9f0b9d6/
in the manylinux docker and the make then proceeds fine with one warning at the
end
*** WARNING: ren
Robin Becker added the comment:
After some searching I tried adding -std=gnu99 and the config goes through OK,
but running make produces
[root@d3cce9786c2e Python-3.6.0b2]# make -j2
gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -Wformat
Robin Becker added the comment:
benjamin.peterson: I tried adding that option -fno-gnu89-inline conditionally
for the 3.6.0b2 build, but it goes wrong in config with an error
configure:3913: $? = 4
configure:3933: checking whether the C compiler works
configure:3955: gcc -Wformat -fno-gnu89
Robin Becker added the comment:
I'm not able to access my work computer, I'll try later today at home.
--
___
Python tracker
<http://bugs.python.o
Robin Becker added the comment:
tds333, the config says that 4.8.2 is being used,
configure:3902: gcc --version >&5
gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
w
Robin Becker added the comment:
Hi njs,
my manylinux diffs
https://www.reportlab.com/media/manylinux-diff.txt
full output of the docker command
docker build -f Dockerfile-x86_64 -t rl/manylinux-x86_64 . &> ~/tmp/ttt
https://www.reportlab.com/media/manylinux-docker-run-output.txt
Robin Becker added the comment:
I executed gcc --version (&cc --version) in the do_cpython_build function
immediately prior to the make -j2 that builds python noth show 4.8.2.
I see the exact same errors as in the initial report. If the makefile or the
configure is doing something spe
Robin Becker added the comment:
Don't want to add too much noise, but this issue also affects the manylinux
project build compiler (gcc 4.8.2).
--
nosy: +rgbecker
___
Python tracker
<http://bugs.python.org/is
Robin Becker added the comment:
I'll repeat the post I made to BreamoreBoy regarding this bug:
"re: http://bugs.python.org/issue1047397
this bug is now 10 years old. I'm not sure why it's to be considered
closed because the original intent of the bug report was that th
Robin Becker added the comment:
I cheated on the building both versions. I had 32 bit python installed and with
the help of a colleague got hold of the installed files for the 64 bit version.
I noticed that distutils was looking for the 64bit files in new_lib =
os.path.join(sys.exec_prefix
Robin Becker added the comment:
That would be a solution if we had a separate 64 bit machine & extra versions
of Visual Studio, but the actual bug is with the cross-compiling behaviour. If
it's not supposed to work then this isn't a bug and section 5.4 should go;
otherwise t
Robin Becker added the comment:
Some context. ReportLab windows exe installers for pythons 2.x x=4-7 are built
on a single 32bit machine with 32bit pythons using a code that looks like this
set FT_LIB=c:\devel\libs_x86\freetype.lib
\python2x\python setup.py bdist_wininst --bitmap=%BMP
New submission from Robin Becker :
I notice this from win32 setup.py bdist_wininst --plat-name=win-amd64
> running bdist_wininst
> running build
> running build_py
> creating build
> creating build\lib.win32-2.6
> creating build\lib.win32-2.6\reportlab
> copying src\r
New submission from Robin Becker :
When building extensions on win32 distutils with --plat-name=win-amd64 adds
PCBuild/AMD64 in the wrong place.
This patch ensures the AMD64 location comes first
--
assignee: tarek
components: Distutils
files: patch.txt
messages: 101259
nosy: rgbecker
14 matches
Mail list logo
