wxPython-Phoenix on CentOS 6.8 with Python 3.6.0 issues

[Aleksey_Galipchak]

Hi All,

I’ve been banging my head on the desk trying to do a successful build for CentOS 6.8 using Python 3.6.0.

I was following the instructions for installing it on Ubuntu, with modifications for CentOS. Some packages in the guide are not available for CentOS 6.8, so I made due with what was there, if anything at all.

I was able to run “python3 build.py dox etg sip” without any problems. However, when I’m running “python3 build.py build” it errors out.

Here is the error I’m receiving:

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

compilation terminated.

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

compilation terminated.

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

compilation terminated.

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

compilation terminated.

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

compilation terminated.

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

compilation terminated.

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

compilation terminated.

make: *** [wxregex_regcomp.o] Error 1

make: *** Waiting for unfinished jobs…

make: *** [wxregex_regexec.o] Error 1

make: *** [wxregex_regerror.o] Error 1

make: *** [wxregex_regfree.o] Error 1

make: *** [wxexpat_xmlparse.o] Error 1

make: *** [wxexpat_xmlrole.o] Error 1

make: *** [wxexpat_xmltok.o] Error 1

Error building

ERROR: failed building wxWidgets

Traceback (most recent call last):

File “build.py”, line 1224, in cmd_build_wx

wxbuild.main(wxDir(), build_options)

File “/opt/aleksey/Phoenix/buildtools/build_wxwidgets.py”, line 491, in main

exitIfError(wxBuilder.build(dir=buildDir, options=args), “Error building”)

File “/opt/aleksey/Phoenix/buildtools/build_wxwidgets.py”, line 85, in exitIfError

raise builder.BuildError(msg)

buildtools.builder.BuildError: Error building

Finished command: build_wx (0.139s)

Finished command: build (0.140s)

I do not know what the files above are referring to and if I have a missing package that doesn’t allow me to read/create them.

I will be happy to provide any logs or info that is needed to further troubleshoot this issue.

Thank you in advance.

[Robin]

Aleksey Galipchak wrote:

Hi All,

I’ve been banging my head on
the desk trying to do a successful build for CentOS 6.8 using Python 3.6.0.

I was following the instructions for installing it on Ubuntu, with modifications for CentOS. Some packages in the guide are not available for CentOS 6.8, so I made due with what was there, if anything at all.

I was able to run “python3 build.py dox etg sip” without any problems. However, when I’m running * “python3
build.py build”* it errors out.

Here is the error I’m receiving:

…

···

It looks like something in the wxWidgets part of the config/build is going wrong, causing it to use an incorrect command line for the compiler. Try the following:

• Run “python3 build.py clean_wx” to clean up the failed wxWidgets build

• Run “python3 build.py build_wx --jobs=1 2>&1 | tee build.log” to try it again. The --jobs=1 flag tells it to just do one compilation at a time in order to not get potential error or warning messages mixed up. If it succeeds then there was probably some garbage or something in
  the build folders that confused things. You can go ahead and build the Phoenix modules with “python3 build.py build_py”. If the build_wx failed then send the build.log file so we can take a closer look at it.

–
Robin Dunn

Software Craftsman

http://wxPython.org

[Aleksey_Galipchak]

Hi Robin,

Unfortunately it did fail. I’ve attached the log file to be viewed.

This is where it looks like it failed:

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

compilation terminated.

make: *** [wxregex_regcomp.o] Error 1

build.log (35 KB)

[Tim_Roberts]

Aleksey Galipchak wrote:

Hi Robin,

Unfortunately it did fail. I've attached the log file to be viewed.

This is where it looks like it failed:

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files
compilation terminated.

