I've built the latest CVS on AIX 5 using xlc and xlC compilers. It seems that autoconf 2.57 produces a configure file which looks for a gnu compatable malloc. This means that malloc(0) should return a none Null value. Since the AIX malloc returns null, the configure adds to config.h :
#define HAVE_MALLOC 0 and
#define malloc rpl_malloc
I have done this and would like to contribute the changes to the repository. This includes an additional file src/nco/malloc.c and changes to: Makefile.am Makefile.in
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the patch. No one's posted a patch to the SF patch
tool before. I could not figure out how to view it. Are you
sure it's there? Anyway, Rorik is the person to merge this.
I did manage to give Rorik permission to manage it, assuming
he is better than I at finding it :) Rorik, try accessing
the patch now.
Does the patch have to go into a file called malloc.c, i.e.,
because automake will look for malloc.o? If so, I guess we'll
have to live with the file-namespace pollution.
If not, my preference would be to insert the code in nco_mmr.c/nco_mmr.h.
I just committed changes which ensure that all NCO code calls
either nco_malloc() or nco_malloc_flg() (both in nco_mmr.c)
rather than malloc() directly. It would be nice to keep the
memory-related code together.
Jim, it would be nice if, once this patch is installed, you
could test the 32 and 64 bit ABI's on AIX. See nco/configure.eg for details.
Thanks,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've built but I've been at a loss on how to test. Since I'm behind a firewall I have to go get the nco_tst.nc by hand so I get it and put it in my data directory and ? what next?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Being behind a firewall complicates things.
I guess there's no way of doing a completely successful
and automated ./configure build and test behind a firewall.
Now that you've manually downloaded nco_tst.nc,
I think 'cd nco;make check' will execute the test scripts.
What I'm most interested in is can you get the 64 bit ABI
executables built, linked, and executing with the ./configure
script? I'm also interested in getting nco_c++ built and
tested with ./configure on AIX
For the future, we should move nco_tst.nc into CVS
or create it from scratch during the build in order to make testing behind firewalls possible.
That means that the FTP test in nco_tst.sh should be
allowed to fail rather than just hang.
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It took me a little while to figure out where the patch task stuff was as well. I put the rpl_malloc() function into it's own file nco_malloc.c. It won't work inside nco_mmr.c because AIX machines need to #undef malloc before compiling the rpl_malloc(), but don't want to do that when compiling nco_mmr.c. We could probably make it work somehow if you think it matters, otherwise, there is now a 2-line program in the source tree.
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've now successfully built 32bit and 64bit on AIX5.1 using the configure tools. Here are the grusome details:
After looking at your nco_mmr.c I realized that the
AC_FUNC_MALLOC of configure.in is really pointless. I recomend removing that line from configure.in and removing the patch that started this thread. That is - remove file nco_malloc.c and the change to Makefile.am and Makefile.in
Using
libtool 1.5
automake1.7.5
autoconf 2.57
I built a new configure file.
Then configure using
LDFLAGS=-brtl ./configure
using this LDFLAGS setting triggers the correct configuration of libtool for AIX 5.1 it is needed for the configure step only - not for the make step.
To build the ABI64 I recommend that you set the environment variable OBJECT_MODE=64 rather than messing with -q64 -b64 -X64 nonsense.
Using this method I have been able to build and run ABI32 and ABI64 executables.
For the c++ build xlC fails configure test AC_CXX_HAVE_VALARRAY, I'm still looking into this issue.
It would be really nice to have a suite of tests that goes through each of the executables with some simple application of its test. Is anyone working on or interested in having such a suite?
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for this work. I'm eager to get it integrated. Since you have
access to machines that Rorik does not, I've added you to the NCO
developer list so you can CVS commit the build changes you are making
yourself. Rorik is in charge of the the configure mechanism overall,
especially Linux, but for architecture-specific .configure changes it
makes sense to let people tweak the flags themselves for the machines
they can test. You are now AIX/test guy. Congratulations! Your check
is in the mail...
If you and Rorik use different versions of autotools then you might
generate/commit different ./configure scripts, but you can work
through that problem together. We will sound the alarm if any changes
could negatively impact other OSs.
> After looking at your nco_mmr.c I realized that the
> AC_FUNC_MALLOC of configure.in is really pointless. I recomend removing that
> line from configure.in and removing the patch that started this thread. That
> is - remove file nco_malloc.c and the change to Makefile.am and Makefile.in
If you say so...
> I built a new configure file.
> Then configure using
> LDFLAGS=-brtl ./configure
> using this LDFLAGS setting triggers the correct configuration of libtool for
> AIX 5.1 it is needed for the configure step only - not for the make step.
Fine, please alter nco/configure.eg accordingly whenever you find
optimal switches for configure invocation.
> To build the ABI64 I recommend that you set the environment variable OBJECT_MODE=64
> rather than messing with -q64 -b64 -X64 nonsense.
Ditto.
> Using this method I have been able to build and run ABI32 and ABI64 executables.
Great. When it's seamless, then replace N's with Y's in table in
configure.eg.
> For the c++ build xlC fails configure test AC_CXX_HAVE_VALARRAY, I'm still looking
> into this issue.
Yes, the valarray test is hosed, needs fixing.
> It would be really nice to have a suite of tests that goes through each of the
> executables with some simple application of its test. Is anyone working on
> or interested in having such a suite?
Go for it! bld/nco_tst.sh tests some (all?) of the operators, and
could be used/modified/split up to do what you're suggesting, either
with command line arguments (e.g., nco_tst.sh ncks) or in some fancier
way. And, like I said, the benefits of being able to seamlessly
test NCO from within firewalls outweigh the disadvantages of not
testing the FTP feature in nco_tst.sh. So feel free to add nco_tst.nc
to the CVS repository, or to create it from scratch during the build.
Thanks,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> For the c++ build xlC fails configure test
> AC_CXX_HAVE_VALARRAY, I'm still looking into this
> issue.
The failed program should be in 'config.log'. I got AC_CXX_HAVE_VALARRAY from the autoconf macro archive http://www.gnu.org/software/ac-archive/ If it needs fixing, the archive should be updated as well.
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've now successfully built 32bit and 64bit on AIX5.1 using the configure tools. Here are the grusome details:
After looking at your nco_mmr.c I realized that the
AC_FUNC_MALLOC of configure.in is really pointless. I recomend removing that line from configure.in and removing the patch that started this thread. That is - remove file nco_malloc.c and the change to Makefile.am and Makefile.in
Using
libtool 1.5
automake1.7.5
autoconf 2.57
I built a new configure file.
Then configure using
LDFLAGS=-brtl ./configure
using this LDFLAGS setting triggers the correct configuration of libtool for AIX 5.1 it is needed for the configure step only - not for the make step.
To build the ABI64 I recommend that you set the environment variable OBJECT_MODE=64 rather than messing with -q64 -b64 -X64 nonsense.
Using this method I have been able to build and run ABI32 and ABI64 executables.
For the c++ build xlC fails configure test AC_CXX_HAVE_VALARRAY, I'm still looking into this issue.
It would be really nice to have a suite of tests that goes through each of the executables with some simple application of its test. Is anyone working on or interested in having such a suite?
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just updated configure, configure.in and aclocal.m4 with the changes nessasary for nco_c++ to build on AIX.
I also documented my test in configure.eg.
The other change I had to make was to remove the AC_C_INLINE test. This test causes the AC_CXX_HAVE_VALARRAY
test (and c++ compile in general) to fail on AIX. It doesn't appear to me that nco uses any inline functions so i don't think I broke anything. Please let me know if I've introduced any new problems on other platforms.
(oh and I think I've figured out how not to double post to this forum - sorry about the noise).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the mods. I put the the template commands back in the AIX
section of configure.eg because they are there to for quick
demonstratations of how to configure on all platforms.
I incorporated your recommended changes (I think), yet the configure
build does not get past the link stage when I try it on
babyblue.ucar.edu, an AIX 5.1 machine. You're at NCAR, right?
So you should be able to see what's up.
The output of the scripts is in ~zender/nco, and available over the
web for all platforms at http://dust.ess.uci.edu/nco/rgr in
[configure/config.log/make].powerpc-ibm-aix5.1.0.0.foo.
I append the relevant errors below, looks like libnetcdf.a is not
resolving correctly. No idea why.
The exact commands used to generate this output are now in the
configure.eg file.
Charlie,
I just noticed that you are trying to set -q64 in configure.in but its not working. I use the environment variable
OBJECT_MODE=64 . Also on babyblue you need to specify the CXX=xlC_r and F77=xlf_r or you find g++ and g77.
See babyblue:/ptmp/jedwards/nco for a sucessful example. If you really always want only 64bit builds on aix 5 systems I can look into how to specify that in configure.in
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is my script which successfully builds using both 32 and 64 bit. I looked at what you are trying to do using the netcdf lib to decide 32 vs 64 bit, then passing the -X64 -q64 flags to all the components. But AR and NM are not exported from the configure to the Makefile - I tried adding that part but then they are not exported from the Makefile to the libtool. I think that this method (using the environment variable) is much easier, perhaps we should change the configure.in to fail at line 152 with a message to the effect that the netcdf library was found but could not be linked and you should check the value of the environment variable OBJECT_MODE . Output from the script is in babyblue:~jedwards/nco
#!/bin/sh -x
for obj_mode in 32 64
do
export GNU_TRP=`~/nco/autobld/config.guess`
export OBJECT_MODE=$obj_mode
cd ~/nco;/bin/rm -f *.${GNU_TRP}.foo.$obj_mode;make distclean
LDFLAGS='-brtl' NETCDF_INC='/usr/local/include' NETCDF_LIB=/usr/local/lib${obj_mode}/r4i4 CXX=xlC_r F77=xlf_r CC=xlc_r CPPFLAGS=-I/usr/vacpp/include ./configure --prefix=${HOME}/nco --bindir=${HOME}/nco/bin --datadir=${HOME}/nco/data --libdir=${HOME}/nco/lib --mandir=${HOME}/nco/man > configure.${GNU_TRP}.foo.$obj_mode 2>&1
/bin/cp -f config.log config.log.${GNU_TRP}.foo.$obj_mode
make clean;make > make.${GNU_TRP}.foo.$obj_mode 2>&1
done
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> If you really always want only 64bit builds on aix 5 systems I can
> look into how to specify that in configure.in
Well, we want the user to be able to configure it. I do want 64 bit to
be the default on AIX systems, since I'm not aware of any 32 bit
systems running AIX and NCO. If possible we want to let the user build
32-bit ABI on AIX using the ./configure mechanism because there may
be sites that need that. If OBJECT_MODE is all that's needed, then
rip out -X64 -q64 stuff which was just a hack to begin with.
> Here is my script which successfully builds using both 32 and 64 bit. I looked
> at what you are trying to do using the netcdf lib to decide 32 vs 64 bit, then
> passing the -X64 -q64 flags to all the components. But AR and NM are not exported
> from the configure to the Makefile - I tried adding that part but then they
> are not exported from the Makefile to the libtool. I think that this method
> (using the environment variable) is much easier, perhaps we should change the
> configure.in to fail at line 152 with a message to the effect that the netcdf
> library was found but could not be linked and you should check the value of
> the environment variable OBJECT_MODE . Output from the script is in
> babyblue:~jedwards/nco
It sounds to me like OBJECT_MODE is the way to go for AIX.
Is OBJECT_MODE usable by autotools on non-AIX platforms, or is it AIX specific?
I had never heard of the OBJECT_MODE environment variable before you
mentioned it, so please describe its intended use.
Is CPPFLAGS=-I/usr/vacpp/include needed on all AIX5 builds that use xlC?
i.e., should I add it to bld/Makefile?
Finally, the new ./configure works for you, but not for me on
babyblue (or bluesky, etc.). The only difference I can see is that I
specify --libdir=/home/babyblue/zender/lib/AIX and you have
/usr/local/lib for the corresponding directory. Can you try figuring
this out? Does building in your home directory work for you when you
specify the libraries should be built locally?
My build fails to find netCDF library routines even though I set
NETCDF_LIB='/usr/local/lib64/r4i4' when calling ./configure. It dies with:
< xlc_r -g -qmaxmem=8192 -qlanglvl=extended -brtl -o .libs/ncap ncap_utl.o ncap.o ncap_yacc.o ncap_lex.o -L/usr/
local/lib64/r4i4 -L./.libs -lnco -lm -lC -lnetcdf -Wl,-blibpath:/home/babyblue/zender/lib/AIX:/usr/lpp/xlopt:/usr
/lib/threads:/usr/lib:/lib
< ld: 0711-317 ERROR: Undefined symbol: .nc_inq_libvers
< ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_float
< ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_double
< ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_long
Also, the make output in your directory seems to show that libnco_c++
does not build correctly with autotools. Am I right about this?
If so can you look into that?
Thanks,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> It sounds to me like OBJECT_MODE is the way to go for AIX.
> Is OBJECT_MODE usable by autotools on non-AIX platforms, or is it AIX specific?
> I had never heard of the OBJECT_MODE environment variable before you
> mentioned it, so please describe its intended use.
Its AIX 5 specific. Has two allowed values - 32 and 64 - and is used by any ibm application that cares about whether its reading or writting with ABI32 or ABI64.
> Is CPPFLAGS=-I/usr/vacpp/include needed on all AIX5 builds that use xlC?
> i.e., should I add it to bld/Makefile?
If I didn't use this flag the g++ include files for stdlib were found instead of the xlC include files.
> My build fails to find netCDF library routines
I think that you are still not in the right object mode.
> Also, the make output in your directory seems to show that libnco_c++
> does not build correctly with autotools. Am I right about this?
This is output from an older build - i think the c++ builds okay.
I got inspiration to contact the gnu libtool folks about these problems and am working with them to solve them at that level. Most of these problems are due to that tool not working very well on AIX.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As you can see from the configure.eg, I explicitly set
the OBJECT_MODE when configuring. The only difference
between my configuration and yours, that I can find, is that
I am building everything in my home directory while you
are building the library in /usr/local/lib.
I am glad you are pursuing some upstream fixes.
I hope they propogate quickly into the
build tools available to most people.
OK. I see. configure does not pass OBJECT_MODE to make. It builds as expected now. 'make install' fails
in the symlink stage when the symlinks already exist.
I think it makes sense to add -f flag to ln in ./configure,
or ask the user if he intends to overwrite ncea, ncrcat,
rather than just failing so close to the end.
Would you please make these mods?
Thanks,
Charlie
make install-exec-hook
make[4]: Entering directory `/fs/cgd/home0/zender/nco/src/nco'
ln -s /home/babyblue/zender/bin/AIX/ncra /home/babyblue/zender/bin/AIX/ncea
ln: 0653-421 /home/babyblue/zender/bin/AIX/ncea exists.
Specify -f to remove /home/babyblue/zender/bin/AIX/ncea before linking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've built the latest CVS on AIX 5 using xlc and xlC compilers. It seems that autoconf 2.57 produces a configure file which looks for a gnu compatable malloc. This means that malloc(0) should return a none Null value. Since the AIX malloc returns null, the configure adds to config.h :
#define HAVE_MALLOC 0 and
#define malloc rpl_malloc
As I understand the autoconf documentation, it is your responsibility to provide this rpl_malloc function :
http://www.gnu.org/manual/autoconf/html_node/autoconf_46.html
I have done this and would like to contribute the changes to the repository. This includes an additional file src/nco/malloc.c and changes to: Makefile.am Makefile.in
Hi Jim,
Thanks for the patch. No one's posted a patch to the SF patch
tool before. I could not figure out how to view it. Are you
sure it's there? Anyway, Rorik is the person to merge this.
I did manage to give Rorik permission to manage it, assuming
he is better than I at finding it :) Rorik, try accessing
the patch now.
Does the patch have to go into a file called malloc.c, i.e.,
because automake will look for malloc.o? If so, I guess we'll
have to live with the file-namespace pollution.
If not, my preference would be to insert the code in nco_mmr.c/nco_mmr.h.
I just committed changes which ensure that all NCO code calls
either nco_malloc() or nco_malloc_flg() (both in nco_mmr.c)
rather than malloc() directly. It would be nice to keep the
memory-related code together.
Jim, it would be nice if, once this patch is installed, you
could test the 32 and 64 bit ABI's on AIX. See nco/configure.eg for details.
Thanks,
Charlie
Hi Charlie,
I've built but I've been at a loss on how to test. Since I'm behind a firewall I have to go get the nco_tst.nc by hand so I get it and put it in my data directory and ? what next?
Being behind a firewall complicates things.
I guess there's no way of doing a completely successful
and automated ./configure build and test behind a firewall.
Now that you've manually downloaded nco_tst.nc,
I think 'cd nco;make check' will execute the test scripts.
What I'm most interested in is can you get the 64 bit ABI
executables built, linked, and executing with the ./configure
script? I'm also interested in getting nco_c++ built and
tested with ./configure on AIX
For the future, we should move nco_tst.nc into CVS
or create it from scratch during the build in order to make testing behind firewalls possible.
That means that the FTP test in nco_tst.sh should be
allowed to fail rather than just hang.
Charlie
It took me a little while to figure out where the patch task stuff was as well. I put the rpl_malloc() function into it's own file nco_malloc.c. It won't work inside nco_mmr.c because AIX machines need to #undef malloc before compiling the rpl_malloc(), but don't want to do that when compiling nco_mmr.c. We could probably make it work somehow if you think it matters, otherwise, there is now a 2-line program in the source tree.
rorik
Okay,
I've now successfully built 32bit and 64bit on AIX5.1 using the configure tools. Here are the grusome details:
After looking at your nco_mmr.c I realized that the
AC_FUNC_MALLOC of configure.in is really pointless. I recomend removing that line from configure.in and removing the patch that started this thread. That is - remove file nco_malloc.c and the change to Makefile.am and Makefile.in
Using
libtool 1.5
automake1.7.5
autoconf 2.57
I built a new configure file.
Then configure using
LDFLAGS=-brtl ./configure
using this LDFLAGS setting triggers the correct configuration of libtool for AIX 5.1 it is needed for the configure step only - not for the make step.
To build the ABI64 I recommend that you set the environment variable OBJECT_MODE=64 rather than messing with -q64 -b64 -X64 nonsense.
Using this method I have been able to build and run ABI32 and ABI64 executables.
For the c++ build xlC fails configure test AC_CXX_HAVE_VALARRAY, I'm still looking into this issue.
It would be really nice to have a suite of tests that goes through each of the executables with some simple application of its test. Is anyone working on or interested in having such a suite?
Jim
Hi Jim,
Thanks for this work. I'm eager to get it integrated. Since you have
access to machines that Rorik does not, I've added you to the NCO
developer list so you can CVS commit the build changes you are making
yourself. Rorik is in charge of the the configure mechanism overall,
especially Linux, but for architecture-specific .configure changes it
makes sense to let people tweak the flags themselves for the machines
they can test. You are now AIX/test guy. Congratulations! Your check
is in the mail...
If you and Rorik use different versions of autotools then you might
generate/commit different ./configure scripts, but you can work
through that problem together. We will sound the alarm if any changes
could negatively impact other OSs.
> After looking at your nco_mmr.c I realized that the
> AC_FUNC_MALLOC of configure.in is really pointless. I recomend removing that
> line from configure.in and removing the patch that started this thread. That
> is - remove file nco_malloc.c and the change to Makefile.am and Makefile.in
If you say so...
> I built a new configure file.
> Then configure using
> LDFLAGS=-brtl ./configure
> using this LDFLAGS setting triggers the correct configuration of libtool for
> AIX 5.1 it is needed for the configure step only - not for the make step.
Fine, please alter nco/configure.eg accordingly whenever you find
optimal switches for configure invocation.
> To build the ABI64 I recommend that you set the environment variable OBJECT_MODE=64
> rather than messing with -q64 -b64 -X64 nonsense.
Ditto.
> Using this method I have been able to build and run ABI32 and ABI64 executables.
Great. When it's seamless, then replace N's with Y's in table in
configure.eg.
> For the c++ build xlC fails configure test AC_CXX_HAVE_VALARRAY, I'm still looking
> into this issue.
Yes, the valarray test is hosed, needs fixing.
> It would be really nice to have a suite of tests that goes through each of the
> executables with some simple application of its test. Is anyone working on
> or interested in having such a suite?
Go for it! bld/nco_tst.sh tests some (all?) of the operators, and
could be used/modified/split up to do what you're suggesting, either
with command line arguments (e.g., nco_tst.sh ncks) or in some fancier
way. And, like I said, the benefits of being able to seamlessly
test NCO from within firewalls outweigh the disadvantages of not
testing the FTP feature in nco_tst.sh. So feel free to add nco_tst.nc
to the CVS repository, or to create it from scratch during the build.
Thanks,
Charlie
> For the c++ build xlC fails configure test
> AC_CXX_HAVE_VALARRAY, I'm still looking into this
> issue.
The failed program should be in 'config.log'. I got AC_CXX_HAVE_VALARRAY from the autoconf macro archive http://www.gnu.org/software/ac-archive/ If it needs fixing, the archive should be updated as well.
rorik
Okay,
I've now successfully built 32bit and 64bit on AIX5.1 using the configure tools. Here are the grusome details:
After looking at your nco_mmr.c I realized that the
AC_FUNC_MALLOC of configure.in is really pointless. I recomend removing that line from configure.in and removing the patch that started this thread. That is - remove file nco_malloc.c and the change to Makefile.am and Makefile.in
Using
libtool 1.5
automake1.7.5
autoconf 2.57
I built a new configure file.
Then configure using
LDFLAGS=-brtl ./configure
using this LDFLAGS setting triggers the correct configuration of libtool for AIX 5.1 it is needed for the configure step only - not for the make step.
To build the ABI64 I recommend that you set the environment variable OBJECT_MODE=64 rather than messing with -q64 -b64 -X64 nonsense.
Using this method I have been able to build and run ABI32 and ABI64 executables.
For the c++ build xlC fails configure test AC_CXX_HAVE_VALARRAY, I'm still looking into this issue.
It would be really nice to have a suite of tests that goes through each of the executables with some simple application of its test. Is anyone working on or interested in having such a suite?
Jim
I've just updated configure, configure.in and aclocal.m4 with the changes nessasary for nco_c++ to build on AIX.
I also documented my test in configure.eg.
The other change I had to make was to remove the AC_C_INLINE test. This test causes the AC_CXX_HAVE_VALARRAY
test (and c++ compile in general) to fail on AIX. It doesn't appear to me that nco uses any inline functions so i don't think I broke anything. Please let me know if I've introduced any new problems on other platforms.
(oh and I think I've figured out how not to double post to this forum - sorry about the noise).
Hi Jim,
Thanks for the mods. I put the the template commands back in the AIX
section of configure.eg because they are there to for quick
demonstratations of how to configure on all platforms.
I incorporated your recommended changes (I think), yet the configure
build does not get past the link stage when I try it on
babyblue.ucar.edu, an AIX 5.1 machine. You're at NCAR, right?
So you should be able to see what's up.
The output of the scripts is in ~zender/nco, and available over the
web for all platforms at http://dust.ess.uci.edu/nco/rgr in
[configure/config.log/make].powerpc-ibm-aix5.1.0.0.foo.
I append the relevant errors below, looks like libnetcdf.a is not
resolving correctly. No idea why.
The exact commands used to generate this output are now in the
configure.eg file.
Thanks,
Charlie
zender@bs1201en:~/nco$ make
make all-recursive
make[1]: Entering directory `/fs/cgd/home0/zender/nco'
Making all in src
make[2]: Entering directory `/fs/cgd/home0/zender/nco/src'
Making all in nco
make[3]: Entering directory `/fs/cgd/home0/zender/nco/src/nco'
/bin/sh ../../libtool --mode=link xlc -g -qmaxmem=8192 -qlanglvl=extended -brtl -L/usr/local/lib64/r4i4 -o ncap ncap_utl.o ncap.o ncap_yacc.o ncap_lex.o libnco.la -lm -lC -lnetcdf
xlc -g -qmaxmem=8192 -qlanglvl=extended -brtl -o .libs/ncap ncap_utl.o ncap.o ncap_yacc.o ncap_lex.o -L/usr/local/lib64/r4i4 -L./.libs -lnco -lm -lC -lnetcdf -Wl,-blibpath:/home/bluesky/zender/lib/AIX:/usr/lpp/xlopt:/usr/lib:/lib
ld: 0711-317 ERROR: Undefined symbol: .nc_inq_libvers
ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_float
ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_double
ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_long
ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_short
ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_text
ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_schar
.
.
.
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make[3]: *** [ncap] Error 8
make[3]: Leaving directory `/fs/cgd/home0/zender/nco/src/nco'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/fs/cgd/home0/zender/nco/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/fs/cgd/home0/zender/nco'
make: *** [all] Error 2
Charlie,
I just noticed that you are trying to set -q64 in configure.in but its not working. I use the environment variable
OBJECT_MODE=64 . Also on babyblue you need to specify the CXX=xlC_r and F77=xlf_r or you find g++ and g77.
See babyblue:/ptmp/jedwards/nco for a sucessful example. If you really always want only 64bit builds on aix 5 systems I can look into how to specify that in configure.in
Here is my script which successfully builds using both 32 and 64 bit. I looked at what you are trying to do using the netcdf lib to decide 32 vs 64 bit, then passing the -X64 -q64 flags to all the components. But AR and NM are not exported from the configure to the Makefile - I tried adding that part but then they are not exported from the Makefile to the libtool. I think that this method (using the environment variable) is much easier, perhaps we should change the configure.in to fail at line 152 with a message to the effect that the netcdf library was found but could not be linked and you should check the value of the environment variable OBJECT_MODE . Output from the script is in babyblue:~jedwards/nco
#!/bin/sh -x
for obj_mode in 32 64
do
export GNU_TRP=`~/nco/autobld/config.guess`
export OBJECT_MODE=$obj_mode
cd ~/nco;/bin/rm -f *.${GNU_TRP}.foo.$obj_mode;make distclean
LDFLAGS='-brtl' NETCDF_INC='/usr/local/include' NETCDF_LIB=/usr/local/lib${obj_mode}/r4i4 CXX=xlC_r F77=xlf_r CC=xlc_r CPPFLAGS=-I/usr/vacpp/include ./configure --prefix=${HOME}/nco --bindir=${HOME}/nco/bin --datadir=${HOME}/nco/data --libdir=${HOME}/nco/lib --mandir=${HOME}/nco/man > configure.${GNU_TRP}.foo.$obj_mode 2>&1
/bin/cp -f config.log config.log.${GNU_TRP}.foo.$obj_mode
make clean;make > make.${GNU_TRP}.foo.$obj_mode 2>&1
done
Hi Jim,
> If you really always want only 64bit builds on aix 5 systems I can
> look into how to specify that in configure.in
Well, we want the user to be able to configure it. I do want 64 bit to
be the default on AIX systems, since I'm not aware of any 32 bit
systems running AIX and NCO. If possible we want to let the user build
32-bit ABI on AIX using the ./configure mechanism because there may
be sites that need that. If OBJECT_MODE is all that's needed, then
rip out -X64 -q64 stuff which was just a hack to begin with.
> Here is my script which successfully builds using both 32 and 64 bit. I looked
> at what you are trying to do using the netcdf lib to decide 32 vs 64 bit, then
> passing the -X64 -q64 flags to all the components. But AR and NM are not exported
> from the configure to the Makefile - I tried adding that part but then they
> are not exported from the Makefile to the libtool. I think that this method
> (using the environment variable) is much easier, perhaps we should change the
> configure.in to fail at line 152 with a message to the effect that the netcdf
> library was found but could not be linked and you should check the value of
> the environment variable OBJECT_MODE . Output from the script is in
> babyblue:~jedwards/nco
It sounds to me like OBJECT_MODE is the way to go for AIX.
Is OBJECT_MODE usable by autotools on non-AIX platforms, or is it AIX specific?
I had never heard of the OBJECT_MODE environment variable before you
mentioned it, so please describe its intended use.
Is CPPFLAGS=-I/usr/vacpp/include needed on all AIX5 builds that use xlC?
i.e., should I add it to bld/Makefile?
Finally, the new ./configure works for you, but not for me on
babyblue (or bluesky, etc.). The only difference I can see is that I
specify --libdir=/home/babyblue/zender/lib/AIX and you have
/usr/local/lib for the corresponding directory. Can you try figuring
this out? Does building in your home directory work for you when you
specify the libraries should be built locally?
My build fails to find netCDF library routines even though I set
NETCDF_LIB='/usr/local/lib64/r4i4' when calling ./configure. It dies with:
< xlc_r -g -qmaxmem=8192 -qlanglvl=extended -brtl -o .libs/ncap ncap_utl.o ncap.o ncap_yacc.o ncap_lex.o -L/usr/
local/lib64/r4i4 -L./.libs -lnco -lm -lC -lnetcdf -Wl,-blibpath:/home/babyblue/zender/lib/AIX:/usr/lpp/xlopt:/usr
/lib/threads:/usr/lib:/lib
< ld: 0711-317 ERROR: Undefined symbol: .nc_inq_libvers
< ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_float
< ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_double
< ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_long
Yours works fine here:
> xlc_r -g -qmaxmem=8192 -qlanglvl=extended -brtl -o .libs/ncap ncap_utl.o ncap.o ncap_yacc.o ncap_lex.o -L/usr/
local/lib64/r4i4 -L./.libs -lnco -lm -lC -lnetcdf -Wl,-blibpath:/usr/local/lib:/usr/lpp/xlopt:/usr/lib/threads:/u
sr/lib:/lib
Also, the make output in your directory seems to show that libnco_c++
does not build correctly with autotools. Am I right about this?
If so can you look into that?
Thanks,
Charlie
> It sounds to me like OBJECT_MODE is the way to go for AIX.
> Is OBJECT_MODE usable by autotools on non-AIX platforms, or is it AIX specific?
> I had never heard of the OBJECT_MODE environment variable before you
> mentioned it, so please describe its intended use.
Its AIX 5 specific. Has two allowed values - 32 and 64 - and is used by any ibm application that cares about whether its reading or writting with ABI32 or ABI64.
> Is CPPFLAGS=-I/usr/vacpp/include needed on all AIX5 builds that use xlC?
> i.e., should I add it to bld/Makefile?
If I didn't use this flag the g++ include files for stdlib were found instead of the xlC include files.
> My build fails to find netCDF library routines
I think that you are still not in the right object mode.
> Also, the make output in your directory seems to show that libnco_c++
> does not build correctly with autotools. Am I right about this?
This is output from an older build - i think the c++ builds okay.
I got inspiration to contact the gnu libtool folks about these problems and am working with them to solve them at that level. Most of these problems are due to that tool not working very well on AIX.
Hi Jim,
As you can see from the configure.eg, I explicitly set
the OBJECT_MODE when configuring. The only difference
between my configuration and yours, that I can find, is that
I am building everything in my home directory while you
are building the library in /usr/local/lib.
I am glad you are pursuing some upstream fixes.
I hope they propogate quickly into the
build tools available to most people.
Charlie
cd ~/nco;/bin/rm -f *.${GNU_TRP}.foo;make distclean
CC='xlc_r' CPPFLAGS='-I/usr/vacpp/include' CXX='xlC_r' LDFLAGS='-brtl' NETCDF_INC='/usr/local/include' NETCDF_LIB='/usr/local/lib64/r4i4' OBJECT_MODE='64' ./configure --prefix=${HOME} --bindir=${MY_BIN_DIR} --datadir=${HOME}/nco/data --libdir=${MY_LIB_DIR} --mandir=${HOME}/nco/man > configure.${GNU_TRP}.foo 2>&1
/bin/cp -f config.log config.log.${GNU_TRP}.foo
make clean;make > make.${GNU_TRP}.foo 2>&1
scp configure.${GNU_TRP}.foo config.log.${GNU_TRP}.foo make.${GNU_TRP}.foo dust.ess.uci.edu:/var/www/html/nco/rgr
you need to have the object mode set when you make as well.
OK. I see. configure does not pass OBJECT_MODE to make. It builds as expected now. 'make install' fails
in the symlink stage when the symlinks already exist.
I think it makes sense to add -f flag to ln in ./configure,
or ask the user if he intends to overwrite ncea, ncrcat,
rather than just failing so close to the end.
Would you please make these mods?
Thanks,
Charlie
make install-exec-hook
make[4]: Entering directory `/fs/cgd/home0/zender/nco/src/nco'
ln -s /home/babyblue/zender/bin/AIX/ncra /home/babyblue/zender/bin/AIX/ncea
ln: 0653-421 /home/babyblue/zender/bin/AIX/ncea exists.
Specify -f to remove /home/babyblue/zender/bin/AIX/ncea before linking.