Hi, I'd be happy to hear from those have knowledge to suggest a fix. <http://trac.macosforge.org/projects/macports/ticket/11613> fftw-3-sigle does not build on my MacBook Pro. I should fix this because I am the maintainer of fftw-3 and I need this for GDL. But the error below is beyond my ability. gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -I../simd -O3 -fomit- frame-pointer -malign-double -fstrict-aliasing -ffast-math - march=pentiumpro -D_THREAD_SAFE -MT trig.lo -MD -MP -MF .deps/ trig.Tpo -c trig.c -o trig.o /var/tmp//ccMMtwDn.s:99:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:100:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:132:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:134:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:167:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:168:operands given don't match any known 386 instruction make[2]: *** [trig.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
On Mar 24, 2007, at 06:28, Takeshi Enomoto wrote:
I'd be happy to hear from those have knowledge to suggest a fix.
<http://trac.macosforge.org/projects/macports/ticket/11613>
fftw-3-sigle does not build on my MacBook Pro. I should fix this because I am the maintainer of fftw-3 and I need this for GDL. But the error below is beyond my ability.
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -I../simd -O3 -fomit- frame-pointer -malign-double -fstrict-aliasing -ffast-math - march=pentiumpro -D_THREAD_SAFE -MT trig.lo -MD -MP -MF .deps/ trig.Tpo -c trig.c -o trig.o /var/tmp//ccMMtwDn.s:99:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:100:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:132:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:134:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:167:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:168:operands given don't match any known 386 instruction make[2]: *** [trig.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
It sounds like it's trying to use PowerPC code when building on your Intel Mac? Which it shouldn't do. Someone else seems to have had this problem: http://www.arcknowledge.com/gmane.comp.audio.jamin.devel/2006-07/ msg00011.html In that message he says he got it to work, though he doesn't tell us exactly what he changed to make it work. Maybe he added -march=i386 or some such to his configure line. That seems to be the only suggestion given. What is the difference between fftw-3 and fftw-3-single? Looking at the portfiles, I'm confused. They both download the same version of the same source archive. They have the same default configure.args. fftw-3-single enables altivec instructions when building on PPC; fftw-3 does not. fftw-3-single deletes some things in post-destroot; fftw-3 does not. And fftw-3-single depends on fftw-3. This all seems very weird.
Ryan,
It sounds like it's trying to use PowerPC code when building on your Intel Mac?
Thanks for the link. I will take a look.
What is the difference between fftw-3 and fftw-3-single?
I am not the original author. Fink has only one package for fftw3. I will try to merge the two. We could name the merge package fftw3 and deprecate fftw-3 and fftw-3-single while keep them for a while. Takeshi
On Mar 24, 2007, at 19:19, Takeshi Enomoto wrote:
What is the difference between fftw-3 and fftw-3-single?
I am not the original author. Fink has only one package for fftw3.
I will try to merge the two. We could name the merge package fftw3 and deprecate fftw-3 and fftw-3-single while keep them for a while.
The difference between fftw and fftw-single may be revealing: $ diff -u math/{fftw,fftw-single}/Portfile --- math/fftw/Portfile 2006-11-04 03:41:31.000000000 -0600 +++ math/fftw-single/Portfile 2007-03-02 18:12:40.000000000 -0600 @@ -1,12 +1,12 @@ -# $Id: Portfile 20399 2006-11-03 02:12:19Z jberry@macports.org $ +# $Id: Portfile 22478 2007-03-02 05:16:40Z pipping@macports.org $ -PortSystem 1.0 -name fftw +PortSystem 1.0 +name fftw-single version 2.1.5 -revision 2 +revision 1 categories math devel maintainers nomaintainer@macports.org -description Fast C routines to compute the Discrete Fourier Transform +description Single precision version of fftw long_description \ FFTW is a C subroutine library for computing the Discrete Fourier \ Transform (DFT) in one or more dimensions, of both real and complex \ @@ -20,14 +20,21 @@ platforms darwin +distname fftw-${version} homepage http://www.fftw.org/ master_sites ${homepage} \ ftp://ftp.fftw.org/pub/fftw/ \ ftp://ftp.kusastro.kyoto-u.ac.jp/pub/src/GNU/fftw/ checksums md5 8d16a84f3ca02a785ef9eb36249ba433 -configure.args --enable-type-prefix --enable-threads \ - --disable-fortran --infodir=${prefix}/share/info + +depends_run port:fftw + +configure.args --enable-type-prefix \ + --enable-threads \ + --enable-float \ + --disable-fortran \ + --infodir=${prefix}/share/info variant fortran { depends_lib-append port:gcc34 @@ -38,3 +45,9 @@ } } +# Documentation conflicts with the double precision version, +# so delete it. The documentation is installed by the dependency +# port:fftw, above. + +post-destroot { file delete -force ${destroot}${prefix}/share } + It seems that the difference is that the -single version uses -- enable-float. Perhaps when using --enable-float, fftw installs itself under a different name? And the comment before the post-destroot phase explains why things are being deleted -- because both versions install the same documentation, which would cause a conflict otherwise. Maybe that's why fftw-single depends on fftw -- so that fftw-single will still include the documentation. Apparently there must be some reason why one would want fftw and fftw- single to be able to be installed simultaneously. If you want to try to combine these into a single port, you may want to model your new port after the recently-updated zlib port, which does in fact configure, make and install itself twice as well, with different configure arguments: http://trac.macosforge.org/projects/macports/browser/trunk/dports/ archivers/zlib/Portfile Whatever you do should probably be the same for the fftw / fftw- single and fftw-3 / fftw-3-single ports.
On Mar 24, 2007, at 17:50 , Ryan Schmidt wrote:
It seems that the difference is that the -single version uses -- enable-float.
Sounds like this is for single precisions support. I'm not sure whether it is in addition to double precision support or in lieu of double precision support. Either way, it seems like a variant would be better than two exceedingly similar Portfiles. Dave
Le 07-03-26 à 02:24, David MacMahon a écrit :
On Mar 24, 2007, at 17:50 , Ryan Schmidt wrote:
It seems that the difference is that the -single version uses -- enable-float.
Sounds like this is for single precisions support. I'm not sure whether it is in addition to double precision support or in lieu of double precision support. Either way, it seems like a variant would be better than two exceedingly similar Portfiles.
From what I recall, you have the choice of either single or double precision. Now some ports (or at least one) require single-precision fftw and dependencies can't be a specific variant. It seemed however exagerated to have single as default. Hence the creation of fftw- single. yves
Hello, Looking at the zlib example and the corresponding Fink package, I created a merged version. <http://trac.macosforge.org/projects/macports/ticket/11613> I temporarily named it fftw3, different from fftw-3 and fftw-3-single. The float libraries are a variant. This minimizes the files to be installed. (We could always use the double functions.) Maybe they should not be and built by default. This helps packages depend on fftw3. One can expect both kinds are present. We could simply append --without-gcc-arch to configure.args for the i386 platform to fix the bug but I think the packages should be merged. What do you think? <http://trac.macosforge.org/projects/macports/ticket/11613> Takeshi
On 26/03/07, Takeshi Enomoto <takeshi@mac.com> wrote: Hi
Looking at the zlib example and the corresponding Fink package, I created a merged version. <http://trac.macosforge.org/projects/macports/ticket/11613>
I temporarily named it fftw3, different from fftw-3 and fftw-3-single. The float libraries are a variant. This minimizes the files to be installed. (We could always use the double functions.)
Maybe they should not be and built by default. This helps packages depend on fftw3. One can expect both kinds are present.
This would make the most sense to me as I work on a project that requires both single and double precision FFTW and having single precision as a variant could lead to problems - can you have two different variants of the same port installed?
We could simply append --without-gcc-arch to configure.args for the i386 platform to fix the bug but I think the packages should be merged.
What do you think?
Cheers Adam
I work on a project that requires both single and double precision FFTW
Ok, let's install both double and float versions as default. I was affected by the .Mac's trouble. Sorry for slow reply. I made single version in the default. <http://trac.macosforge.org/projects/macports/ticket/11613> Takeshi
On 29/03/07, Takeshi Enomoto <takeshi@mac.com> wrote:
Ok, let's install both double and float versions as default.
Looks good. Cheers Adam
Ok, let's install both double and float versions as default.
Looks good.
Thank you for examining my submission. Should we - let fftw-3 succeed both double and float versions or - create a new fftw3 package? In either cases, - we could clean all portfiles depend on fftw-3 or fft-3-single and replace them with fftw-3 (new) or fftw3 or - we could leave them as it is and wait until the completion of transitions of all packages. I am in favour of naming it fftw3 and replace all the dependent at once portfiles in some occasion. It would be quicker if someone has commit permission did the replacement. Takeshi
participants (5)
-
Adam Mercer
-
David MacMahon
-
Ryan Schmidt
-
Takeshi Enomoto
-
Yves de Champlain