/opt/aleksey/Phoenix/build/wxbld/bk-deps gcc -c -o wxregex_regcomp.o -DNDEBUG -D__WXGTK__ -fPIC -DPIC -D_FILE_OFFSET_BITS=64 -I/opt/aleksey/Phoenix/build/wxbld/lib/wx/include/gtk2-unicode-3.0 -I/opt/aleksey/Phoenix/ext/wxWidgets/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 -pthread -I/usr/include/webkit-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/include/libsoup-2.4 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libxml2 -pthread -Wall -Wundef -O2 -fno-strict-aliasing -pthread -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -pthread -I/usr/include/gtk-unix-print-2.0 -I/usr/include/gtk-2.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -D_GNU_SOURCE /tools/GNU/python/3.6.0/include/python3.6m/Python.h -fvisibility=hidden /opt/aleksey/Phoenix/ext/wxWidgets/src/regex/regcomp.c
gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

The problem is in the last full line:
    -D_GNU_SOURCE /tools/GNU/python/3.6.0/include/python3.6m/Python.h
The compiler sees that as a file name to compile.

I'm wondering if you accidentally have a CFLAGS environment variable
defined that might be interfering.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

[Aleksey_Galipchak]

Hi Tim,

Thank you! This helped with the build_wx but hindered the build_py. I do have a CFLAGS variable set for Python.h because otherwise I get the following error when building build_py.

Checking for program /tools/GNU/python/3.6.0/bin/python3-config,python3.6-config,python-config-3.6,python3.6m-config : /tools/GNU/python/3.6.0/bin/python3-config

Checking for header Python.h :

Asking python-config for pyembed --cflags flags : yes

Asking python-config for pyembed --libs flags : yes

Asking python-config for pyembed --ldflags flags : yes

Getting pyembed flags from python-config : Could not build a python embedded interpreter

The configuration failed

···

On Friday, March 31, 2017 at 4:30:11 PM UTC-7, Tim Roberts wrote:

Aleksey Galipchak wrote:

Hi Robin,

Unfortunately it did fail. I’ve attached the log file to be viewed.

This is where it looks like it failed:

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

compilation terminated.

/opt/aleksey/Phoenix/build/wxbld/bk-deps gcc -c -o wxregex_regcomp.o -DNDEBUG -D__WXGTK__ -fPIC -DPIC -D_FILE_OFFSET_BITS=64 -I/opt/aleksey/Phoenix/build/wxbld/lib/wx/include/gtk2-unicode-3.0 -I/opt/aleksey/Phoenix/ext/wxWidgets/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 -pthread -I/usr/include/webkit-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/include/libsoup-2.4 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libxml2 -pthread -Wall -Wundef -O2 -fno-strict-aliasing -pthread -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -pthread -I/usr/include/gtk-unix-print-2.0 -I/usr/include/gtk-2.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -D_GNU_SOURCE /tools/GNU/python/3.6.0/include/python3.6m/Python.h -fvisibility=hidden /opt/aleksey/Phoenix/ext/wxWidgets/src/regex/regcomp.c

gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files

The problem is in the last full line:

-D_GNU_SOURCE /tools/GNU/python/3.6.0/include/python3.6m/Python.h

The compiler sees that as a file name to compile.

I’m wondering if you accidentally have a CFLAGS environment variable

defined that might be interfering.

–
Tim Roberts, ti...@probo.com

Providenza & Boekelheide, Inc.

[Robin]

Robin

Try using “-I /tools/GNU/python/3.6.0/include/python3.6m” in your CFLAGS (with the leading -I and without the trailing Python.h)

···

On Monday, April 3, 2017 at 9:11:07 AM UTC-7, Aleksey Galipchak wrote:

Hi Tim,

Thank you! This helped with the build_wx but hindered the build_py. I do have a CFLAGS variable set for Python.h because otherwise I get the following error when building build_py.

Checking for program /tools/GNU/python/3.6.0/bin/python3-config,python3.6-config,python-config-3.6,python3.6m-config : /tools/GNU/python/3.6.0/bin/python3-config

Checking for header Python.h :

Asking python-config for pyembed --cflags flags : yes

Asking python-config for pyembed --libs flags : yes

Asking python-config for pyembed --ldflags flags : yes

Getting pyembed flags from python-config : Could not build a python embedded interpreter

The configuration failed

[Aleksey_Galipchak]

I tried it, but it didn’t work. At first I noticed there’s a space between the “-l” and the path of the directory so I took that space away. Neither way worked.
Also, it seems like having the file, python.h, in there doesn’t work either.

