flupke / pypotrace

Python bindings for potrace library
Other
165 stars 43 forks source link

-mno-cygwin deprecated and not supported in newer MinGW versions #6

Closed Algomorph closed 11 years ago

Algomorph commented 11 years ago

According to this this SO post, -mno-cygwin options are deprecated in gcc 4.7, and are not supported by newer versions of MinGW. I'm using gcc 4.7.1 from MinGW-w64 and I've encountered the same problem trying to build pypotrace on windows.

I guess " -mno-cygwin" should just be removed.

flupke commented 11 years ago

Removed from what? I don't see this option in setup.py

Algomorph commented 11 years ago

This is really a distutils bug, they've been trying to resolve it for a number of years now. Sorry, I guess the issue doesn't belong here.

flupke commented 11 years ago

Does swapping distutils with setuptools solve the issue?

Algomorph commented 11 years ago

It might. I'm not sure how to force it to use setuptools, though. Do you know?

flupke commented 11 years ago

You just have to replace the first two lines of setup.py:

from setuptools import setup
from setuptools.extension import Extension
Algomorph commented 11 years ago

Yes, I've already tried that, but the results were the same. Are you sure that the error isn't in the build_ext method of Cython? It appears as though that is used to actually compile the extensions.

flupke commented 11 years ago

No I'm not and I don't have a windows box to try. Can you put the complete build log here?

Algomorph commented 11 years ago

Well, the detailed log sheds some light on this:

c:\MinGW64\mingw64\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DMS_WIN64 -IC:/Python27/Lib/sit
e-packages/numpy/core/include -Ic:\Python27\include -Ic:\Python27\PC -c potrace\_potrace.c -o build\temp.win-amd64-2.7\Release\potrace\_potrace.o
gcc: error: unrecognized command line option '-mno-cygwin'
Traceback (most recent call last):
  File "setup.py", line 42, in <module>
    cmdclass = {"build_ext": build_ext},
  File "c:\Python27\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "c:\Python27\lib\distutils\dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "c:\Python27\lib\distutils\dist.py", line 972, in run_command
    cmd_obj.run()
  File "C:\Python27\Lib\site-packages\Cython\Distutils\build_ext.py", line 163, in run
    _build_ext.build_ext.run(self)
  File "c:\Python27\lib\distutils\command\build_ext.py", line 339, in run
    self.build_extensions()
  File "C:\Python27\Lib\site-packages\Cython\Distutils\build_ext.py", line 171, in build_extensions
    self.build_extension(ext)
  File "c:\Python27\lib\distutils\command\build_ext.py", line 498, in build_extension
      depends=ext.depends)
  File "c:\Python27\lib\distutils\ccompiler.py", line 572, in compile
    self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
  File "c:\Python27\lib\distutils\cygwinccompiler.py", line 166, in _compile
    raise CompileError, msg
distutils.errors.CompileError: command 'gcc' failed with exit status 1
sh: C:/Users/Algomorph/Garage/potrace-1.11/src: is a directory
sh: C:/Users/Algomorph/Garage/agg-2.5: is a directory
C:/Users/Algomorph/Garage/agg-2.5/src/libagg.a: line 1: syntax error near unexpected token
 `newline'
C:/Users/Algomorph/Garage/agg-2.5/src/libagg.a: line 1: `!<arch>'
Algomorph commented 11 years ago

I'm going to try to remove instances of -mno-cygwin from my distutils\cygwinccompiler.py file.

Algomorph commented 11 years ago

Well, I've got around the issue in two steps: 1) I removed the evil -mno-cygwin from the distutils\cygwinccompiler.py file 2) I changed the command line syntax to: python setup.py -v build_ext -I"C:\\Python27\\Lib\\site-packages\\numpy\\core\\include;C:\\Users\\Algomorph\\Garage\\potrace-1.11\\src;C:\\Users\\Algomorph\\Garage\\agg-2.5" -L"C:\\Users\\Algomorph\\Garage\\potrace-1.11\\src\\.libs;C:\\Users\\Algomorph\\Garage\\agg-2.5\\src"

Note specifically the double-quotes - you might want to add that to the build instructions for windows, since otherwise only the first argument gets read.

I'm not out of the woods yet completely, since now for some reason it cannot find the libagg_pic ("cannot find -lagg_pic"). I'll look further into what the problem is with that.

Algomorph commented 11 years ago

The only difference in my process for agg was that I used the an existing makefile (for win NT 6.1 - copy of the one for win NT 5.1) instead of running autogen, because the autogen script yielded a ton of errors and failed to generate a proper config file. It built libagg.a but nothing else.

Is there are libagg_pic.a being built when you build agg-2.5 on your machine?

flupke commented 11 years ago

Sorry I can't help here since I haven't developed on windows for years... Have you tried klonuo's instructions in the README ?

Algomorph commented 11 years ago

Yeah, his instructions is those I've been following, actually. They need to be tweaked a bit - see the above comment about quotes. I'm totally with you on switch to linux development, I use only linux at home. I'm only doing this because my research partner is more of a theoretician than a coder and only uses Windows, and I'm trying to determine whether it's possible at all for him to use this.

Can you check if you have libagg_pic.so or libagg_pic.a somewhere on linux where it would be visible to the build?

flupke commented 11 years ago

libagg_pic.a is part of the libagg-dev package:

$ apt-file search libagg_pic
libagg-dev: /usr/lib/libagg_pic.a
Algomorph commented 11 years ago

I guess this commit caused the issue: https://github.com/flupke/pypotrace/commit/f3e1d1449007440a9b04960c30479014878bdff1

agg was ultimately replaced with agg_pic. I'm going to rename my file to libagg_pic.a and see what gives.

Algomorph commented 11 years ago

That worked. So that can be added to the windows build instructions as well. klonuo specified that the include folder inside the agg-2.5 sources had to be renamed to agg2, so this could come right after it: "Rename libagg.a in agg-2.5/src/ to libagg_pic.a.

klonuo commented 10 years ago

Hi,

I think I understand your problem as you are trying to build 64bit package, i.e. potrace is easy to build with mingw64, but not agg which uses so called "auto" tools that aren't available in mingw64. Googling around and seeing dumb responses like this suggesting you build your own "auto" tools seems unrealistic to me.

OTOH, your approach of using mingw32 to do "auto" stuff and then use mingw64 on produced configure script wasn't too attractive to me, too.

So with this reply I want to suggest alternative of using already build 64bit agg lib from the latest mapserver (currently release-1600-x64-gdal-1-10-1-mapserver-6-4-1-libs.zip) and just copying agg.lib in agg-2.5 src folder and renaming it as agg_pic.lib.

Worked for me fine.

Cheers

Algomorph commented 10 years ago

Where are you getting the mingw32? I was using mingw64 exclusively, I believe, although this was awhile back.