math/py-numpy vs. math/atlas-devel
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
math/py-numpy vs. math/atlas-devel
by Scott Bennett-2
::
Rate this Message:
I would like to install science/gnudatalanguage but have been running
into various obstacles. Lars Engels very kindly just fixed one of them (devel/lasi) (Thanks, Lars!), so now I'm on to the next one, which may not be a showstopper, but it's at least a nuisance. One of the gnudatalanguage dependencies is math/py-numpy, which, in turn, depends upon math/atlas. However, I have math/atlas-devel installed and do not wish to revert to an older, slower version of the ATLAS library. Adding a "-x atlas-\*" onto the portmaster command to build math/py-numpy fails to prevent portmaster from trying to build math/atlas. Creating a /var/db/pkg/atlas-3.8.3_1,1/+IGNOREME file in addition doesn't help. How can I force math/py-numpy to accept the already installed math/atlas-devel libraries? Thanks in advance for any help! Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** _______________________________________________ freebsd-questions@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@..." |
|
|
|
|
|
Re: math/py-numpy vs. math/atlas-devel
by Doug Barton
::
Rate this Message:
First, sorry I missed the original problem report, I'm not subscribed
to -questions. Usually ports questions (including those about tools) are handled on freebsd-ports@..., but OTOH if you're not sure where to send a question it's always better to start on the -questions list. :) Second, thanks to b.f. for the very thorough analysis of the problem. I will respond and trim a bit as I go. Third, I've cc'ed maho@ since the genesis of the problem is that math/atlas and math/atlas-devel aren't setting CONFLICTS when apparently they should be. maho, if you need any help with this let me know. b. f. wrote: > Scott Bennett wrote: >> I would like to install science/gnudatalanguage but have been running >> into various obstacles. Lars Engels very kindly just fixed one of them >> (devel/lasi) (Thanks, Lars!), so now I'm on to the next one, which may not >> be a showstopper, but it's at least a nuisance. One of the gnudatalanguage >> dependencies is math/py-numpy, which, in turn, depends upon math/atlas. >> However, I have math/atlas-devel installed and do not wish to revert to an >> older, slower version of the ATLAS library. Adding a "-x atlas-\*" onto >> the portmaster command to build math/py-numpy fails to prevent portmaster >>from trying to build math/atlas. As was pointed out, that definitely won't work. With the glob patterns for exclusions, or specifying ports on the command line you want to be as conservative as possible. Also, it's not necessary to include a * at the end, portmaster will handle that for you. >> Creating a >> /var/db/pkg/atlas-3.8.3_1,1/+IGNOREME file in addition doesn't help. +IGNOREME files are only relevant to installed ports. >> How >> can I force math/py-numpy to accept the already installed math/atlas-devel >> libraries? >> Thanks in advance for any help! The easiest way for you to accomplish this would have been to use '-x atlas', the second-easiest would have been to use the -i command line option. See the man page for more information on that. > Congratulations, you've managed to defeat three sets of safeguards in > portmaster. > > Problem #1 > > math/atlas and math/atlas-devel don't have proper CONFLICTS entries in > their Makefiles (this should be fixed), Yes, this analysis was essentially correct. > Problem #2: > > You're using the -x flag incorrectly. Or portmaster isn't > implementing it properly when the port to be excluded is not actually > installed, take your pick. The way that -x is implemented currently really depends on the user's definition of the exclude pattern, and is designed to exclude things as early as possible so as to avoid what would ultimately become wasted effort. It's hard to justify modifying the code to guess that something we've already started working on might match what we think the user MEANT instead of what they SAID. > Problem #3: > > The +IGNOREME checks in portmaster aren't properly implemented for > this case, so they fail to prevent math/atlas from being built. s/properly implemented for/designed to handle/ If you think about this for a second, the entries in /var/db/pkg are exclusively related to installed ports, so trying to use an +IGNOREME file for this purpose doesn't make sense, although I can sympathize with the OPs sense of desperation here. :) > So what can you do while these problems are being fixed? Just to be clear, I didn't see anything that needs to be fixed in your message, and I hope my explanation makes it clear why. If you think that there are actual bugs that need to be fixed please feel free to create a thread on -ports to discuss them. hope this helps, Doug PS, Can't resist ... http://dougbarton.us/portmaster-proposal.html -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ freebsd-questions@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@..." |
|
|
Re: math/py-numpy vs. math/atlas-devel
by b. f.-2
::
Rate this Message:
On 11/9/09, Doug Barton <dougb@...> wrote:
> First, sorry I missed the original problem report, I'm not subscribed > to -questions. Usually ports questions (including those about tools) > are handled on freebsd-ports@..., but OTOH if you're not sure > where to send a question it's always better to start on the -questions > list. :) > > Second, thanks to b.f. for the very thorough analysis of the problem. > I will respond and trim a bit as I go. > > Third, I've cc'ed maho@ since the genesis of the problem is that > math/atlas and math/atlas-devel aren't setting CONFLICTS when > apparently they should be. maho, if you need any help with this let me > know. > > b. f. wrote: >> Scott Bennett wrote: >>> I would like to install science/gnudatalanguage but have been running >>> into various obstacles. Lars Engels very kindly just fixed one of them >>> (devel/lasi) (Thanks, Lars!), so now I'm on to the next one, which may >>> not >>> be a showstopper, but it's at least a nuisance. One of the >>> gnudatalanguage >>> dependencies is math/py-numpy, which, in turn, depends upon math/atlas. >>> However, I have math/atlas-devel installed and do not wish to revert to >>> an >>> older, slower version of the ATLAS library. Adding a "-x atlas-\*" onto >>> the portmaster command to build math/py-numpy fails to prevent portmaster >>>from trying to build math/atlas. > > As was pointed out, that definitely won't work. With the glob patterns > for exclusions, or specifying ports on the command line you want to be > as conservative as possible. Also, it's not necessary to include a * > at the end, portmaster will handle that for you. > >>> Creating a >>> /var/db/pkg/atlas-3.8.3_1,1/+IGNOREME file in addition doesn't help. > > +IGNOREME files are only relevant to installed ports. > >>> How >>> can I force math/py-numpy to accept the already installed >>> math/atlas-devel >>> libraries? >>> Thanks in advance for any help! > > The easiest way for you to accomplish this would have been to use '-x > atlas', the second-easiest would have been to use the -i command line > option. See the man page for more information on that. > >> Congratulations, you've managed to defeat three sets of safeguards in >> portmaster. >> >> Problem #1 >> >> math/atlas and math/atlas-devel don't have proper CONFLICTS entries in >> their Makefiles (this should be fixed), > > Yes, this analysis was essentially correct. > >> Problem #2: >> >> You're using the -x flag incorrectly. Or portmaster isn't >> implementing it properly when the port to be excluded is not actually >> installed, take your pick. > > The way that -x is implemented currently really depends on the user's > definition of the exclude pattern, and is designed to exclude things > as early as possible so as to avoid what would ultimately become > wasted effort. It's hard to justify modifying the code to guess that > something we've already started working on might match what we think > the user MEANT instead of what they SAID. > >> Problem #3: >> >> The +IGNOREME checks in portmaster aren't properly implemented for >> this case, so they fail to prevent math/atlas from being built. > > s/properly implemented for/designed to handle/ > > If you think about this for a second, the entries in /var/db/pkg are > exclusively related to installed ports, so trying to use an +IGNOREME > file for this purpose doesn't make sense, although I can sympathize > with the OPs sense of desperation here. :) > >> So what can you do while these problems are being fixed? > > Just to be clear, I didn't see anything that needs to be fixed in your > message, and I hope my explanation makes it clear why. If you think > that there are actual bugs that need to be fixed please feel free to > create a thread on -ports to discuss them. > The CONFLICTS for math/atlas* should be fixed, as you remarked. As for portmaster, I'll allow that your choices were reasonable, but it would be wise to note in the manpage that: 1) +IGNOREME files only work with installed ports (just because the package database is naturally associated with installed ports doesn't mean that someone won't create an +IGNOREME for one that isn't installed), and 2) when trying to prevent the build or installation of a port that is not currently installed, the exclusion glob will be compared with the port directory, rather than the PKGNAME, as is done for installed packages. Using something like: #!/bin/sh for _dir in `make -C /usr/ports -V SUBDIR` ; do for _dir2 in `make -C /usr/ports/${_dir} -V SUBDIR` ; do _pkgname=`make -C /usr/ports/${_dir}/${_dir2} -V PKGNAME` case "${_dir}/${_dir2}" in *${_pkgname%%-[0-9]*}*) ;; *) echo "${_dir}/${_dir2} ${_pkgname}" ;; esac ; done ; done one can find a number of ports that might surprise a user that was not aware of this fact. And with regard to the selection of exclusion globs, we should note that a glob that matches too many ports may be as problematic as one that matches too few. b. _______________________________________________ freebsd-questions@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@..." |
|
|
|
|
|
Re: math/py-numpy vs. math/atlas-devel
by Doug Barton
::
Rate this Message:
b. f. wrote:
> 1) +IGNOREME files only work with installed ports (just because the > package database is naturally associated with installed ports doesn't > mean that someone won't create an +IGNOREME for one that isn't > installed), and > 2) when trying to prevent the build or installation of a port that is > not currently installed, the exclusion glob will be compared with the > port directory, rather than the PKGNAME, as is done for installed > packages. I've updated my working copy of the man page with these suggestions, thanks! > And with regard to the selection of exclusion > globs, we should note that a glob that matches too many ports may be > as problematic as one that matches too few. But, of course. :) Regexp creation is both one of the rites of passage for all system administrators and a never-ending journey. If the -x or other glob option is not suitable there are always other options. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ freebsd-questions@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@..." |
|
|
Re: math/py-numpy vs. math/atlas-devel
by b. f.-2
::
Rate this Message:
On 11/9/09, Scott Bennett <bennett@...> wrote:
> On Sun, 08 Nov 2009 23:59:29 -0800 Doug Barton <dougb@...> > wrote: ... > Anyway, the math/py-numpy port now proceeds to build without bothering > with math/atlas. It quickly goes astray when it doesn't recognize that any > of gfortran4[345] has been installed--I guess there no longer is a FORTRAN > compiler included in the base system--and instead tries to use lang/g95, > which has also been installed. Of course, this won't work because the ATLAS > library needs to have been compiled with the same compiler as the programs > that use it. > > ===> Configuring for py26-numpy-1.3.0_2,1 > Running from numpy source directory. > [39mF2PY Version 2 [0m > [39mblas_opt_info: [0m > [39mblas_mkl_info: [0m > [39m libraries mkl,vml,guide not found in /usr/lib [0m > [39m libraries mkl,vml,guide not found in /usr/local/lib [0m > [39m libraries mkl,vml,guide not found in > /usr/local/lib/gcc44/gcc/i386-portbld-freebsd7.2/4.4.3/../../../ [0m > [39m NOT AVAILABLE [0m > [39m [0m > [39matlas_blas_threads_info: [0m > [39mSetting PTATLAS=ATLAS [0m > [39mSetting PTATLAS=ATLAS [0m > [39mSetting PTATLAS=ATLAS [0m > [39m FOUND: [0m > [39m libraries = ['alapack_r', 'f77blas_r', 'cblas_r', 'atlas_r'] [0m > [39m library_dirs = ['/usr/local/lib'] [0m > [39m language = c [0m > [39m include_dirs = ['/usr/local/include'] [0m > [39m [0m > /usr/ports/math/py-numpy/work/numpy-1.3.0/numpy/distutils/command/config.py:361: > DeprecationWarning: > +++++++++++++++++++++++++++++++++++++++++++++++++ > Usage of get_output is deprecated: please do not > use it anymore, and avoid configuration checks > involving running executable on the target machine. > +++++++++++++++++++++++++++++++++++++++++++++++++ > > DeprecationWarning) > [39mcustomize GnuFCompiler [0m > [32mFound executable /usr/local/bin/gfortran44 [0m > [31mgnu: no Fortran 90 compiler found [0m > [31mgnu: no Fortran 90 compiler found [0m > [39mcustomize Gnu95FCompiler [0m > [39mcustomize Gnu95FCompiler [0m > [39mcustomize Gnu95FCompiler using config [0m > compiling '_configtest.c': > > /* This file is generated from numpy/distutils/system_info.py */ > void ATL_buildinfo(void); > int main(void) { > ATL_buildinfo(); > return 0; > } > [39mC compiler: gcc44 -DNDEBUG -O2 -fno-strict-aliasing -pipe > -march=prescott -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x100000 -O2 > -fno-strict-aliasing -pipe -march=prescott -Wl,-rpath=/usr/local/lib/gcc44 > -fPIC > [0m > [39mcompile options: '-c' [0m > [39mgcc44: _configtest.c [0m > [39mgcc44 _configtest.o -L/usr/local/lib -lalapack_r -lf77blas_r -lcblas_r > -latlas_r -o _configtest [0m > /usr/bin/ld: _configtest: hidden symbol `__powisf2' in > /usr/local/lib/gcc44/gcc/i386-portbld-freebsd7.2/4.4.3/libgcc.a(_powisf2.o) > is referenced by DSO > collect2: ld returned 1 exit status > /usr/bin/ld: _configtest: hidden symbol `__powisf2' in > /usr/local/lib/gcc44/gcc/i386-portbld-freebsd7.2/4.4.3/libgcc.a(_powisf2.o) > is referenced by DSO > collect2: ld returned 1 exit status > [39mfailure. [0m > [39mremoving: _configtest.c _configtest.o [0m > [39mStatus: 255 [0m > [39mOutput: [0m > [39m FOUND: [0m > [39m libraries = ['alapack_r', 'f77blas_r', 'cblas_r', 'atlas_r'] [0m > [39m library_dirs = ['/usr/local/lib'] [0m > [39m language = c [0m > [39m define_macros = [('NO_ATLAS_INFO', 2)] [0m > [39m include_dirs = ['/usr/local/include'] [0m > [39m [0m > [39mlapack_opt_info: [0m > [39mlapack_mkl_info: [0m > [39mmkl_info: [0m > [39m libraries mkl,vml,guide not found in /usr/lib [0m > [39m libraries mkl,vml,guide not found in /usr/local/lib [0m > [39m libraries mkl,vml,guide not found in > /usr/local/lib/gcc44/gcc/i386-portbld-freebsd7.2/4.4.3/../../../ [0m > [39m NOT AVAILABLE [0m > [39m [0m > [39m NOT AVAILABLE [0m > [39m [0m > [39matlas_threads_info: [0m > [39mSetting PTATLAS=ATLAS [0m > [39m libraries lapack_atlas not found in /usr/local/lib [0m > [39mnumpy.distutils.system_info.atlas_threads_info [0m > [39mSetting PTATLAS=ATLAS [0m > /usr/ports/math/py-numpy/work/numpy-1.3.0/numpy/distutils/system_info.py:999: > UserWarning: > ********************************************************************* > Lapack library (from ATLAS) is probably incomplete: > size of /usr/local/lib/libalapack_r.so is 3832k (expected >4000k) > > Follow the instructions in the KNOWN PROBLEMS section of the file > numpy/INSTALL.txt. > ********************************************************************* > > warnings.warn(message) > > > The above sequence gets more or less repeated several more times, and > after much compiling, running of python26, and other activities, the > process runs aground as follows. > > > [39mcreating build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/fft [0m > [39mcompile options: '-Inumpy/core/include > -Ibuild/src.freebsd-7.2-STABLE-i386-2.6/numpy/core/include/numpy > -Inumpy/core/src -Inumpy/core/include -I/usr/local/include/python2.6 -c' [0m > [39mgcc44: numpy/fft/fftpack_litemodule.c [0m > [39mgcc44: numpy/fft/fftpack.c [0m > [39mcc -shared -pthread -O2 -fno-strict-aliasing -pipe -march=prescott > -Wl,-rpath=/usr/local/lib/gcc44 > build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/fft/fftpack_litemodule.o > build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/fft/fftpack.o > -Lbuild/temp.freebsd-7.2-STABLE-i386-2.6 -o > build/lib.freebsd-7.2-STABLE-i386-2.6/numpy/fft/fftpack_lite.so [0m > [39mbuilding 'numpy.linalg.lapack_lite' extension [0m > [39mcompiling C sources [0m > [39mC compiler: gcc44 -DNDEBUG -O2 -fno-strict-aliasing -pipe > -march=prescott -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x100000 -O2 > -fno-strict-aliasing -pipe -march=prescott -Wl,-rpath=/usr/local/lib/gcc44 > -fPIC > [0m > [39mcreating build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/linalg [0m > [39mcompile options: '-DATLAS_INFO="\"3.9.11\"" -I/usr/local/include > -Inumpy/core/include > -Ibuild/src.freebsd-7.2-STABLE-i386-2.6/numpy/core/include/numpy > -Inumpy/core/src -Inumpy/core/include -I/usr/local/include/python2.6 -c' [0m > [39mgcc44: numpy/linalg/lapack_litemodule.c [0m > [39mgcc44: numpy/linalg/python_xerbla.c [0m > [39mcc -shared -pthread -O2 -fno-strict-aliasing -pipe -march=prescott > -Wl,-rpath=/usr/local/lib/gcc44 > build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/lapack_litemodule.o > build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/python_xerbla.o > -L/usr/local/lib -Lbuild/temp.freebsd-7.2-STABLE-i386-2.6 -lalapack_r > -lalapack_r -lf77blas_r -lcblas_r -latlas_r -lgfortran -lm -lpthread -o > build/lib.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/lapack_lite.so [0m > /usr/bin/ld: cannot find -lgfortran > /usr/bin/ld: cannot find -lgfortran > error: Command "cc -shared -pthread -O2 -fno-strict-aliasing -pipe > -march=prescott -Wl,-rpath=/usr/local/lib/gcc44 > build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/lapack_litemodule.o > build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/python_xerbla.o > -L/usr/local/lib -Lbuild/temp.freebsd-7.2-STABLE-i386-2.6 -lalapack_r > -lalapack_r -lf77blas_r -lcblas_r -latlas_r -lgfortran -lm -lpthread -o > build/lib.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/lapack_lite.so" failed > with exit status 1 > *** Error code 1 > > Stop in /usr/ports/math/py-numpy. > > ===>>> make failed for math/py-numpy > ===>>> Aborting update > > I looked in /usr/local/lib and didn't spot libraries by name for > gfortran[345], so I assume they have either been renamed or included in > with the corresponding gcc libraries. What is the best way to proceed? > Will simply deleting the instances of "-lgfortran" do the job? Or do I > need to specify the library explicitly? > The port is broken WITH_ATLAS=yes on your system: it reverts to using the base system C compiler, cc, when it should be using gcc44. You trimmed off some relevant parts, so it is difficult to tell at a glance whether this is because something is wrong with your system, or with the port itself, although the port has a history of problems with this non-default option. If I have some time later, I may play with it, but at the moment, I don't have atlas installed. You should send a full build transcript to me and the math/py-numpy maintainer via private email. The libraries in question should be in /usr/local/lib/gcc44. When searching for registered shared libraries, it is easier to do something like: ldconfig -vr | grep -ie fortran and for static libraries or unregistered shared libraries, locate(1) and find(1) are your friends. b. _______________________________________________ freebsd-questions@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@..." |
|
|
|
|
|
Re: math/py-numpy vs. math/atlas-devel
by Maho NAKATA
::
Rate this Message:
Hi all,
I'm willing to apply patches to atlas ports if available. I talked with Goto Kazushige (author of GotoBLAS), he told me that L2 cache handling on FreeBSD is very bad. It may be a reason why ATLAS build is so fragile. On Linux machines, it takes only 20 min or so. Thanks for good discussions! Best, Nakata Maho From: Scott Bennett <bennett@...> Subject: Re: math/py-numpy vs. math/atlas-devel Date: Mon, 09 Nov 2009 15:07:55 -0600 (CST) > On Mon, 9 Nov 2009 20:26:15 +0000 "b. f." <bf1783@...> > wrote: >>On 11/9/09, Scott Bennett <bennett@...> wrote: >>> On Sun, 08 Nov 2009 23:59:29 -0800 Doug Barton <dougb@...> >>> wrote: >> >>... >> >>> Anyway, the math/py-numpy port now proceeds to build without bothering >>> with math/atlas. It quickly goes astray when it doesn't recognize that any >>> of gfortran4[345] has been installed--I guess there no longer is a FORTRAN >>> compiler included in the base system--and instead tries to use lang/g95, >>> which has also been installed. Of course, this won't work because the ATLAS >>> library needs to have been compiled with the same compiler as the programs >>> that use it. >>> >>> ===> Configuring for py26-numpy-1.3.0_2,1 >>> Running from numpy source directory. >>> [39mF2PY Version 2 [0m >>> [39mblas_opt_info: [0m >>> [39mblas_mkl_info: [0m >>> [39m libraries mkl,vml,guide not found in /usr/lib [0m >>> [39m libraries mkl,vml,guide not found in /usr/local/lib [0m >>> [39m libraries mkl,vml,guide not found in >>> /usr/local/lib/gcc44/gcc/i386-portbld-freebsd7.2/4.4.3/../../../ [0m >>> [39m NOT AVAILABLE [0m >>> [39m [0m >>> [39matlas_blas_threads_info: [0m >>> [39mSetting PTATLAS=ATLAS [0m >>> [39mSetting PTATLAS=ATLAS [0m >>> [39mSetting PTATLAS=ATLAS [0m >>> [39m FOUND: [0m >>> [39m libraries = ['alapack_r', 'f77blas_r', 'cblas_r', 'atlas_r'] [0m >>> [39m library_dirs = ['/usr/local/lib'] [0m >>> [39m language = c [0m >>> [39m include_dirs = ['/usr/local/include'] [0m >>> [39m [0m >>> /usr/ports/math/py-numpy/work/numpy-1.3.0/numpy/distutils/command/config.py:361: >>> DeprecationWarning: >>> +++++++++++++++++++++++++++++++++++++++++++++++++ >>> Usage of get_output is deprecated: please do not >>> use it anymore, and avoid configuration checks >>> involving running executable on the target machine. >>> +++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> DeprecationWarning) >>> [39mcustomize GnuFCompiler [0m >>> [32mFound executable /usr/local/bin/gfortran44 [0m >>> [31mgnu: no Fortran 90 compiler found [0m >>> [31mgnu: no Fortran 90 compiler found [0m >>> [39mcustomize Gnu95FCompiler [0m >>> [39mcustomize Gnu95FCompiler [0m >>> [39mcustomize Gnu95FCompiler using config [0m >>> compiling '_configtest.c': >>> >>> /* This file is generated from numpy/distutils/system_info.py */ >>> void ATL_buildinfo(void); >>> int main(void) { >>> ATL_buildinfo(); >>> return 0; >>> } >>> [39mC compiler: gcc44 -DNDEBUG -O2 -fno-strict-aliasing -pipe >>> -march=prescott -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x100000 -O2 >>> -fno-strict-aliasing -pipe -march=prescott -Wl,-rpath=/usr/local/lib/gcc44 >>> -fPIC >>> [0m >>> [39mcompile options: '-c' [0m >>> [39mgcc44: _configtest.c [0m >>> [39mgcc44 _configtest.o -L/usr/local/lib -lalapack_r -lf77blas_r -lcblas_r >>> -latlas_r -o _configtest [0m >>> /usr/bin/ld: _configtest: hidden symbol `__powisf2' in >>> /usr/local/lib/gcc44/gcc/i386-portbld-freebsd7.2/4.4.3/libgcc.a(_powisf2.o) >>> is referenced by DSO >>> collect2: ld returned 1 exit status >>> /usr/bin/ld: _configtest: hidden symbol `__powisf2' in >>> /usr/local/lib/gcc44/gcc/i386-portbld-freebsd7.2/4.4.3/libgcc.a(_powisf2.o) >>> is referenced by DSO >>> collect2: ld returned 1 exit status >>> [39mfailure. [0m >>> [39mremoving: _configtest.c _configtest.o [0m >>> [39mStatus: 255 [0m >>> [39mOutput: [0m >>> [39m FOUND: [0m >>> [39m libraries = ['alapack_r', 'f77blas_r', 'cblas_r', 'atlas_r'] [0m >>> [39m library_dirs = ['/usr/local/lib'] [0m >>> [39m language = c [0m >>> [39m define_macros = [('NO_ATLAS_INFO', 2)] [0m >>> [39m include_dirs = ['/usr/local/include'] [0m >>> [39m [0m >>> [39mlapack_opt_info: [0m >>> [39mlapack_mkl_info: [0m >>> [39mmkl_info: [0m >>> [39m libraries mkl,vml,guide not found in /usr/lib [0m >>> [39m libraries mkl,vml,guide not found in /usr/local/lib [0m >>> [39m libraries mkl,vml,guide not found in >>> /usr/local/lib/gcc44/gcc/i386-portbld-freebsd7.2/4.4.3/../../../ [0m >>> [39m NOT AVAILABLE [0m >>> [39m [0m >>> [39m NOT AVAILABLE [0m >>> [39m [0m >>> [39matlas_threads_info: [0m >>> [39mSetting PTATLAS=ATLAS [0m >>> [39m libraries lapack_atlas not found in /usr/local/lib [0m >>> [39mnumpy.distutils.system_info.atlas_threads_info [0m >>> [39mSetting PTATLAS=ATLAS [0m >>> /usr/ports/math/py-numpy/work/numpy-1.3.0/numpy/distutils/system_info.py:999: >>> UserWarning: >>> ********************************************************************* >>> Lapack library (from ATLAS) is probably incomplete: >>> size of /usr/local/lib/libalapack_r.so is 3832k (expected >4000k) >>> >>> Follow the instructions in the KNOWN PROBLEMS section of the file >>> numpy/INSTALL.txt. >>> ********************************************************************* >>> >>> warnings.warn(message) >>> >>> >>> The above sequence gets more or less repeated several more times, and >>> after much compiling, running of python26, and other activities, the >>> process runs aground as follows. >>> >>> >>> [39mcreating build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/fft [0m >>> [39mcompile options: '-Inumpy/core/include >>> -Ibuild/src.freebsd-7.2-STABLE-i386-2.6/numpy/core/include/numpy >>> -Inumpy/core/src -Inumpy/core/include -I/usr/local/include/python2.6 -c' [0m >>> [39mgcc44: numpy/fft/fftpack_litemodule.c [0m >>> [39mgcc44: numpy/fft/fftpack.c [0m >>> [39mcc -shared -pthread -O2 -fno-strict-aliasing -pipe -march=prescott >>> -Wl,-rpath=/usr/local/lib/gcc44 >>> build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/fft/fftpack_litemodule.o >>> build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/fft/fftpack.o >>> -Lbuild/temp.freebsd-7.2-STABLE-i386-2.6 -o >>> build/lib.freebsd-7.2-STABLE-i386-2.6/numpy/fft/fftpack_lite.so [0m >>> [39mbuilding 'numpy.linalg.lapack_lite' extension [0m >>> [39mcompiling C sources [0m >>> [39mC compiler: gcc44 -DNDEBUG -O2 -fno-strict-aliasing -pipe >>> -march=prescott -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x100000 -O2 >>> -fno-strict-aliasing -pipe -march=prescott -Wl,-rpath=/usr/local/lib/gcc44 >>> -fPIC >>> [0m >>> [39mcreating build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/linalg [0m >>> [39mcompile options: '-DATLAS_INFO="\"3.9.11\"" -I/usr/local/include >>> -Inumpy/core/include >>> -Ibuild/src.freebsd-7.2-STABLE-i386-2.6/numpy/core/include/numpy >>> -Inumpy/core/src -Inumpy/core/include -I/usr/local/include/python2.6 -c' [0m >>> [39mgcc44: numpy/linalg/lapack_litemodule.c [0m >>> [39mgcc44: numpy/linalg/python_xerbla.c [0m >>> [39mcc -shared -pthread -O2 -fno-strict-aliasing -pipe -march=prescott >>> -Wl,-rpath=/usr/local/lib/gcc44 >>> build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/lapack_litemodule.o >>> build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/python_xerbla.o >>> -L/usr/local/lib -Lbuild/temp.freebsd-7.2-STABLE-i386-2.6 -lalapack_r >>> -lalapack_r -lf77blas_r -lcblas_r -latlas_r -lgfortran -lm -lpthread -o >>> build/lib.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/lapack_lite.so [0m >>> /usr/bin/ld: cannot find -lgfortran >>> /usr/bin/ld: cannot find -lgfortran >>> error: Command "cc -shared -pthread -O2 -fno-strict-aliasing -pipe >>> -march=prescott -Wl,-rpath=/usr/local/lib/gcc44 >>> build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/lapack_litemodule.o >>> build/temp.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/python_xerbla.o >>> -L/usr/local/lib -Lbuild/temp.freebsd-7.2-STABLE-i386-2.6 -lalapack_r >>> -lalapack_r -lf77blas_r -lcblas_r -latlas_r -lgfortran -lm -lpthread -o >>> build/lib.freebsd-7.2-STABLE-i386-2.6/numpy/linalg/lapack_lite.so" failed >>> with exit status 1 >>> *** Error code 1 >>> >>> Stop in /usr/ports/math/py-numpy. >>> >>> ===>>> make failed for math/py-numpy >>> ===>>> Aborting update >>> >>> I looked in /usr/local/lib and didn't spot libraries by name for >>> gfortran[345], so I assume they have either been renamed or included in >>> with the corresponding gcc libraries. What is the best way to proceed? >>> Will simply deleting the instances of "-lgfortran" do the job? Or do I >>> need to specify the library explicitly? >>> >> >>The port is broken WITH_ATLAS=yes on your system: it reverts to using >>the base system C compiler, cc, when it should be using gcc44. You >>trimmed off some relevant parts, so it is difficult to tell at a >>glance whether this is because something is wrong with your system, or >>with the port itself, although the port has a history of problems >>with this non-default option. If I have some time later, I may play >>with it, but at the moment, I don't have atlas installed. You should > > Okay, but be advised that the ATLAS library takes around six hours > to build on a 3.4 GHz Prescott with little else active on the machine > at the time. (ATLAS should be built on a very quiet machine, so that > its timing tests will be fairly accurate. The build is likely to die > if several runs of a timing test yield a variance greater than what the > build procedure wants.) > >>send a full build transcript to me and the math/py-numpy maintainer >>via private email. > > Will do, but probably not till tonight sometime. >> >>The libraries in question should be in /usr/local/lib/gcc44. When >>searching for registered shared libraries, it is easier to do >>something like: >> >>ldconfig -vr | grep -ie fortran > > 1046:-lgfortran.3 => /usr/local/lib/gcc43/libgfortran.so.3 > 1056:-lgfortran.3 => /usr/local/lib/gcc44/libgfortran.so.3 > 1068:-lgfortran.3 => /usr/local/lib/gcc45/libgfortran.so.3 >> >>and for static libraries or unregistered shared libraries, locate(1) >>and find(1) are your friends. >> > Well, locate(1) *ought* to be, you're right. However, although it > worked fine on FreeBSD 5, I've never succeeded in getting FreeBSD 6 or 7 > to build the locate database properly. It would be nice, but I've already > spent too many hours on too many occasions trying to track down the trouble, > so I just use find(1). > find(1) turns up the following. > > /usr/local/lib/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/libgfortranbegin.la > /usr/local/lib/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/libgfortranbegin.a > /usr/local/lib/gcc43/libgfortran.so.3 > /usr/local/lib/gcc43/libgfortran.so > /usr/local/lib/gcc43/libgfortran.a > /usr/local/lib/gcc44/gcc/i386-portbld-freebsd7.2/4.4.3/libgfortranbegin.la > /usr/local/lib/gcc44/gcc/i386-portbld-freebsd7.2/4.4.3/libgfortranbegin.a > /usr/local/lib/gcc44/libgfortran.so.3 > /usr/local/lib/gcc44/libgfortran.so > /usr/local/lib/gcc44/libgfortran.a > /usr/local/lib/gcc45/gcc/i386-portbld-freebsd7.2/4.5.0/libgfortranbegin.la > /usr/local/lib/gcc45/gcc/i386-portbld-freebsd7.2/4.5.0/libgfortranbegin.a > /usr/local/lib/gcc45/libgfortran.so.3 > /usr/local/lib/gcc45/libgfortran.so > /usr/local/lib/gcc45/libgfortran.a > > I'll get the rest of the stuff off to you later tonight. Thank you > very much for looking at all of this. I wonder if I'm the only person > trying to install science/gnudatalanguage. There have been enough > obstacles to getting that done that I have to wonder how the maintainer > managed to test it. > > > Scott Bennett, Comm. ASMELG, CFIAG > ********************************************************************** > * Internet: bennett at cs.niu.edu * > *--------------------------------------------------------------------* > * "A well regulated and disciplined militia, is at all times a good * > * objection to the introduction of that bane of all free governments * > * -- a standing army." * > * -- Gov. John Hancock, New York Journal, 28 January 1790 * > ********************************************************************** > freebsd-questions@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@..." |
| Free embeddable forum powered by Nabble | Forum Help |