I don’t know why GCC is having an issue seeing it. There is a log that’s written to /Phoenix/build/waf/3.6/. I’ve attached it to this reply.

config.log (21.3 KB)

···

On Monday, April 3, 2017 at 12:32:21 PM UTC-7, Robin Dunn wrote:

On Monday, April 3, 2017 at 9:11:07 AM UTC-7, Aleksey Galipchak wrote:

Hi Tim,

Thank you! This helped with the build_wx but hindered the build_py. I do have a CFLAGS variable set for Python.h because otherwise I get the following error when building build_py.

Checking for program /tools/GNU/python/3.6.0/bin/python3-config,python3.6-config,python-config-3.6,python3.6m-config : /tools/GNU/python/3.6.0/bin/python3-config

Checking for header Python.h :

Asking python-config for pyembed --cflags flags : yes

Asking python-config for pyembed --libs flags : yes

Asking python-config for pyembed --ldflags flags : yes

Getting pyembed flags from python-config : Could not build a python embedded interpreter

The configuration failed

Robin

Try using “-I /tools/GNU/python/3.6.0/include/python3.6m” in your CFLAGS (with the leading -I and without the trailing Python.h)

[Robin]

It looks to me like the Python in /tools/GNU/python/3.6.0/bin/ is built or installed in a such a way that is confusing waf. Based on the log, waf is using /tools/GNU/python/3.6.0/bin/python3-config to get info about build flags, dirs and libs to use for building extensions. So probably the first thing to do is to run that script yourself and verify the output for the various options. For example, based the log again it looks like it is giving “-I/.automount/.automount/tools/GNU/python/3.6.0/include/python3.6m” for --cflags, which I’m guessing matches the machine that the Python package was built on, not the one it is installed on (yours). You’ll also want to verify --ldflags and --libs.

You can probably hack your Python installation if you have write access to those folders, search for “/.automount/.automount” in the …/python/3.6.0 tree and edit as needed. (And any other bad flags or values you may find.) But it looks to me like the real fault lies with wherever that python came from, so you probably should file a bug report with them about it.

HTH,

Robin

···

On Monday, April 3, 2017 at 2:00:52 PM UTC-7, Aleksey Galipchak wrote:

I tried it, but it didn’t work. At first I noticed there’s a space between the “-l” and the path of the directory so I took that space away. Neither way worked.
Also, it seems like having the file, python.h, in there doesn’t work either.

I don’t know why GCC is having an issue seeing it. There is a log that’s written to /Phoenix/build/waf/3.6/. I’ve attached it to this reply.

On Monday, April 3, 2017 at 12:32:21 PM UTC-7, Robin Dunn wrote:

On Monday, April 3, 2017 at 9:11:07 AM UTC-7, Aleksey Galipchak wrote:

Hi Tim,

Thank you! This helped with the build_wx but hindered the build_py. I do have a CFLAGS variable set for Python.h because otherwise I get the following error when building build_py.

Checking for program /tools/GNU/python/3.6.0/bin/python3-config,python3.6-config,python-config-3.6,python3.6m-config : /tools/GNU/python/3.6.0/bin/python3-config

Checking for header Python.h :

Asking python-config for pyembed --cflags flags : yes

Asking python-config for pyembed --libs flags : yes

Asking python-config for pyembed --ldflags flags : yes

Getting pyembed flags from python-config : Could not build a python embedded interpreter

The configuration failed

Robin

Try using “-I /tools/GNU/python/3.6.0/include/python3.6m” in your CFLAGS (with the leading -I and without the trailing Python.h)

[Aleksey_Galipchak]

Thank you for all the help troubleshooting. I’ll do some more investigation in the install and config files.

···

On Monday, April 3, 2017 at 4:48:30 PM UTC-7, Robin Dunn wrote:

