[Ncep.list.pmb-dataflow] Re: problems compiling on new server
Patrick O'Reilly
patrick.oreilly at noaa.gov
Tue Aug 7 11:24:57 EDT 2007
I believe we have a 32-bit executable running on a 64-bit AIX system. We have to
compile on a system at the TOC which is 32 bit, and run it on a 64-bit system.
After talking to the cnvgrib developer, I don't think the opengl stuff is an issue.
Is it possible our account has settings set too low to use cnvgrib, some memory
limits, so that when it runs, it hits the limit and core dumps?
Chi Y Kang wrote:
> Try exporting the including the path to
> "/vg0/ncep/home/ftpncep/woc/g95/g95-0.90/" for now.
>
> I don't have opengl libraries installed on the other boxes. Do you have
> this version running on 64 bit anywhere else?
>
>
>
> Patrick O'Reilly wrote:
>> Hi Chi,
>>
>> The new g95 compiler seems to have installation issues or the
>> environment is not set up correctly. I have the executable linked from
>> ~/bin:
>>
>> lrwxrwxrwx 1 ftpncep ftpncep 43 Aug 7 12:48 g95 ->
>> /vg0/ncep/home/ftpncep/woc/g95/g95-0.90/g95
>>
>> A compile shows:
>>
>> ftpncep at gd1-ncep:~/grib2/w3lib-1.4$ make
>> g95 -g -O3 -c bacio_module.f
>> g95: installation problem, cannot exec 'f951': No such file or directory
>> make: *** [bacio_module.o] Error 1
>>
>> Additionally, a supporting library (JasPer) seems to have many more
>> errors than usual when it's compiled. It can't find OpenGL on the
>> system and from the documentation it depends on this for some of its
>> functionality. I've included the Dependencies section of this software
>> below. It's possible that the cnvgrib that I did get compiled with
>> 'g95-amd64-32' might seg fault because of the incomplete Jasper libraries.
>>
>> Patrick
>>
>>
>> Dependencies of Jasper
>>
>> "In order to have access to the full functionality of the JasPer
>> sofware, you may need to install some additional software on your
>> system. This software must be installed before you attempt to build JasPer.
>>
>> In order to compile the JasPer software with JPEG support, you will need
>> to download and install the free IJG JPEG library which is available
>> from the IJG web site (i.e., http://www.ijg.org). If you are not using a
>> configure-based build for JasPer, then you will need to manually change
>> the build process to use the code in the files jpg_enc.c and jpg_dec.c
>> instead of jpg_dummy.c. (Note: These three files are contained in the
>> JasPer distribution, not the IJG library.)
>>
>> In order to build the jiv application, you will need the OpenGL and GLUT
>> libraries installed on your system. It would appear that Windows 2000
>> and Windows XP ship with the OpenGL library from Microsoft. Most recent
>> versions of UNIX ship with OpenGL support included. The GLUT library is
>> less common and, therefore, may not be installed on your system. To
>> obtain the GLUT library, one can visit:
>> http://www.opengl.org/developers/documentation/glut. For more
>> information on the OpenGL library, see: http://www.opengl.org.
>>
>> At the time of this writing, a binary distribution of the GLUT library
>> for Windows is available from the OpenGL web site:
>> http://www.opengl.org/developers/documentation/glut/glutdlls37beta.zip
>> This archive file contains three files of interest: 1) glut.h, 2)
>> glut32.lib, and 3) glut32.dll. The file glut.h file should be installed
>> in a directory in which the C compiler searches for header files
>> (e.g.,Page 15 $TOPDIR/src/include/jasper). The glut32.lib file should be
>> installed in a directory in which the C compiler searches for libraries.
>> The glut32.dll file should be installed in a directory in which the
>> system looks for dynamically-linked libraries."
>>
>>
>> Chi Y Kang wrote:
>>> I think compile this from gcc 4.0.3
>>>
>>> /vg0/ncep/home/ftpncep/woc/g95/g95-0.90/g95
>>>
>>> I left the libraries for this here
>>> "/vg0/ncep/home/ftpncep/woc/gcc/gcc-4.0.3/g95/"
>>>
>>>
>>> I compiled this also with the 64 binaries with default set to 32
>>> integer set here.
>>>
>>> Give this a try.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Patrick O'Reilly wrote:
>>>> Chi,
>>>>
>>>> I got one of our pieces of code compiled:
>>>>
>>>> ~ftpncep/grib2/wgrib
>>>>
>>>> This uses only the 'cc' compiler, and it compiled and works correctly.
>>>>
>>>> Patrick
>>>>
>>>> Chi Y Kang wrote:
>>>>> So I installed gdb and cgdb for us young folks.
>>>>>
>>>>> I am wondering if the 64bit is a big issue here. Clearly, there is a
>>>>> memory addressing has an offset for 32bit vs 64bit here,
>>>>>
>>>>> Looking at the cnvgrib build myself.
>>>>>
>>>>>
>>>>>
>>>>> gdb cnvgrib core
>>>>> GNU gdb 6.4.90-debian
>>>>> Copyright (C) 2006 Free Software Foundation, Inc.
>>>>> GDB is free software, covered by the GNU General Public License, and
>>>>> you are
>>>>> welcome to change it and/or distribute copies of it under certain
>>>>> conditions.
>>>>> Type "show copying" to see the conditions.
>>>>> There is absolutely no warranty for GDB. Type "show warranty" for
>>>>> details.
>>>>> This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db
>>>>> library "/lib/libthread_db.so.1".
>>>>>
>>>>> Reading symbols from /usr/lib/libpng12.so.0...done.
>>>>> Loaded symbols for /usr/lib/libpng12.so.0
>>>>> Reading symbols from /usr/lib/libz.so.1...done.
>>>>> Loaded symbols for /usr/lib/libz.so.1
>>>>> Reading symbols from /lib/libm.so.6...done.
>>>>> Loaded symbols for /lib/libm.so.6
>>>>> Reading symbols from /lib/libc.so.6...done.
>>>>> Loaded symbols for /lib/libc.so.6
>>>>> Reading symbols from /lib/ld-linux-x86-64.so.2...done.
>>>>> Loaded symbols for /lib64/ld-linux-x86-64.so.2
>>>>> Core was generated by `./cnvgrib -g21 nam.t12z.awip1212.tm00.grib2
>>>>> nam.t12z.awip1212.tm00'.
>>>>> Program terminated with signal 11, Segmentation fault.
>>>>> #0 0x00002b650ac8a20a in free () from /lib/libc.so.6
>>>>> (gdb) bt
>>>>> #0 0x00002b650ac8a20a in free () from /lib/libc.so.6
>>>>> #1 0x0000000000444548 in mem_close (obj=0x653950) at jas_stream.c:1126
>>>>> #2 0x00000000004445a4 in jas_stream_close (stream=0x674030) at
>>>>> jas_stream.c:513
>>>>> #3 0x00000000004416a2 in jas_image_cmpt_destroy (cmpt=0x673fd0) at
>>>>> jas_image.c:391
>>>>> #4 0x000000000044245c in jas_image_destroy (image=0x673f80) at
>>>>> jas_image.c:337
>>>>> #5 0x000000000042ae7c in dec_jpeg2000__ ()
>>>>> #6 0x000000000042ad3d in jpcunpack_ (cpack=0x653a5d "ÿOÿQ",
>>>>> len=0x7fffa035adbc, idrstmpl=0x647338,
>>>>> ndpts=0x7fffa035c468, fld=<value optimized out>, cpack.len=<value
>>>>> optimized out>) at jpcunpack.f:54
>>>>> #7 0x0000000000428d0b in gf_unpack7__ (cgrib=<value optimized out>,
>>>>> lcgrib=<value optimized out>,
>>>>> iofst=0x7fffa035ae94, igdsnum=0x7fffa035c3d8,
>>>>> igdstmpl=0x7fffa035c3e0,
>>>>> idrsnum=<value optimized out>, idrstmpl=0x7fffa035c478,
>>>>> ndpts=0x7fffa035c468, fld=0x7fffa035c4d8,
>>>>> ierr=0x7fffa035ae88, cgrib.len=1) at gf_unpack7.f:105
>>>>> #8 0x0000000000426fcd in getgb2r_ (lugb=<value optimized out>,
>>>>> cindex=<value optimized out>,
>>>>> gfld=0x7fffa035c330, iret=0x7fffa035c6b4, cindex.len=<value
>>>>> optimized out>) at getgb2r.f:271
>>>>> #9 0x00000000004239e7 in getgb2_ (lugb=0x7fffa035ce54, lugi=<value
>>>>> optimized out>, j=0x7fffa035c6bc,
>>>>> jdisc=0x7fffa035c6c4, jids=0x7fffa035b390, jpdtn=0x7fffa035c6c0,
>>>>> jpdt=0x0, jgdtn=0x0, jgdt=0x0,
>>>>> unpack=0x0, k=0x0, gfld=0x7fffa035c330, iret=0x7fffa035c6b4) at
>>>>> getgb2.f:326
>>>>> #10 0x00000000004106b9 in cnv21_ (ifl1=0x7fffa035ce54,
>>>>> ifl2=0x7fffa035ce48) at cnv21.f:61
>>>>> #11 0x0000000000408b75 in MAIN_ () at cnvgrib.f:161
>>>>> #12 0x0000000000472d1e in main ()
>>>>>
>>>>>
>>>>>
>>>>> Chi Y Kang wrote:
>>>>>> not too much here.
>>>>>>
>>>>>> This GDB was configured as "x86_64-linux-gnu".
>>>>>> (tgdb) core-file core
>>>>>> Core was generated by `./cnvgrib -g21 nam.t12z.awip1212.tm00.grib2
>>>>>> nam.t12z.awip1212.tm00'.
>>>>>> Program terminated with signal 11, Segmentation fault.
>>>>>> #0 0x00002b650ac8a20a in ?? ()
>>>>>> (tgdb) backtrace
>>>>>> #0 0x00002b650ac8a20a in ?? ()
>>>>>>
>>>>>>
>>>>>> I'll work on the g95 this weekend to get you something you can use.
>>>>>>
>>>>>> What are you compiling and how can I test the binaries?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Patrick O'Reilly wrote:
>>>>>>> Bad news, the executable seg faulted. There's a core file in
>>>>>>> /vg0/ncep/home/ftpncep/cnvgrib_test if you're good at reading those
>>>>>>> things, but I didn't find dbx or gdb.
>>>>>>>
>>>>>>> Is it possible to compile a g95 from source instead of using the
>>>>>>> binaries?
>>>>>>>
>>>>>>> Patrick
>>>>>>>
>>>>>>> Chi.Y.Kang wrote:
>>>>>>>> So this is 64 bit native binaries with 32 integer set by default.
>>>>>>>>
>>>>>>>> Patrick.OReilly at noaa.gov wrote:
>>>>>>>>> Success!
>>>>>>>>>
>>>>>>>>> I'll test the executable tomorrow some to make sure it performs
>>>>>>>>> similar
>>>>>>>>> to the one on the current diskserver.
>>>>>>>>>
>>>>>>>>> Thanks Chi!
>>>>>>>>>
>>>>>>>>> Patrick
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Chi.Y.Kang" <Chi.Y.Kang at noaa.gov>
>>>>>>>>> Date: Thursday, August 2, 2007 4:50 pm
>>>>>>>>> Subject: Re: problems compiling on new server
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> /vg0/ncep/home/ftpncep/bin/g95-amd64-32
>>>>>>>>>>
>>>>>>>>>> Patrick.OReilly at noaa.gov wrote:
>>>>>>>>>>
>>>>>>>>>>> Not sure it's going to work, unless I need to passing some
>>>>>>>>>>> flag
>>>>>>>>>> to the
>>>>>>>>>>
>>>>>>>>>>> compiler. Here's what I see:
>>>>>>>>>>>
>>>>>>>>>>> ftpncep at gd0-ncep:~/grib2/w3lib-1.4$ make
>>>>>>>>>>> g95-i386 -g -O3 -c bacio_module.f
>>>>>>>>>>> g95-i386 -g -O3 -c getgb.f
>>>>>>>>>>> /tmp/ccS1N4wb.s: Assembler messages:
>>>>>>>>>>> /tmp/ccS1N4wb.s:41: Error: suffix or operands invalid for `push'
>>>>>>>>>>> /tmp/ccS1N4wb.s:45: Error: suffix or operands invalid for `push'
>>>>>>>>>>> /tmp/ccS1N4wb.s:47: Error: suffix or operands invalid for `push'
>>>>>>>>>>> /tmp/ccS1N4wb.s:49: Error: suffix or operands invalid for `push'
>>>>>>>>>>> /tmp/ccS1N4wb.s:135: Error: suffix or operands invalid for `pop'
>>>>>>>>>>> /tmp/ccS1N4wb.s:137: Error: suffix or operands invalid for `pop'
>>>>>>>>>>> /tmp/ccS1N4wb.s:139: Error: suffix or operands invalid for `pop'
>>>>>>>>>>> /tmp/ccS1N4wb.s:141: Error: suffix or operands invalid for `pop'
>>>>>>>>>>> make: *** [getgb.o] Error 1
>>>>>>>>>>>
>>>>>>>>>>> This seems to be some 32 vs. 64 bit conflict.
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Chi.Y.Kang" <Chi.Y.Kang at noaa.gov>
>>>>>>>>>>> Date: Thursday, August 2, 2007 2:06 pm
>>>>>>>>>>> Subject: Re: problems compiling on new server
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Give this a try.
>>>>>>>>>>>>
>>>>>>>>>>>> /vg0/ncep/home/ftpncep/bin/g95-i386
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Patrick.OReilly at noaa.gov wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Chi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes why don't we try running the 32 bit binaries and see what
>>>>>>>>>>>>>
>>>>>>>>>>>> happens.
>>>>>>>>>>>>> Let me know when you've had a chance to get them installed.
>>>>>>>>>>>>> Patrick
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>> From: Chi Y Kang <Chi.Y.Kang at noaa.gov>
>>>>>>>>>>>>> Date: Wednesday, August 1, 2007 5:22 pm
>>>>>>>>>>>>> Subject: Re: problems compiling on new server
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> only difference in this version is that is it compiled for
>>>>>>>>>>>>>>
>>>>>>>>>> 64bit
>>>>>>>>>>>>>> but the default interger of 32 rather then 64. I wonder if
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> have
>>>>>>>>>> to
>>>>>>>>>>>>>> define this differently on the "mkieee.f "
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can also just install binaries for 32 bit and run them in
>>>>>>>>>>>>>>
>>>>>>>>>>>> compat
>>>>>>>>>>>>>> mode too. You want to try that?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Justin Cooke wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Chi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have started compiling the same codes that Patrick was
>>>>>>>>>>>>>>>
>>>>>>>>>>>> working
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>> few days ago. This is the code that converts GRIB1 data to
>>>>>>>>>>>>>>>
>>>>>>>>>> GRIB2.>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>> One of the routines calls intrinsic Fortran
>>>>>>>>>>>>>>> function
>>>>>>>>>> "mvbits",
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> but we
>>>>>>>>>>>>>>> are getting an error that the function is not defined by the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> compiler:>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /vg0/ncep/home/ftpncep/grib2/g2lib-1.0.9/libg2.a(mkieee.o):
>>>>>>>>>>>>>>>
>>>>>>>>>> In
>>>>>>>>>>>>>>> function `mkieee_':
>>>>>>>>>>>>>>> /vg0/ncep/home/ftpncep/grib2/g2lib-1.0.9/mkieee.f:89:
>>>>>>>>>>>>>>>
>>>>>>>>>> undefined
>>>>>>>>>>>>>>> reference to `mvbits_'
>>>>>>>>>>>>>>> /vg0/ncep/home/ftpncep/grib2/g2lib-1.0.9/mkieee.f:104:
>>>>>>>>>>>>>>>
>>>>>>>>>>>> undefined
>>>>>>>>>>>>>>> reference to `mvbits_'
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I did a search in
>>>>>>>>>>>>>>> /woc/binary/g95-install/lib/gcc-lib/x86_64-unknown-linux-
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> gnu/4.0.3/libf95.a
>>>>>>>>>>>>>>> for mvbits and see it is defined as "_g95_mvbits".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But when we compile the source code for the library that uses
>>>>>>>>>>>>>>>
>>>>>>>>>>>> mvbits>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> ftpncep at gd0-ncep:~/grib2/g2lib-1.0.9$ strings libg2.a |grep
>>>>>>>>>>>>>>>
>>>>>>>>>> mvbits>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>> it returns:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> mvbits_
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All other intrinsic functions in libg2.a have the proper _g95
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> prefix,
>>>>>>>>>>>>>>> like nint:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _g95_nint_8_r4
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So it looks like when libg2 is begin compiled mvbits is not
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>> being defined. This is how the mkieee.f code is being
>>>>>>>>>>>>>>>
>>>>>>>>>> compiled
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (that
>>>>>>>>>>>>>>> is the part that contains the call to mvbits):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> g95 -c -O3 -g -I . mkieee.f
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm continuing to look but I just wanted to run this by you
>>>>>>>>>>>>>>>
>>>>>>>>>> to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> see if
>>>>>>>>>>>>>>> you had any suggestions.....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Justin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Chi Y. Kang
>>>>>>>>>>>> Contractor
>>>>>>>>>>>> Principal Engineer
>>>>>>>>>>>> Phone: 301-713-3333 x201
>>>>>>>>>>>> Cell: 240-338-1059
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Chi Y. Kang
>>>>>>>>>> Contractor
>>>>>>>>>> Principal Engineer
>>>>>>>>>> Phone: 301-713-3333 x201
>>>>>>>>>> Cell: 240-338-1059
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>
>>> _______________________________________________
>>> Ncep.list.pmb-dataflow mailing list
>>> Ncep.list.pmb-dataflow at noaa.gov
>>> https://lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.pmb-dataflow
>
>
More information about the Ncep.list.pmb-dataflow
mailing list