From RBenshalom at iai.co.il Tue Feb 1 09:33:17 2011 From: RBenshalom at iai.co.il (Ronit Ben Shalom) Date: Tue, 1 Feb 2011 10:33:17 +0200 Subject: Performance tests - Scilab 5.3.0 Vs Scilab 5.3.0-SSE3 Message-ID: <2B47C3F3ED55F7428D8C66B3BD7E629B09EB35@mlmxmail.malam.iai.co.il> Hi, 1. I work in Israel Aerospace Industries Ltd. I did some performance tests: Scilab 5.3.0 Vs Scilab 5.3.0-SSE3 The benchmark is set of Scilab Math core functions. It is performed on Scilab v5.3.0/5.3.0-SSE3 under Windows XP 64 bits. The processor is an Intel Core 2 Duo E7500 at 2.93 GHz. I used Intel Math Kernel Library (MKL). I would appreciate if you publish my result (attach .pdf file). Regards, Ronit Ben-Shalom *************************************************************************************** Please consider the environment before printing this email The information contained in this communication is proprietary to Israel Aerospace Industries Ltd. and/or third parties, may contain confidential or privileged information, and is intended only for the use of the intended addressee thereof. If you are not the intended addressee, please be aware that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. If you receive this communication in error, please notify the sender immediately and delete it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Performance Scilab5 3 0 Vs Scilab5 3 0-SSE3.pdf Type: application/octet-stream Size: 368178 bytes Desc: Performance Scilab5 3 0 Vs Scilab5 3 0-SSE3.pdf URL: From michael.baudin at scilab.org Tue Feb 1 16:07:53 2011 From: michael.baudin at scilab.org (=?ISO-8859-1?Q?Micha=EBl_Baudin?=) Date: Tue, 01 Feb 2011 16:07:53 +0100 Subject: [Scilab-Dev] Performance tests - Scilab 5.3.0 Vs Scilab 5.3.0-SSE3 In-Reply-To: <2B47C3F3ED55F7428D8C66B3BD7E629B09EB35@mlmxmail.malam.iai.co.il> References: <2B47C3F3ED55F7428D8C66B3BD7E629B09EB35@mlmxmail.malam.iai.co.il> Message-ID: <4D4821C9.5060802@scilab.org> Hi, These results are interesting. I updated the Tutorials page on the wiki, in the section "Comparison of scientific technical softwares", which is the "benchmark" section of this page. Obviously, the Intel MKL already brings most of the speedup for linear algebra, which leaves only a small space for other optimizations in this field. Do we agree on the conclusion that there is only a slight advantage, i.e. < 1%, on these tests for Scilab/SSE3 ? What specific processor instructions are brought by SSE3 that Scilab (actually the compiler) could may use of ? Best regards, Micha?l Le 01/02/2011 09:33, Ronit Ben Shalom a ?crit : > > Hi, > > 1. > > I work in Israel Aerospace Industries Ltd. > > I did some performance tests: Scilab 5.3.0 Vs Scilab 5.3.0-SSE3 > > The benchmark is set of Scilab Math core functions. > It is performed on Scilab v5.3.0/5.3.0-SSE3 under Windows XP 64 bits. > The processor is an Intel Core 2 Duo E7500 at 2.93 GHz. > > I used Intel Math Kernel Library (MKL). > > I would appreciate if you publish my result (attach .pdf file). > > Regards, > Ronit Ben-Shalom > > *************************************************************************************** > *Please consider the environment before printing this email* > The information contained in this communication is proprietary to > Israel Aerospace Industries Ltd. and/or third parties, may contain > confidential or privileged information, and is intended only for the > use of the intended addressee thereof. If you are not the intended > addressee, please be aware that any use, disclosure, distribution > and/or copying of this communication is strictly prohibited. If you > receive this communication in error, please notify the sender > immediately and delete it from your computer. Thank you. -- Micha?l Baudin Ing?nieur de d?veloppement michael.baudin at scilab.org ------------------------- Consortium Scilab - Digiteo Domaine de Voluceau - Rocquencourt B.P. 105 - 78153 Le Chesnay Cedex Tel. : 01 39 63 56 87 - Fax : 01 39 63 55 94 -------------- next part -------------- An HTML attachment was scrubbed... URL: From communication at scilab.org Fri Feb 4 15:17:11 2011 From: communication at scilab.org (Scilab Communication) Date: Fri, 04 Feb 2011 15:17:11 +0100 Subject: Scilab File Exchange Message-ID: <4D4C0A67.6060508@scilab.org> Dear all, We are pleased to announce the launch of Scilab File Exchange - new website for Scilab community of users, dedicated to easily exchange files, script, data, experiences, etc. We invite you to connect to: http://fileexchange.scilab.org/ Do not hesitate to make us comments or suggestions in return. Best Regards ----------------------------------------------- The Scilab Consortium R&D Team ----------------------------------------------- Digiteo Domaine de Voluceau Rocquencourt - B.P. 105 78153 Le Chesnay Cedex - France From deanm at sharplabs.com Fri Feb 4 20:01:09 2011 From: deanm at sharplabs.com (Dean S. Messing) Date: Fri, 04 Feb 2011 11:01:09 -0800 Subject: [Scilab-Dev] Performance tests - Scilab 5.3.0 Vs Scilab 5.3.0-SSE3 In-Reply-To: <4D4821C9.5060802@scilab.org> (message from =?us-ascii?Q?=3D?= =?us-ascii?Q?=3FISO-8859-1=3FQ=3FMicha=3DEBl=5FBaudin=3F=3D?= on Tue, 01 Feb 2011 16:07:53 +0100) References: <2B47C3F3ED55F7428D8C66B3BD7E629B09EB35@mlmxmail.malam.iai.co.il> <4D4821C9.5060802@scilab.org> Message-ID: Slightly off topic: Is it possible for scilab (64-bit) to link in the MKL libs under a Linux OS? Currently I link in the Atlas libs, but I think MKL is faster. Thanks Dean From deanm at sharplabs.com Mon Feb 7 21:46:24 2011 From: deanm at sharplabs.com (Dean S. Messing) Date: Mon, 07 Feb 2011 12:46:24 -0800 Subject: 5.3.0 built with Atlas but with_atlas() returns F Message-ID: I'm trying to build the Image Processing Devel package under linux (outside of ATOMS). It immedately returns with an error saying I need to install Atlas. Problem is that I built scilab (GIT version from 27th Jan. 11) with Atlas. Note the 5th from last line. In fact here are the relevant lines from the output of the ./configure checking for msgcat... /usr/bin/msgcat checking if BLAS, ATLAS or MKL is available... checking how to get verbose linking output from gfortran... -v checking for Fortran 77 libraries of gfortran... -L/usr/lib64/atlas -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../.. -lpthread -ldl -lcurses -lgfortranbegin -lgfortran -lm checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore checking for sgemm_... no checking for ATL_xerbla in -latlas... yes checking for sgemm_ in -lf77blas... yes checking for cblas_dgemm in -lcblas... yes Atlas found checking if LAPACK is available... checking for cheev_... no checking for cheev_ in -llapack... yes Library -llapack found And here are the relevant lines from ldd: =>ldd /usr/local/bin/scilab-bin | fgrep -i atl libcblas.so.3 => /usr/lib64/atlas/libcblas.so.3 (0x00007f64572a3000) libf77blas.so.3 => /usr/lib64/atlas/libf77blas.so.3 (0x00007f6457086000) libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x00007f6456895000) liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3 (0x00007f6455d29000) But: -->with_atlas() ans = F Clues will be appreciated. :-) Dean From deanm at sharplabs.com Mon Feb 7 21:51:26 2011 From: deanm at sharplabs.com (Dean S. Messing) Date: Mon, 07 Feb 2011 12:51:26 -0800 Subject: 5.3.0 built with Atlas but with_atlas() returns F Message-ID: Sorry to disturb you. I just read bugzilla on this issue. Should have done that first. Dean From bvl at btconnect.com Tue Feb 8 00:08:06 2011 From: bvl at btconnect.com (bv) Date: Mon, 7 Feb 2011 23:08:06 +0000 Subject: [Scilab-Dev] 5.3.0 built with Atlas but with_atlas() returns F In-Reply-To: References: Message-ID: <201102072308.06860.bvl@btconnect.com> On Monday 07 February 2011 20:46:24 Dean S. Messing wrote: > I'm trying to build the Image Processing Devel package under linux > (outside of ATOMS). It immedately returns with an error saying I need > to install Atlas. Problem is that I built scilab (GIT version from 27th > Jan. 11) with Atlas. Note the 5th from last line. > > In fact here are the relevant lines from the output of the ./configure > > checking for msgcat... /usr/bin/msgcat > checking if BLAS, ATLAS or MKL is available... > checking how to get verbose linking output from gfortran... -v > checking for Fortran 77 libraries of gfortran... -L/usr/lib64/atlas > -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5 > -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64 -L/lib/../lib64 > -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../.. > -lpthread -ldl -lcurses -lgfortranbegin -lgfortran -lm checking for dummy > main to link with Fortran 77 libraries... none > checking for Fortran 77 name-mangling scheme... lower case, underscore, no > extra underscore checking for sgemm_... no > checking for ATL_xerbla in -latlas... yes > checking for sgemm_ in -lf77blas... yes > checking for cblas_dgemm in -lcblas... yes > Atlas found > checking if LAPACK is available... > checking for cheev_... no > checking for cheev_ in -llapack... yes > Library -llapack found > > > And here are the relevant lines from ldd: > > =>ldd /usr/local/bin/scilab-bin | fgrep -i atl > libcblas.so.3 => /usr/lib64/atlas/libcblas.so.3 (0x00007f64572a3000) > libf77blas.so.3 => /usr/lib64/atlas/libf77blas.so.3 (0x00007f6457086000) > libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x00007f6456895000) > liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3 (0x00007f6455d29000) > > But: > > -->with_atlas() > ans = > > F > > Clues will be appreciated. :-) > > Dean Maybe you should try the latest versions of atlas and compile from sources. I had a go with atlas3.9.33/scilab-5.3.0 and it seems to have worked. From deanm at sharplabs.com Mon Feb 7 23:33:07 2011 From: deanm at sharplabs.com (Dean S. Messing) Date: Mon, 07 Feb 2011 14:33:07 -0800 Subject: [Scilab-Dev] 5.3.0 built with Atlas but with_atlas() returns F In-Reply-To: <201102072308.06860.bvl@btconnect.com> (message from bv on Mon, 7 Feb 2011 23:08:06 +0000) References: <201102072308.06860.bvl@btconnect.com> Message-ID: > Maybe you should try the latest versions of atlas and compile from sources. I > had a go with atlas3.9.33/scilab-5.3.0 and it seems to have worked. The Atlas libs seem to work fine as far as scilab benchmark times are concerned. The problem seems to be an old bug in with_atlas(), i.e., it's a scilab problem I think. http://bugzilla.scilab.org/show_bug.cgi?id=3265 From sylvestre.ledru at scilab.org Mon Feb 7 23:43:06 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Mon, 07 Feb 2011 23:43:06 +0100 Subject: [Scilab-Dev] 5.3.0 built with Atlas but with_atlas() returns F In-Reply-To: References: <201102072308.06860.bvl@btconnect.com> Message-ID: <1297118586.21615.8.camel@losinj.inria.fr> On Mon, 2011-02-07 at 14:33 -0800, Dean S. Messing wrote: > > Maybe you should try the latest versions of atlas and compile from sources. I > > had a go with atlas3.9.33/scilab-5.3.0 and it seems to have worked. > > The Atlas libs seem to work fine as far as scilab benchmark times are > concerned. The problem seems to be an old bug in with_atlas(), > i.e., it's a scilab problem I think. > > http://bugzilla.scilab.org/show_bug.cgi?id=3265 Actually, under GNU/Linux & Mac OS X, it is irrelevant. It is hard to properly detect the underlying linear algebra library (if it ref BLAS, atlas or the MKL). Under Windows, it is easier but still not very interesting ... It is why we are going to move it in getdebuginfo() under Windows and drop it under !Windows. Sylvestre From sylvestre.ledru at scilab.org Mon Feb 7 23:44:14 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Mon, 07 Feb 2011 23:44:14 +0100 Subject: [Scilab-Dev] Performance tests - Scilab 5.3.0 Vs Scilab 5.3.0-SSE3 In-Reply-To: References: <2B47C3F3ED55F7428D8C66B3BD7E629B09EB35@mlmxmail.malam.iai.co.il> <4D4821C9.5060802@scilab.org> Message-ID: <1297118654.21615.14.camel@losinj.inria.fr> On Fri, 2011-02-04 at 11:01 -0800, Dean S. Messing wrote: > Slightly off topic: > > Is it possible for scilab (64-bit) to link > in the MKL libs under a Linux OS? Currently > I link in the Atlas libs, but I think MKL > is faster. Yes, it is possible but you might have to play a bit with LDFLAGS ;) Sylvestre From deanm at sharplabs.com Tue Feb 8 01:43:09 2011 From: deanm at sharplabs.com (Dean S. Messing) Date: Mon, 07 Feb 2011 16:43:09 -0800 Subject: ATOMS page down? Message-ID: Browsing to http://atoms.scilab.org/ from the Scilab homepage returns Une exception a ??t?? g??r??e Error MYSQL : Erreur de connexion au serveurpalmaria.inria.fr File /home/web/old.scilab.org/accounts/lib/session.class.php Line 74 Code 0 Trace File /home/web/atoms.scilab.org/admin/session.php.inc Line 18 Class session Function __construct I got to this page from the "Brownse the modules >>" link on products --> All Modules from the home page. Dean From sylvestre.ledru at scilab.org Tue Feb 8 08:00:37 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 08 Feb 2011 08:00:37 +0100 Subject: [Scilab-Dev] ATOMS page down? In-Reply-To: References: Message-ID: <1297148437.21615.1007.camel@losinj.inria.fr> fixed. Thanks for reporting it. S On Mon, 2011-02-07 at 16:43 -0800, Dean S. Messing wrote: > Browsing to http://atoms.scilab.org/ from the Scilab homepage > > returns > > > Une exception a ??t?? g??r??e > Error > MYSQL : Erreur de connexion au serveurpalmaria.inria.fr > File > /home/web/old.scilab.org/accounts/lib/session.class.php > Line > 74 > Code > 0 > Trace > File > /home/web/atoms.scilab.org/admin/session.php.inc > Line > 18 > Class > session > Function > __construct > > > I got to this page from the "Brownse the modules >>" link on > > products --> All Modules > > from the home page. > > Dean From deanm at sharplabs.com Wed Feb 9 22:59:19 2011 From: deanm at sharplabs.com (Dean S. Messing) Date: Wed, 09 Feb 2011 13:59:19 -0800 Subject: Problems with atoms.scilab.org again Message-ID: Browsing over to atoms.scilab.org, the page never renders. No response at all. Just a "waiting for atoms.scilab.org" til finally a "Connection was reset" message appears on the screen However, I can ping the address. Dean From sylvestre.ledru at scilab.org Wed Feb 9 23:37:42 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Wed, 09 Feb 2011 23:37:42 +0100 Subject: [Scilab-Dev] Problems with atoms.scilab.org again In-Reply-To: References: Message-ID: <1297291062.9050.17.camel@losinj.inria.fr> Le mercredi 09 f?vrier 2011 ? 13:59 -0800, Dean S. Messing a ?crit : > Browsing over to atoms.scilab.org, the page never renders. No > response at all. Just a "waiting for atoms.scilab.org" til finally > a "Connection was reset" message appears on the screen > > > However, I can ping the address. Indeed ... The server looks like down :/ We will reboot it tomorrow morning (Paris time)... Sorry Sylvestre From develop.dujardin at numericable.fr Mon Feb 14 17:07:25 2011 From: develop.dujardin at numericable.fr (DUJARDIN Bernard) Date: Mon, 14 Feb 2011 17:07:25 +0100 Subject: SEP#50: Xcos help folders and naming conventions. Message-ID: <4D59533D.2000800@numericable.fr> Hello, An abstract of the SEP : The progress of the work on the help of Xcos has for result an increasing number of files for examples and images. This SEP proposes a new folder hierarchy to make more easy the management of the images, and examples. It proposes also a standardized naming of files and a standardized writing of the link's references. This SEP will also serve as reference for the writers of the help of Xcos -- Bernard DUJARDIN -------------- next part -------------- A non-text attachment was scrubbed... Name: SEP_50_Xcos_Help_Folder.tgz Type: application/x-compressed Size: 23673 bytes Desc: not available URL: From sylvestre.ledru at scilab.org Tue Feb 15 17:24:30 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 15 Feb 2011 17:24:30 +0100 Subject: [Scilab-Dev] SEP#50: Xcos help folders and naming conventions. In-Reply-To: <4D59533D.2000800@numericable.fr> References: <4D59533D.2000800@numericable.fr> Message-ID: <1297787070.5205.155.camel@losinj.inria.fr> Hello As I told you privately, I strongly support your proposal! Sylvestre Le lundi 14 f?vrier 2011 ? 17:07 +0100, DUJARDIN Bernard a ?crit : > Hello, > > An abstract of the SEP : > > The progress of the work on the help of Xcos has for result an > increasing number of files for examples and images. > > > This SEP proposes a new folder hierarchy to make more easy the > management of the images, and examples. It proposes also a > standardized naming of files and a standardized writing of > the link's references. > > This SEP will also serve as reference for the writers of > the help of Xcos > > From deanm at sharplabs.com Fri Feb 18 02:28:04 2011 From: deanm at sharplabs.com (Dean S. Messing) Date: Thu, 17 Feb 2011 17:28:04 -0800 Subject: New ./configure error on Fedora 13 machine Message-ID: Was something in ./configure changed in the last month? This: PATH=${PATH}:/usr/share/pvm3/lib ./configure LDFLAGS="-L/usr/lib64/atlas" has been working just fine for several months on my Fedora 13 system. Today I down-loaded the source from last night and tried to build. It died in the ./configure with: Generic Blas found checking if LAPACK is available... checking for cheev_... no checking for cheev_ in -llapack... no checking for cheev_ in -llapack_rs6k... no configure: error: Impossible to find the LAPACK library. The problem is this (from the config.log): configure:22543: checking for cheev_ in -llapack configure:22576: gcc -o conftest -g -O2 -D_LARGEFILE64_SOURCE -DNDEBUG -fno-stack-protector -DNARROWPROTO -m64 -I$(top_srcdir)/modules/core/includes/ -I$(top_srcdir)/libs/MALLOC/includes/ -I$(top_srcdir)/modules/localization/includes/ -D_LARGEFILE64_SOURCE -DNDEBUG -fno-stack-protector -I$(top_srcdir)/modules/core/includes/ -I$(top_srcdir)/libs/MALLOC/includes/ -I$(top_srcdir)/modules/localization/includes/ -Wl,--no-as-needed conftest.c -llapack -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../.. -lpthread -ldl -lcurses -lgfortranbegin -lgfortran -lm -lblas -lpthread -ldl -lcurses -lm >&5 /usr/bin/ld: cannot find -llapack collect2: ld returned 1 exit status Here is the corresponding lines from my January 22nd build: configure:22472: checking for cheev_ in -llapack configure:22505: gcc -o conftest -g -O2 -DNDEBUG -fno-stack-protector -DNARROWPROTO -m64 -I$(top_srcdir)/modules/core/includes/ -I$(top_srcdir)/libs/MALLOC/includes/ -I$(top_srcdir)/modules/localization/includes/ -DNDEBUG -fno-stack-protector -I$(top_srcdir)/modules/core/includes/ -I$(top_srcdir)/libs/MALLOC/includes/ -I$(top_srcdir)/modules/localization/includes/ -L/usr/lib64/atlas conftest.c -llapack -L/usr/lib64/atlas -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../.. -lpthread -ldl -lcurses -lgfortranbegin -lgfortran -lm -lcblas -lf77blas -latlas -lpthread -ldl -lcurses -lm >&5 configure:22505: $? = 0 configure:22515: result: yes The problem is that the -L/usr/lib64/atlas flags have vanished! But it is in /usr/lib64/atlas that liblapack.so lives. What's the fix? Thanks Dean From deanm at sharplabs.com Fri Feb 18 04:04:01 2011 From: deanm at sharplabs.com (Dean S. Messing) Date: Thu, 17 Feb 2011 19:04:01 -0800 Subject: New ./configure error on Fedora 13 machine : deanm@sharplabs.com (Dean S. Messing) Message-ID: There are a lot of other problems too with ./configure For one thing, configure is not detecting that I have the atlas libraries. Th following appears to be the problem. This change ./configure seems to fix everything. --- configure_orig 2011-02-17 13:03:44.818878305 -0800 +++ configure 2011-02-17 17:51:53.492879440 -0800 @@ -9298,7 +9298,7 @@ # Once all cyclic dependencies have been dropped, this line could be removed. # Check if linker supports --as-needed and --no-as-needed options if $LD --help 2>/dev/null | grep no-as-needed > /dev/null; then - LDFLAGS="-Wl,--no-as-needed" + LDFLAGS="$LDFLAGS -Wl,--no-as-needed" fi Dean From sylvestre.ledru at scilab.org Fri Feb 18 08:33:37 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Fri, 18 Feb 2011 08:33:37 +0100 Subject: [Scilab-Dev] New ./configure error on Fedora 13 machine In-Reply-To: References: Message-ID: <1298014417.29607.1284.camel@losinj.inria.fr> Hello Dean, It is likely to be caused by a change on your system. If you are sure it is not the case, could you send your config.log ? Thanks S Le jeudi 17 f?vrier 2011 ? 17:28 -0800, Dean S. Messing a ?crit : > Was something in ./configure changed in the last month? > > This: > > PATH=${PATH}:/usr/share/pvm3/lib ./configure LDFLAGS="-L/usr/lib64/atlas" > > > has been working just fine for several months on my Fedora 13 system. > > Today I down-loaded the source > from last night and tried to build. It died in the ./configure with: > > Generic Blas found > checking if LAPACK is available... > checking for cheev_... no > checking for cheev_ in -llapack... no > checking for cheev_ in -llapack_rs6k... no > configure: error: Impossible to find the LAPACK library. > > The problem is this (from the config.log): > > configure:22543: checking for cheev_ in -llapack > configure:22576: gcc -o conftest -g -O2 -D_LARGEFILE64_SOURCE -DNDEBUG -fno-stack-protector -DNARROWPROTO -m64 -I$(top_srcdir)/modules/core/includes/ -I$(top_srcdir)/libs/MALLOC/includes/ -I$(top_srcdir)/modules/localization/includes/ -D_LARGEFILE64_SOURCE -DNDEBUG -fno-stack-protector -I$(top_srcdir)/modules/core/includes/ -I$(top_srcdir)/libs/MALLOC/includes/ -I$(top_srcdir)/modules/localization/includes/ -Wl,--no-as-needed conftest.c -llapack -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../.. -lpthread -ldl -lcurses -lgfortranbegin -lgfortran -lm -lblas -lpthread -ldl -lcurses -lm >&5 > /usr/bin/ld: cannot find -llapack > collect2: ld returned 1 exit status > > > Here is the corresponding lines from my January 22nd build: > > > > configure:22472: checking for cheev_ in -llapack > configure:22505: gcc -o conftest -g -O2 -DNDEBUG -fno-stack-protector -DNARROWPROTO -m64 -I$(top_srcdir)/modules/core/includes/ -I$(top_srcdir)/libs/MALLOC/includes/ -I$(top_srcdir)/modules/localization/includes/ -DNDEBUG -fno-stack-protector -I$(top_srcdir)/modules/core/includes/ -I$(top_srcdir)/libs/MALLOC/includes/ -I$(top_srcdir)/modules/localization/includes/ -L/usr/lib64/atlas conftest.c -llapack -L/usr/lib64/atlas -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../.. -lpthread -ldl -lcurses -lgfortranbegin -lgfortran -lm -lcblas -lf77blas -latlas -lpthread -ldl -lcurses -lm >&5 > configure:22505: $? = 0 > configure:22515: result: yes > > > The problem is that the -L/usr/lib64/atlas flags have vanished! > But it is in /usr/lib64/atlas that liblapack.so lives. > > What's the fix? > > Thanks > Dean From sylvestre.ledru at scilab.org Fri Feb 18 08:41:04 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Fri, 18 Feb 2011 08:41:04 +0100 Subject: [Scilab-Dev] Re: New ./configure error on Fedora 13 machine : deanm@sharplabs.com (Dean S. Messing) In-Reply-To: References: Message-ID: <1298014864.29607.1302.camel@losinj.inria.fr> Le jeudi 17 f?vrier 2011 ? 19:04 -0800, Dean S. Messing a ?crit : > There are a lot of other problems too with ./configure > For one thing, configure is not detecting that > I have the atlas libraries. > > > Th following appears to be the problem. > This change ./configure seems to fix everything. > > --- configure_orig 2011-02-17 13:03:44.818878305 -0800 > +++ configure 2011-02-17 17:51:53.492879440 -0800 > @@ -9298,7 +9298,7 @@ > # Once all cyclic dependencies have been dropped, this line could be removed. > # Check if linker supports --as-needed and --no-as-needed options > if $LD --help 2>/dev/null | grep no-as-needed > /dev/null; then > - LDFLAGS="-Wl,--no-as-needed" > + LDFLAGS="$LDFLAGS -Wl,--no-as-needed" > fi You are right. It is my fault. Thanks! Here it is: http://codereview.scilab.org/#change,3207 Sylvestre From clement.david at scilab.org Fri Feb 18 09:53:12 2011 From: clement.david at scilab.org (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Fri, 18 Feb 2011 09:53:12 +0100 Subject: [Scilab-Dev] Re: New ./configure error on Fedora 13 machine : deanm@sharplabs.com (Dean S. Messing) In-Reply-To: <1298014864.29607.1302.camel@losinj.inria.fr> References: <1298014864.29607.1302.camel@losinj.inria.fr> Message-ID: <1298019192.3063.0.camel@pinarellu.inria.fr> Le vendredi 18 f?vrier 2011 ? 08:41 +0100, Sylvestre Ledru a ?crit : > Le jeudi 17 f?vrier 2011 ? 19:04 -0800, Dean S. Messing a ?crit : > > There are a lot of other problems too with ./configure > > For one thing, configure is not detecting that > > I have the atlas libraries. > > > > > > Th following appears to be the problem. > > This change ./configure seems to fix everything. > > > > --- configure_orig 2011-02-17 13:03:44.818878305 -0800 > > +++ configure 2011-02-17 17:51:53.492879440 -0800 > > @@ -9298,7 +9298,7 @@ > > # Once all cyclic dependencies have been dropped, this line could be removed. > > # Check if linker supports --as-needed and --no-as-needed options > > if $LD --help 2>/dev/null | grep no-as-needed > /dev/null; then > > - LDFLAGS="-Wl,--no-as-needed" > > + LDFLAGS="$LDFLAGS -Wl,--no-as-needed" > > fi > You are right. It is my fault. Thanks! > > Here it is: > http://codereview.scilab.org/#change,3207 > > Sylvestre > > Merged at http://gitweb.scilab.org/?p=scilab.git;a=commit;h=09a5dc4185ce574cd16df0a13fcbd503817ac74f -- Cl?ment David