It looks to me like the Python in /tools/GNU/python/3.6.0/bin/ is built or installed in a such a way that is confusing waf. Based on the log, waf is using /tools/GNU/python/3.6.0/bin/python3-config to get info about build flags, dirs and libs to use for building extensions. So probably the first thing to do is to run that script yourself and verify the output for the various options. For example, based the log again it looks like it is giving “-I/.automount/.automount/tools/GNU/python/3.6.0/include/python3.6m” for --cflags, which I’m guessing matches the machine that the Python package was built on, not the one it is installed on (yours). You’ll also want to verify --ldflags and --libs.

You can probably hack your Python installation if you have write access to those folders, search for “/.automount/.automount” in the …/python/3.6.0 tree and edit as needed. (And any other bad flags or values you may find.) But it looks to me like the real fault lies with wherever that python came from, so you probably should file a bug report with them about it.

HTH,

Robin

On Monday, April 3, 2017 at 2:00:52 PM UTC-7, Aleksey Galipchak wrote:

I tried it, but it didn’t work. At first I noticed there’s a space between the “-l” and the path of the directory so I took that space away. Neither way worked.
Also, it seems like having the file, python.h, in there doesn’t work either.

I don’t know why GCC is having an issue seeing it. There is a log that’s written to /Phoenix/build/waf/3.6/. I’ve attached it to this reply.

On Monday, April 3, 2017 at 12:32:21 PM UTC-7, Robin Dunn wrote:

On Monday, April 3, 2017 at 9:11:07 AM UTC-7, Aleksey Galipchak wrote:

Hi Tim,

Thank you! This helped with the build_wx but hindered the build_py. I do have a CFLAGS variable set for Python.h because otherwise I get the following error when building build_py.

Checking for program /tools/GNU/python/3.6.0/bin/python3-config,python3.6-config,python-config-3.6,python3.6m-config : /tools/GNU/python/3.6.0/bin/python3-config

Checking for header Python.h :

Asking python-config for pyembed --cflags flags : yes

Asking python-config for pyembed --libs flags : yes

Asking python-config for pyembed --ldflags flags : yes

Getting pyembed flags from python-config : Could not build a python embedded interpreter

The configuration failed

Robin

Try using “-I /tools/GNU/python/3.6.0/include/python3.6m” in your CFLAGS (with the leading -I and without the trailing Python.h)

[Aleksey_Galipchak]

So after some checking, (grep -r “/.automount/.automount” {in python install}) there was nothing found. It’s not supposed to list automount twice in a row. I’m wondering if the pathing for python is broken somewhere. I do have root access to the machine this is installed on. It’s actually on a server, and it’s loaded into the environment via modules.

I’ll do more digging.

···

On Monday, April 3, 2017 at 4:48:30 PM UTC-7, Robin Dunn wrote:

It looks to me like the Python in /tools/GNU/python/3.6.0/bin/ is built or installed in a such a way that is confusing waf. Based on the log, waf is using /tools/GNU/python/3.6.0/bin/python3-config to get info about build flags, dirs and libs to use for building extensions. So probably the first thing to do is to run that script yourself and verify the output for the various options. For example, based the log again it looks like it is giving “-I/.automount/.automount/tools/GNU/python/3.6.0/include/python3.6m” for --cflags, which I’m guessing matches the machine that the Python package was built on, not the one it is installed on (yours). You’ll also want to verify --ldflags and --libs.

You can probably hack your Python installation if you have write access to those folders, search for “/.automount/.automount” in the …/python/3.6.0 tree and edit as needed. (And any other bad flags or values you may find.) But it looks to me like the real fault lies with wherever that python came from, so you probably should file a bug report with them about it.

HTH,

Robin

On Monday, April 3, 2017 at 2:00:52 PM UTC-7, Aleksey Galipchak wrote:

I tried it, but it didn’t work. At first I noticed there’s a space between the “-l” and the path of the directory so I took that space away. Neither way worked.
Also, it seems like having the file, python.h, in there doesn’t work either.

I don’t know why GCC is having an issue seeing it. There is a log that’s written to /Phoenix/build/waf/3.6/. I’ve attached it to this reply.

On Monday, April 3, 2017 at 12:32:21 PM UTC-7, Robin Dunn wrote:

On Monday, April 3, 2017 at 9:11:07 AM UTC-7, Aleksey Galipchak wrote:

