Menu
▾
▴
pysparse-users
|
From: Rob S. <rs...@MI...> - 2010-03-11 19:39:41
|
I'm having two problems that make it difficult to install Pysparse in
many situations. I'm writing a library that depends on Pysparse, but I
can't distribute this library if Pysparse itself won't install.
1. Pysparse doesn't support "setup.py develop". This means it cannot
be installed through Pip.
This seems to be because of the line:
package_dir = {package_name: 'Lib'},
The problem is that there is no valid directory to put on the Python
path. Here's a bug report about this issue (which was closed as
invalid in Pip because they concluded it's a problem with either
setuptools or pysparse):
http://bitbucket.org/ianb/pip/issue/72/editable-install-doesnt-respect-package_dir
It sounds like this could be fixed by reorganizing the code structure,
or at least making a symlink, so that there is an actual "pysparse"
directory at the top level. Renaming "Lib" to "pysparse" might be the
right answer.
2. Pysparse won't install in a virtualenv. It tries to install files
in the include/ directory of your Python environment, but virtualenvs
don't have their own include directory. They just symlink to the
system-wide one.
I don't know what the correct way to resolve this one is, because I've
never had to manage additional include files in a Python package.
Thanks,
-- Rob
|
|
From: Dominique O. <dom...@gm...> - 2010-03-19 14:28:03
|
On Thu, Mar 11, 2010 at 7:39 PM, Rob Speer <rs...@mi...> wrote:
> I'm having two problems that make it difficult to install Pysparse in
> many situations. I'm writing a library that depends on Pysparse, but I
> can't distribute this library if Pysparse itself won't install.
>
>
> 1. Pysparse doesn't support "setup.py develop". This means it cannot
> be installed through Pip.
>
> This seems to be because of the line:
> package_dir = {package_name: 'Lib'},
>
> The problem is that there is no valid directory to put on the Python
> path. Here's a bug report about this issue (which was closed as
> invalid in Pip because they concluded it's a problem with either
> setuptools or pysparse):
>
> http://bitbucket.org/ianb/pip/issue/72/editable-install-doesnt-respect-package_dir
>
> It sounds like this could be fixed by reorganizing the code structure,
> or at least making a symlink, so that there is an actual "pysparse"
> directory at the top level. Renaming "Lib" to "pysparse" might be the
> right answer.
>
>
> 2. Pysparse won't install in a virtualenv. It tries to install files
> in the include/ directory of your Python environment, but virtualenvs
> don't have their own include directory. They just symlink to the
> system-wide one.
>
> I don't know what the correct way to resolve this one is, because I've
> never had to manage additional include files in a Python package.
Rob,
Thanks for the feedback. #1 has been on my list for a long time but
never gets adressed because time is scarce. I really want to have a
proper setup.py for Pysparse. I'm now getting better at writing them
so maybe I can whip up something quick.
Regarding #2, could you be more specific? In my experience,
package-specific include files always go to the include/ directory of
the local Python environment. However, you can normally install
packages "locally" (e.g., in your home directory) instead of system
wide, by using an option such as --prefix or --home with setup.py. I
might have misunderstood your question...
Cheers,
--
Dominique
|
|
From: Rob S. <rs...@MI...> - 2010-03-24 17:25:09
|
>> 2. Pysparse won't install in a virtualenv. It tries to install files >> in the include/ directory of your Python environment, but virtualenvs >> don't have their own include directory. They just symlink to the >> system-wide one. >> >> I don't know what the correct way to resolve this one is, because I've >> never had to manage additional include files in a Python package. > > Rob, > > Thanks for the feedback. #1 has been on my list for a long time but > never gets adressed because time is scarce. I really want to have a > proper setup.py for Pysparse. I'm now getting better at writing them > so maybe I can whip up something quick. > > Regarding #2, could you be more specific? In my experience, > package-specific include files always go to the include/ directory of > the local Python environment. However, you can normally install > packages "locally" (e.g., in your home directory) instead of system > wide, by using an option such as --prefix or --home with setup.py. I > might have misunderstood your question... Responding to this part now: does your local Python environment actually have its own include/ directory? Because my virtualenv just has a symbolic link to the Python global one. This means that installing pysparse in a virtualenv requires permission to modify the global Python include directory, and it does so. -- Rob |
|
From: Dominique O. <dom...@gm...> - 2010-03-25 14:18:15
|
On Wed, Mar 24, 2010 at 5:24 PM, Rob Speer <rs...@mi...> wrote: >>> 2. Pysparse won't install in a virtualenv. It tries to install files >>> in the include/ directory of your Python environment, but virtualenvs >>> don't have their own include directory. They just symlink to the >>> system-wide one. >>> >>> I don't know what the correct way to resolve this one is, because I've >>> never had to manage additional include files in a Python package. >> >> Rob, >> >> Thanks for the feedback. #1 has been on my list for a long time but >> never gets adressed because time is scarce. I really want to have a >> proper setup.py for Pysparse. I'm now getting better at writing them >> so maybe I can whip up something quick. >> >> Regarding #2, could you be more specific? In my experience, >> package-specific include files always go to the include/ directory of >> the local Python environment. However, you can normally install >> packages "locally" (e.g., in your home directory) instead of system >> wide, by using an option such as --prefix or --home with setup.py. I >> might have misunderstood your question... > > Responding to this part now: does your local Python environment > actually have its own include/ directory? Because my virtualenv just > has a symbolic link to the Python global one. This means that > installing pysparse in a virtualenv requires permission to modify the > global Python include directory, and it does so. No my virtual environment doesn't have its own include dir. All it has is a symlink to the system include dir. This looks like a defect of virtualenv, really. The pysparse header files are now installed under pysparse/include in the lib/pythonX.Y directory. So this doesn't cause permission issues with virtual environments anymore. I also added a convenience function for packages that rely on pysparse: >>> import pysparse >>> pysparse.get_include() Let me know how that goes. -- Dominique |
|
From: Rob S. <rs...@MI...> - 2010-03-25 16:11:46
|
Thanks for figuring out the include thing! You should put setuptools in a try/except block. Remember, I want users to automatically pull in pysparse as a dependency, so they wouldn't have an option to stop the process between downloading and installing pysparse to edit a file. And when pip installs something from SVN instead of from PyPI, it insists on 'setup.py develop'. It's fortunate that pip can force setuptools to be imported, but we shouldn't rely on that behavior. Unrelatedly, I've just noticed a bug in the PysparseMatrix class. It has a .matvec method that doesn't meet NumPy's requirements (because it returns its result, instead of writing it into another array). Currently I work around it by using .matrix.matvec, which does the right thing, but it would be nice if this worked better. Would it make sense for me to have SVN access so I can fix minor things like this? -- Rob On Thu, Mar 25, 2010 at 10:18 AM, Dominique Orban <dom...@gm...> wrote: > On Wed, Mar 24, 2010 at 5:24 PM, Rob Speer <rs...@mi...> wrote: >>>> 2. Pysparse won't install in a virtualenv. It tries to install files >>>> in the include/ directory of your Python environment, but virtualenvs >>>> don't have their own include directory. They just symlink to the >>>> system-wide one. >>>> >>>> I don't know what the correct way to resolve this one is, because I've >>>> never had to manage additional include files in a Python package. >>> >>> Rob, >>> >>> Thanks for the feedback. #1 has been on my list for a long time but >>> never gets adressed because time is scarce. I really want to have a >>> proper setup.py for Pysparse. I'm now getting better at writing them >>> so maybe I can whip up something quick. >>> >>> Regarding #2, could you be more specific? In my experience, >>> package-specific include files always go to the include/ directory of >>> the local Python environment. However, you can normally install >>> packages "locally" (e.g., in your home directory) instead of system >>> wide, by using an option such as --prefix or --home with setup.py. I >>> might have misunderstood your question... >> >> Responding to this part now: does your local Python environment >> actually have its own include/ directory? Because my virtualenv just >> has a symbolic link to the Python global one. This means that >> installing pysparse in a virtualenv requires permission to modify the >> global Python include directory, and it does so. > > No my virtual environment doesn't have its own include dir. All it has > is a symlink to the system include dir. This looks like a defect of > virtualenv, really. > > The pysparse header files are now installed under pysparse/include in > the lib/pythonX.Y directory. So this doesn't cause permission issues > with virtual environments anymore. I also added a convenience function > for packages that rely on pysparse: > >>>> import pysparse >>>> pysparse.get_include() > > Let me know how that goes. > > -- > Dominique > |
|
From: Rob S. <rs...@MI...> - 2010-03-25 18:10:57
|
Huh. Now I'm confused. It looks like NumPy and SciPy documentation expect matvec to have the behavior it does in PysparseMatrix, but pysparse.jdsym expects the behavior it has in ll_mat. -- Rob On Thu, Mar 25, 2010 at 12:11 PM, Rob Speer <rs...@mi...> wrote: > Thanks for figuring out the include thing! > > You should put setuptools in a try/except block. Remember, I want > users to automatically pull in pysparse as a dependency, so they > wouldn't have an option to stop the process between downloading and > installing pysparse to edit a file. And when pip installs something > from SVN instead of from PyPI, it insists on 'setup.py develop'. > > It's fortunate that pip can force setuptools to be imported, but we > shouldn't rely on that behavior. > > Unrelatedly, I've just noticed a bug in the PysparseMatrix class. It > has a .matvec method that doesn't meet NumPy's requirements (because > it returns its result, instead of writing it into another array). > Currently I work around it by using .matrix.matvec, which does the > right thing, but it would be nice if this worked better. Would it make > sense for me to have SVN access so I can fix minor things like this? > > -- Rob > > On Thu, Mar 25, 2010 at 10:18 AM, Dominique Orban > <dom...@gm...> wrote: >> On Wed, Mar 24, 2010 at 5:24 PM, Rob Speer <rs...@mi...> wrote: >>>>> 2. Pysparse won't install in a virtualenv. It tries to install files >>>>> in the include/ directory of your Python environment, but virtualenvs >>>>> don't have their own include directory. They just symlink to the >>>>> system-wide one. >>>>> >>>>> I don't know what the correct way to resolve this one is, because I've >>>>> never had to manage additional include files in a Python package. >>>> >>>> Rob, >>>> >>>> Thanks for the feedback. #1 has been on my list for a long time but >>>> never gets adressed because time is scarce. I really want to have a >>>> proper setup.py for Pysparse. I'm now getting better at writing them >>>> so maybe I can whip up something quick. >>>> >>>> Regarding #2, could you be more specific? In my experience, >>>> package-specific include files always go to the include/ directory of >>>> the local Python environment. However, you can normally install >>>> packages "locally" (e.g., in your home directory) instead of system >>>> wide, by using an option such as --prefix or --home with setup.py. I >>>> might have misunderstood your question... >>> >>> Responding to this part now: does your local Python environment >>> actually have its own include/ directory? Because my virtualenv just >>> has a symbolic link to the Python global one. This means that >>> installing pysparse in a virtualenv requires permission to modify the >>> global Python include directory, and it does so. >> >> No my virtual environment doesn't have its own include dir. All it has >> is a symlink to the system include dir. This looks like a defect of >> virtualenv, really. >> >> The pysparse header files are now installed under pysparse/include in >> the lib/pythonX.Y directory. So this doesn't cause permission issues >> with virtual environments anymore. I also added a convenience function >> for packages that rely on pysparse: >> >>>>> import pysparse >>>>> pysparse.get_include() >> >> Let me know how that goes. >> >> -- >> Dominique >> > |
|
From: Dominique O. <dom...@gm...> - 2010-03-26 08:01:49
|
On Thu, Mar 25, 2010 at 4:11 PM, Rob Speer <rs...@mi...> wrote: > Thanks for figuring out the include thing! > > You should put setuptools in a try/except block. Remember, I want > users to automatically pull in pysparse as a dependency, so they > wouldn't have an option to stop the process between downloading and > installing pysparse to edit a file. And when pip installs something > from SVN instead of from PyPI, it insists on 'setup.py develop'. > > It's fortunate that pip can force setuptools to be imported, but we > shouldn't rely on that behavior. > > Unrelatedly, I've just noticed a bug in the PysparseMatrix class. It > has a .matvec method that doesn't meet NumPy's requirements (because > it returns its result, instead of writing it into another array). > Currently I work around it by using .matrix.matvec, which does the > right thing, but it would be nice if this worked better. Would it make > sense for me to have SVN access so I can fix minor things like this? I did try to wrap 'import setuptools' in a try/except but that had consequences when I did simple 'python setup.py install'. It created new directories and eggs. I'd rather leave it up to the user unless there is a strong consensus otherwise. The matvec behavior is the intended behavior. The whole idea of the PysparseMatrix class is that it is "easy" and "natural" to use. Amongst other things, that means you can say y=A*x instead of A.matvec(x,y). The savvy user will notice (as you did) that ll_mat objects are more efficient and will use those. The typical user will use the PysparseMatrix class. -- Dominique |
|
From: Rob S. <rs...@MI...> - 2010-03-26 16:33:09
|
> The matvec behavior is the intended behavior. The whole idea of the > PysparseMatrix class is that it is "easy" and "natural" to use. > Amongst other things, that means you can say y=A*x instead of > A.matvec(x,y). The savvy user will notice (as you did) that ll_mat > objects are more efficient and will use those. The typical user will > use the PysparseMatrix class. That creates a rather broken API. Having an inplace version of matvec is fine, but please at least call it "matvec_inplace" or something, in both ll_mat and jdsym, to make it clear that it's not supposed to be matvec. The current situation is very confusing. -- Rob |
|
From: Dominique O. <dom...@gm...> - 2010-03-26 23:15:47
|
On Fri, Mar 26, 2010 at 4:32 PM, Rob Speer <rs...@mi...> wrote: >> The matvec behavior is the intended behavior. The whole idea of the >> PysparseMatrix class is that it is "easy" and "natural" to use. >> Amongst other things, that means you can say y=A*x instead of >> A.matvec(x,y). The savvy user will notice (as you did) that ll_mat >> objects are more efficient and will use those. The typical user will >> use the PysparseMatrix class. > > That creates a rather broken API. Having an inplace version of matvec > is fine, but please at least call it "matvec_inplace" or something, in > both ll_mat and jdsym, to make it clear that it's not supposed to be > matvec. The current situation is very confusing. I understand your confusion now. You're not supposed to use the matvec method of a PysparseMatrix object. You're just supposed to say "*", as in y=A*x. One of us did add a matvec method in there just because that is what Scipy solvers expect. I should really let the others chime in about renaming ll_mat.matvec. That would surely break some existing code. Perhaps the surest thing is to subclass PysparseMatrix and add the matvec method there, just for Scipy solvers. Thanks for the raising this point. Dominique -- Dominique |
|
From: Rob S. <rs...@MI...> - 2010-03-27 01:51:00
|
On Fri, Mar 26, 2010 at 4:01 AM, Dominique Orban <dom...@gm...> wrote: > I did try to wrap 'import setuptools' in a try/except but that had > consequences when I did simple 'python setup.py install'. It created > new directories and eggs. I'd rather leave it up to the user unless > there is a strong consensus otherwise. The egg-info directory does have a purpose: it allows the package to be upgraded or uninstalled without manually hacking the site-packages directory. What harm does it do? -- Rob |
|
From: Dominique O. <dom...@gm...> - 2010-03-29 18:58:42
|
On Fri, Mar 26, 2010 at 9:50 PM, Rob Speer <rs...@mi...> wrote: > On Fri, Mar 26, 2010 at 4:01 AM, Dominique Orban > <dom...@gm...> wrote: >> I did try to wrap 'import setuptools' in a try/except but that had >> consequences when I did simple 'python setup.py install'. It created >> new directories and eggs. I'd rather leave it up to the user unless >> there is a strong consensus otherwise. > > The egg-info directory does have a purpose: it allows the package to > be upgraded or uninstalled without manually hacking the site-packages > directory. What harm does it do? Rob, It's probably just me. I added the try/except in svn. Enjoy! Dominique -- Dominique |
|
From: Rob S. <rs...@MI...> - 2010-04-05 23:07:46
|
Do you know why itsolvers won't compile in new-setup-py? Here's the output again: building 'pysparse.itsolvers.itsolvers' extension compiling C sources C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 creating build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers creating build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src compile options: '-DNO_ATLAS_INFO=3 -Ipysparse/itsolvers/src -I/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/core/include -Iinclude -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c' extra options: '-faltivec -I/System/Library/Frameworks/vecLib.framework/Headers' gcc: pysparse/itsolvers/src/qmrs.c gcc: pysparse/itsolvers/src/bicgstab.c gcc: pysparse/itsolvers/src/gmres.c gcc: pysparse/itsolvers/src/pcg.c gcc: pysparse/itsolvers/src/cgs.c gcc: pysparse/itsolvers/src/minres.c gcc: pysparse/itsolvers/src/itsolversmodule.c gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/itsolversmodule.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/bicgstab.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/cgs.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/gmres.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/minres.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/pcg.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/qmrs.o -o pysparse/itsolvers/itsolvers.so -Wl,-framework -Wl,Accelerate ld: duplicate symbol _itsolvers_spmatrix in build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/bicgstab.old :and duplicatebuild /symboltemp.macosx -_itsolvers_spmatrix10.3- fatin- build2.6//temp.macosxpysparse-/10.3itsolvers-/fatsrc-2.6//itsolversmodule.o pysparse/foritsolvers architecture /ppc src/bicgstab.o and build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/itsolversmodule.o for architecture i386 collect2: ld returned 1 exit status collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/SZ/SZiYTR1fGoeIwworxM8sgU+++TI/-Tmp-//ccXGMs4h.out (No such file or directory) ld: duplicate symbol _itsolvers_spmatrix in build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/bicgstab.old :and duplicatebuild /symboltemp.macosx -_itsolvers_spmatrix10.3- fatin- build2.6//temp.macosxpysparse-/10.3itsolvers-/fatsrc-2.6//itsolversmodule.o pysparse/foritsolvers architecture /ppc src/bicgstab.o and build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/itsolversmodule.o for architecture i386 collect2: ld returned 1 exit status collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/SZ/SZiYTR1fGoeIwworxM8sgU+++TI/-Tmp-//ccXGMs4h.out (No such file or directory) error: Command "gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/itsolversmodule.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/bicgstab.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/cgs.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/gmres.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/minres.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/pcg.o build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/qmrs.o -o pysparse/itsolvers/itsolvers.so -Wl,-framework -Wl,Accelerate" failed with exit status 1 -- Rob |
|
From: Rob S. <rs...@MI...> - 2010-04-05 23:33:36
|
It seems that it has something to do with the symbol hackery that defines SPMATRIX_UNIQUE_SYMBOL in a whole bunch of different places. Apparently numpy.distutils isn't handling this the way you expect. If I define NO_IMPORT_SPMATRIX, it compiles. -- Rob On Mon, Apr 5, 2010 at 7:07 PM, Rob Speer <rs...@mi...> wrote: > Do you know why itsolvers won't compile in new-setup-py? Here's the > output again: > > > building 'pysparse.itsolvers.itsolvers' extension > > compiling C sources > > C compiler: gcc -arch ppc -arch i386 -isysroot > /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common > -dynamic -DNDEBUG -g -O3 > > > > creating build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers > > creating build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src > > compile options: '-DNO_ATLAS_INFO=3 -Ipysparse/itsolvers/src > -I/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/core/include > -I/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/core/include > -Iinclude -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 > -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 > -c' > > extra options: '-faltivec -I/System/Library/Frameworks/vecLib.framework/Headers' > > gcc: pysparse/itsolvers/src/qmrs.c > > gcc: pysparse/itsolvers/src/bicgstab.c > > gcc: pysparse/itsolvers/src/gmres.c > > gcc: pysparse/itsolvers/src/pcg.c > > gcc: pysparse/itsolvers/src/cgs.c > > gcc: pysparse/itsolvers/src/minres.c > > gcc: pysparse/itsolvers/src/itsolversmodule.c > > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g > -bundle -undefined dynamic_lookup > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/itsolversmodule.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/bicgstab.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/cgs.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/gmres.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/minres.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/pcg.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/qmrs.o -o > pysparse/itsolvers/itsolvers.so -Wl,-framework -Wl,Accelerate > > ld: duplicate symbol _itsolvers_spmatrix in > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/bicgstab.old > :and duplicatebuild /symboltemp.macosx -_itsolvers_spmatrix10.3- > fatin- build2.6//temp.macosxpysparse-/10.3itsolvers-/fatsrc-2.6//itsolversmodule.o > pysparse/foritsolvers architecture /ppc > > src/bicgstab.o and > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/itsolversmodule.o > for architecture i386 > > collect2: ld returned 1 exit status > > collect2: ld returned 1 exit status > > lipo: can't open input file: > /var/folders/SZ/SZiYTR1fGoeIwworxM8sgU+++TI/-Tmp-//ccXGMs4h.out (No > such file or directory) > > ld: duplicate symbol _itsolvers_spmatrix in > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/bicgstab.old > :and duplicatebuild /symboltemp.macosx -_itsolvers_spmatrix10.3- > fatin- build2.6//temp.macosxpysparse-/10.3itsolvers-/fatsrc-2.6//itsolversmodule.o > pysparse/foritsolvers architecture /ppc > > src/bicgstab.o and > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/itsolversmodule.o > for architecture i386 > > collect2: ld returned 1 exit status > > collect2: ld returned 1 exit status > > lipo: can't open input file: > /var/folders/SZ/SZiYTR1fGoeIwworxM8sgU+++TI/-Tmp-//ccXGMs4h.out (No > such file or directory) > > error: Command "gcc -arch ppc -arch i386 -isysroot > /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/itsolversmodule.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/bicgstab.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/cgs.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/gmres.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/minres.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/pcg.o > build/temp.macosx-10.3-fat-2.6/pysparse/itsolvers/src/qmrs.o -o > pysparse/itsolvers/itsolvers.so -Wl,-framework -Wl,Accelerate" failed > with exit status 1 > > -- Rob > |
|
From: Dominique O. <dom...@gm...> - 2010-04-07 07:00:13
|
On Tue, Apr 6, 2010 at 12:23 AM, Rob Speer <rs...@mi...> wrote: > It seems that it has something to do with the symbol hackery that > defines SPMATRIX_UNIQUE_SYMBOL in a whole bunch of different places. > Apparently numpy.distutils isn't handling this the way you expect. > > If I define NO_IMPORT_SPMATRIX, it compiles. This is odd. It compiles without problems for me on Mac Intel but again I notice that my gcc flags are quite different from yours: C compiler: gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Are you using the default /usr/bin/gcc? -- Dominique |
|
From: Rob S. <rs...@MI...> - 2010-04-08 08:50:37
|
On Wed, Apr 7, 2010 at 3:00 AM, Dominique Orban <dom...@gm...> wrote: > On Tue, Apr 6, 2010 at 12:23 AM, Rob Speer <rs...@mi...> wrote: >> It seems that it has something to do with the symbol hackery that >> defines SPMATRIX_UNIQUE_SYMBOL in a whole bunch of different places. >> Apparently numpy.distutils isn't handling this the way you expect. >> >> If I define NO_IMPORT_SPMATRIX, it compiles. > > This is odd. It compiles without problems for me on Mac Intel but > again I notice that my gcc flags are quite different from yours: > > C compiler: gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall > -Wstrict-prototypes > > Are you using the default /usr/bin/gcc? The one that comes from Xcode, yes. The -fno-strict-aliasing option sounds relevant. Where are these options set, anyway? -- Rob |
|
From: Dominique O. <dom...@gm...> - 2010-04-08 09:04:52
|
On Thu, Apr 8, 2010 at 9:50 AM, Rob Speer <rs...@mi...> wrote: > On Wed, Apr 7, 2010 at 3:00 AM, Dominique Orban > <dom...@gm...> wrote: >> On Tue, Apr 6, 2010 at 12:23 AM, Rob Speer <rs...@mi...> wrote: >>> It seems that it has something to do with the symbol hackery that >>> defines SPMATRIX_UNIQUE_SYMBOL in a whole bunch of different places. >>> Apparently numpy.distutils isn't handling this the way you expect. >>> >>> If I define NO_IMPORT_SPMATRIX, it compiles. >> >> This is odd. It compiles without problems for me on Mac Intel but >> again I notice that my gcc flags are quite different from yours: >> >> C compiler: gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall >> -Wstrict-prototypes >> >> Are you using the default /usr/bin/gcc? > > The one that comes from Xcode, yes. > > The -fno-strict-aliasing option sounds relevant. Where are these > options set, anyway? You can set compiler options by setting the CFLAGS variable, e.g. : % CFLAGS='-O0' python setup.py build See http://docs.python.org/install/#building-extensions-tips-and-tricks I'm using the gcc from http://hpc.sf.net which seems to be setting those options automatically. -- Dominique |
|
From: Rob S. <rs...@MI...> - 2010-04-08 23:38:13
Attachments:
fix_unique_symbol.patch
|
> You can set compiler options by setting the CFLAGS variable, e.g. : > > % CFLAGS='-O0' python setup.py build > > See http://docs.python.org/install/#building-extensions-tips-and-tricks > > I'm using the gcc from http://hpc.sf.net which seems to be setting > those options automatically. Well, I couldn't fix it with the compiler options. I don't know why hpc's and Apple's compilers are so different here, but they apparently are. But I could fix it by googling for recommendations on how to avoid duplicate symbol errors, which basically involves defining the thing shared between a bunch of modules (in this case, "SPMATRIX_UNIQUE_SYMBOL") as extern in the .h file, and defining it for real in one of the .c files. I might have broken something else by doing this, but it now installs out of the box and passes the tests I need it for. I'm attaching this as a very short patch file. -- Rob |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X