On Fri, 23 Jul 2004, Peter W. Draper wrote:
> On Thu, 22 Jul 2004, Peter W. Draper wrote:
>
> > Just in case you notice (I hope not they shouldn't effect anything else),
> > I've updated and merged my patches that I've been using to build the
> > various libraries needed for the production of the JNIHDS and JNIAST
> > shareable libraries under MinGW. Using starconf this has actually
> > simplified things somewhat and there are now only significant changes to
> > HDS, PSX and CNF. See the CVS logs for what I've done.
>
PS Does this work on MinGW mean that cygwin is currently a dead duck?
PPS At some point you'll need to drop in an fio variant of fio1_serr.f.
I'm working on that at the moment though (rejigging it to use an include
file generated via errno.h). There is a fundamental problem with FIO in
that the IO error codes are not platform dependent, they're actually
compiler dependent. I'm assuming that when we rebuild fio using xlf all
the I/O error code translation will break. Conversely, the linux and osx
variants will be identical as they currently stand because they are using
g77 error codes (and presumably building on solaris with g77 will be fun
as well since FIO assumes error codes that come from the solaris
compiler). We need to be able to bring in code based on compiler, not just
os.
> Brad, if you've done this you'll need to recompile HDS and any
> applications you've built during that time. I've also noticed that DIPSO
> is currently in some difficulty (it's started picking up the ADAM version
> of MERS after a little change of Tim's), so you should update and rebuild
> that too.
Sorry. That was all the kaplibs_link vs kaplibs_link_adam problem.
>
> Finally, NCAR may be having a shareable library problem, when I run DIPSO
> at present I see the following message:
>
> 0PARAMETER IDENTIFIER - LABEL/NAME.
> ERROR 15 IN AGSETP - LABEL LIST OVERFLOW - SEE AUTOGRAPH SPECIALIST
>
> When I recompile NCAR statically the problem goes away. Can anyone else
> confirm this? Just update, build, install and run "make check" for dipso
> (or snx in fact).
>
Yes. That was happening on tiger team week and is the reason for the
comment on the wiki. I seem to recall statically linking everything except
ncar and snx also worked ! Haven't had time to look into this but it's
clearly a dipso breaker.
Putting a LDFLAGS="-static" in any app that uses snx_link will get us
through if necessary but it's something that sohuld be on the "is broken
and needs fixing" list.
Having a quick look it seems that SNX is using NCAR COMMON block areas
without an accessor. During Tiger Team week I was looking for suspicious
BLOCK DATA rather than the obvious COMMON. Indeed, every common used by
SNX is actually an NCAR common. There are seven common blocks. I don't
know how pervasively SNX fiddles with them.
Can we add "-static" to snx_link? :-)
I note that the NCAR option libraries will have the same problem....
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|