Hi Tim,

Thank you! This helped with the build_wx but hindered the build_py. I do have a CFLAGS variable set for Python.h because otherwise I get the following error when building build_py.

Checking for program /tools/GNU/python/3.6.0/bin/python3-config,python3.6-config,python-config-3.6,python3.6m-config : /tools/GNU/python/3.6.0/bin/python3-config

Checking for header Python.h :

Asking python-config for pyembed --cflags flags : yes

Asking python-config for pyembed --libs flags : yes

Asking python-config for pyembed --ldflags flags : yes

Getting pyembed flags from python-config : Could not build a python embedded interpreter

The configuration failed

Robin

Try using “-I /tools/GNU/python/3.6.0/include/python3.6m” in your CFLAGS (with the leading -I and without the trailing Python.h)

[Aleksey_Galipchak]

Holy crap I’ve figured it out. This is within Python, and I don’t know if this is a bug in the 3.6.0 version or something of my own doing. I don’t even know where to submit it so they can take a look at it.

Essencially, after opening up python3-config script with vi, I noticed they had a section in there for builds (around line 32). For some reason, in the script they had the following: prefix=$(echo “$prefix_build”****| sed “s#$prefix_build#$prefix_real#”)

This made it so /.automount was duplicated for some reason. I commented out the sed portion of the command and build_py went through! It built 851 items afterwards and finished successfully.

I’ll continue on with the installation to make sure everything works out afterwards but this is a huge step in the right direction to making it work.

Thanks to all whom responded. This has put me on the right path to troubleshoot the problem.

-Aleksey

···

On Monday, April 3, 2017 at 4:48:30 PM UTC-7, Robin Dunn wrote:

It looks to me like the Python in /tools/GNU/python/3.6.0/bin/ is built or installed in a such a way that is confusing waf. Based on the log, waf is using /tools/GNU/python/3.6.0/bin/python3-config to get info about build flags, dirs and libs to use for building extensions. So probably the first thing to do is to run that script yourself and verify the output for the various options. For example, based the log again it looks like it is giving “-I/.automount/.automount/tools/GNU/python/3.6.0/include/python3.6m” for --cflags, which I’m guessing matches the machine that the Python package was built on, not the one it is installed on (yours). You’ll also want to verify --ldflags and --libs.

You can probably hack your Python installation if you have write access to those folders, search for “/.automount/.automount” in the …/python/3.6.0 tree and edit as needed. (And any other bad flags or values you may find.) But it looks to me like the real fault lies with wherever that python came from, so you probably should file a bug report with them about it.

HTH,

Robin

On Monday, April 3, 2017 at 2:00:52 PM UTC-7, Aleksey Galipchak wrote:

I tried it, but it didn’t work. At first I noticed there’s a space between the “-l” and the path of the directory so I took that space away. Neither way worked.
Also, it seems like having the file, python.h, in there doesn’t work either.

I don’t know why GCC is having an issue seeing it. There is a log that’s written to /Phoenix/build/waf/3.6/. I’ve attached it to this reply.

On Monday, April 3, 2017 at 12:32:21 PM UTC-7, Robin Dunn wrote:

On Monday, April 3, 2017 at 9:11:07 AM UTC-7, Aleksey Galipchak wrote:

Hi Tim,

Thank you! This helped with the build_wx but hindered the build_py. I do have a CFLAGS variable set for Python.h because otherwise I get the following error when building build_py.

Checking for program /tools/GNU/python/3.6.0/bin/python3-config,python3.6-config,python-config-3.6,python3.6m-config : /tools/GNU/python/3.6.0/bin/python3-config

Checking for header Python.h :

Asking python-config for pyembed --cflags flags : yes

Asking python-config for pyembed --libs flags : yes

Asking python-config for pyembed --ldflags flags : yes

Getting pyembed flags from python-config : Could not build a python embedded interpreter

The configuration failed

Robin

Try using “-I /tools/GNU/python/3.6.0/include/python3.6m” in your CFLAGS (with the leading -I and without the trailing Python.h)