From owner-freebsd-ports@FreeBSD.ORG Thu Nov 11 11:59:44 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2AAC16A4CE for ; Thu, 11 Nov 2004 11:59:43 +0000 (GMT) Received: from grummit.biaix.org (86.Red-213-97-212.pooles.rima-tde.net [213.97.212.86]) by mx1.FreeBSD.org (Postfix) with SMTP id 46F9E43D46 for ; Thu, 11 Nov 2004 11:59:42 +0000 (GMT) (envelope-from lists-freebsd@biaix.org) Received: (qmail 51125 invoked by uid 1000); 11 Nov 2004 11:57:08 -0000 Date: Thu, 11 Nov 2004 12:57:08 +0100 From: Joan Picanyol To: freebsd-ports@freebsd.org, chuckr@freebsd.org Message-ID: <20041111115708.GA40447@grummit.biaix.org> Mail-Followup-To: freebsd-ports@freebsd.org, chuckr@freebsd.org, lists-freebsd@biaix.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: octave and threading libraries on SMP X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 11:59:44 -0000 Hi, I'm trying to get octave to use both my CPUs, so far to no avail. Octave insists on linking to the non_threaded libraries: joan@calvin:~(0)$ ldd /usr/local/bin/octave-2.1.57 /usr/local/bin/octave-2.1.57: liboctinterp.so => not found (0x0) liboctave.so => not found (0x0) libcruft.so => not found (0x0) libalapack.so.1 => /usr/local/lib/libalapack.so.1 (0x28085000) libcblas.so.1 => /usr/local/lib/libcblas.so.1 (0x28488000) libf77blas.so.1 => /usr/local/lib/libf77blas.so.1 (0x284b2000) libatlas.so.1 => /usr/local/lib/libatlas.so.1 (0x284d1000) libreadline.so.5 => /lib/libreadline.so.5 (0x28de1000) libncurses.so.5 => /lib/libncurses.so.5 (0x28e10000) libg2c.so.1 => /usr/lib/libg2c.so.1 (0x28e52000) libm.so.3 => /lib/libm.so.3 (0x28e70000) libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x28e8a000) libc.so.5 => /lib/libc.so.5 (0x28f67000) even though the threaded versions are there: joan@calvin:~(0)$ ls /usr/local/lib/lib{cblas,alapack,atlas,f77blas}_r* /usr/local/lib/libalapack_r.a /usr/local/lib/libcblas_r.a /usr/local/lib/libalapack_r.so /usr/local/lib/libcblas_r.so /usr/local/lib/libalapack_r.so.1 /usr/local/lib/libcblas_r.so.1 /usr/local/lib/libatlas_r.a /usr/local/lib/libf77blas_r.a /usr/local/lib/libatlas_r.so /usr/local/lib/libf77blas_r.so /usr/local/lib/libatlas_r.so.1 /usr/local/lib/libf77blas_r.so.1 Not even changing the ${BLAS_LIBS} in the Makefile to the *_r variants seems to have any effect: Installation prefix: /usr/local C compiler: cc -mieee-fp -Wall -W -Wshadow -O -pipe -march=athlon- mp -I/usr/local/include C++ compiler: c++ -mieee-fp -Wall -W -Wshadow -O -pipe -march=athlon -mp Fortran compiler: f77 -O Fortran libraries: -L/usr/local/lib -L/usr/lib -lg2c -lm BLAS libraries: -lalapack_r -lcblas -lf77blas -latlas FFTW libraries: HDF5 libraries: MPI libraries: LIBS: -lreadline -lncurses -lm Default pager: less gnuplot: gnuplot Do internal array bounds checking: false Build static libraries: true Build shared libraries: true Dynamic Linking: true (dlopen) Include support for GNU readline: true Watching top during simulations shows that only one CPU is being used, which is quite fustrating. Any hints on how to get it to use both CPUs? tks -- pica