[gradsusr] GrAds 2.0a7 and beyond - floating point exception

Goodson,Ron [Edm] Ron.Goodson at EC.gc.ca
Thu Feb 17 11:15:45 EST 2011


hmmmm 2.3.4 on both computers.  Thanks Arlindo -- I'll give that a shot.
 
('though I hate to think of the depencies-worm-can I'll be opening up.....)
 

Ron Goodson            
Prairie and Northern Meteorological Service of Canada Science Section   Unité des Sciences, Région des Prairies et du Nord, Service Météorologique du Canada   
Environment Canada

Room 200 ; 4999 - 98 Avenue

Edmonton Alberta T6B 2X3        Environnement Canada

Pièce 200 ; 4999 - 98 Avenue

Edmonton Alberta T6B 2X3       
Telephone | Téléphone   780 951 8791   
Email | Courriel        ron.goodson at ec.gc.ca   


 

________________________________

From: gradsusr-bounces at gradsusr.org [mailto:gradsusr-bounces at gradsusr.org] On Behalf Of Arlindo da Silva
Sent: February 16, 2011 6:17 PM
To: GrADS Users Forum
Subject: Re: [gradsusr] GrAds 2.0a7 and beyond - floating point exception


Ron, 

 Sometimes this floating point error means an incompatible version of libc.  What is the result of

% ldd --version

You should have at least GNU libc 2.5; anything earlier will not work.

    Arlindo

On Wed, Feb 16, 2011 at 2:47 PM, Goodson,Ron [Edm] <Ron.Goodson at ec.gc.ca> wrote:


	Hi Jennifer
	 
	Thanks for the reply.
	 
	I'm using i686 versions.  
	 
	On the RedHat System....
	 
	The 2.0.a5 ldd only had 5 entries,
	 
	libX11.so.6
	libm.so.6
	libc.so.6
	libdl.so.2
	ld-linux.so.2.
	 
	All of these exist on my system
	 
	The 2.0.a7 version was ... ouch...
	 
	 ldd  grads  
	 
	/usr/bin/ldd line 124: 32206 Floating point exception LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION=$verify_out LD_VERBOSE="$@"
	 
	On the Debain System.
	 
	ldd for both 2.0a5 and 2.0a7 gave the same results 
	 
	linux-gate.so.1
	libX11.so.6
	libm.so.6
	libc.so.6
	libXau.so.6
	libXdmcp.so.6
	libdl.so.2
	ld-linux.so.2
	 
	All of these exist on my system.  The libXau.so.6 and libXdmcp exist only on my Debian system.  I see via google that  "linux-gate.so.1" is not a real file so I ignore that (but surprised I don't see it on the RedHat side .. perhaps too ancient).
	 
	But, given that ldd reports the same libraries for a5 and a7 on the Debian system .. and one runs and the other gets the floating poing exception .. I'm now at a bit of a loss.  Oh well, perhaps building from source it is.. too bad.
	 
	 

	Ron Goodson            
	Prairie and Northern Meteorological Service of Canada Science Section   Unité des Sciences, Région des Prairies et du Nord, Service Météorologique du Canada   
	Environment Canada

	Room 200 ; 4999 - 98 Avenue

	Edmonton Alberta T6B 2X3        Environnement Canada

	Pièce 200 ; 4999 - 98 Avenue

	Edmonton Alberta T6B 2X3       
	Telephone | Téléphone   780 951 8791   
	Email | Courriel        ron.goodson at ec.gc.ca   
	

	 

________________________________

	From: gradsusr-bounces at gradsusr.org [mailto:gradsusr-bounces at gradsusr.org] On Behalf Of Jennifer Adams
	Sent: February 16, 2011 11:57 AM
	To: GrADS Users Forum
	Subject: Re: [gradsusr] GrAds 2.0a7 and beyond - floating point exception
	
	
	Hi, Ron --  
	The 'floating point exception' usually means the architecture of the executable is incompatible with the OS. Our binary releases are not 100% statically linked, there are some shared dependencies. From your message, it's not clear which binary release you're using -- CentOS (previously known as RHEL) 4 or 5 (the two 64-bit builds) or i686 (the 32-bit build). Try using the 'ldd' command print out shared library dependencies and see if those libs exist on your system, and you can compare the ldd ouptut from 2.0.a5 and later builds. For example, the latest CentOS5 build has this: 

	> ldd /usr/local/grads/2.0/2.0.a9.release/grads 
	        libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003edf000000)
	        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ede800000)
	        libdl.so.2 => /lib64/libdl.so.2 (0x0000003ede400000)
	        librt.so.1 => /lib64/librt.so.1 (0x0000003ee2400000)
	        libm.so.6 => /lib64/libm.so.6 (0x0000003ede000000)
	        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003ee4000000)
	        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003ee2c00000)
	        libc.so.6 => /lib64/libc.so.6 (0x0000003eddc00000)
	        libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003edf400000)
	        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003edf800000)
	        /lib64/ld-linux-x86-64.so.2 (0x0000003edd800000)


	If your unix flavor is not quite the same as the OS on which the binary was originally compiled/linked, then you may have to rebuild from source. It's hard to say what what may have changed between a5 and a6 -- maybe our OS was upgraded during that time. 

	Here's the current uname -a output from our CentOS 4 and 5 boxes: 

	# uname -a
	Linux <host> 2.6.9-89.0.16.ELsmp #1 SMP Tue Nov 3 17:43:09 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
	 # uname -a
	Linux <host> 2.6.18-194.17.1.el5 #1 SMP Wed Sep 29 12:50:31 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

	--Jennifer


	On Feb 16, 2011, at 1:31 PM, Goodson,Ron [Edm] wrote:


		Hi to the brain trust (Jennifer et al.).  Because my problem is so vague - I'm not necessarily expecting an answer but thought I'd give it a shot.
		 
		Using either an older RedHat WS4 installation running kernel 2.6.9-11, or a newer Debian etch (2.6.18-6) I have been able to use all version of grads up to and including 2.0.a5.  However, all versions beyond that result in a "floating point exception" immediately after invoking grads.  
		 
		I am thinking there is some underlying library mis-match.  Just wondering if anyone could throw me a bone as to what might have changed between a5 and a7 (in terms of what they expect from the operating-system libraries) so that I can have a starting point to fixing this.
		 
		Thanks for any help - but - since I haven't seen any one else mention this, I'm not expecting much.
		 
		ron goodson
		environment canda
		 
		 
		_______________________________________________
		gradsusr mailing list
		gradsusr at gradsusr.org
		http://gradsusr.org/mailman/listinfo/gradsusr
		


	--
	Jennifer M. Adams
	IGES/COLA
	4041 Powder Mill Road, Suite 302
	Calverton, MD 20705
	jma at cola.iges.org




	_______________________________________________
	gradsusr mailing list
	gradsusr at gradsusr.org
	http://gradsusr.org/mailman/listinfo/gradsusr
	
	




-- 
Arlindo da Silva
dasilva at alum.mit.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20110217/483e2d08/attachment-0003.html 


More information about the gradsusr mailing list