20040723: McIDAS-X v2004 build problems on OSF/1 4.0F

>From: "Tonkin, Martha E." <address@hidden>
>Organization: Northrop Grumman
>Keywords: 200407231411.i6NEBFaW018 696 McIDAS-X VERSION.TXT

Martha, Martha, Martha...

>Thanks for this.  Sorry to be the bearer of bad news, but...

Why couldn't this be a cheery note saying that all is well ;-)

>While our Linux build went okay, I have since
>tried to build on our Compaq Alpha with vendor compilers - 
>OSF UNIX 4.0f, Compaq C 6.4, Compaq Fortran 5.2

We no longer have an OSF/1 4.0x machine in house, so I was unable to
test on it before the release.  I did test extensively on 'Compaq Tru64
UNIX V5.1B (Rev. 2650)', so the problem you are having must be related
to the older version of OSF/1.

>A couple of difficulties I fixed - we needed a higher
>version of libtiff than what was installed, so I downloaded
>and installed the correct version with no problem.

Can you tell me exacly whic version of libtiff you ended up using?
If I can get it to build successfully on all of the platforms I
have to test on, I will probably upgrade the version in the distribution.

>The code in colorutil.f wouldn't compile, as a character
>variable was being initialized with '' to indicate the null
>string.  I changed that so that the variable was initialized
>with char(0) and that worked.

Are you referring to the setting of 'syntax' in 'data' statements?
Here are the two occurrances that I see of strings being set with
"''":

line 138:
        data syntax/'','','','','','','','','',''/

line 292:
        data syntax/'','','','','','','','','',''/

Was your solution in both cases:

        data syntax/10*char(0)/

>The stopper is in linking mcimage.  I am attaching the
>makelog and a file containing the env variables for
>the build.

makelog.mcidas2004:

 ...

>./mccomp -O -s -vendor -o mcimage mci.o mci_brie.o mci_buff.o mci_cmap.o 
>mci_com
>b.o mci_cpfl.o mci_curs.o mci_evnt.o mci_frfl.o mci_glbl.o mci_rsrc.o 
>mci_updt.o
> mci_visl.o mci_nvpp.o -L. -lmcidas -lXext -lX11
>mccomp: Using default optimizations
>f77 -s -O -o mcimage mci.o mci_brie.o mci_buff.o mci_cmap.o mci_comb.o 
>mci_cpfl.
>o mci_curs.o mci_evnt.o mci_frfl.o mci_glbl.o mci_rsrc.o mci_updt.o mci_visl.o 
>m
>ci_nvpp.o -L. -lmcidas -lXext -lX11 -nofor_main -lm
>ld:
>Unresolved:
>a_
>fort: Severe: Failed while trying to link.
>link    mcimage:                FAILED

OK.  I looked at your makelog output and am now trying to determine which
routine is calling the 'a_' entry point that is not being found...
the entry point is listed as being called from mci_evnt.o:

% nm mci_evnt.o

Name                                    Value        Type       Size

 ...

_fpdata                          | 0000000000000000 | U | 0000000000000000
a_                               | 0000000000000000 | U | 0000000000000008
check_for_changed_frame          | 0000000000000000 | U | 0000000000000008

 ...

The funny thing is that I don't see where this is actually called in
mci_evnt.c!?

'a_' should be the entry point created from the Fortran routine a.for.
This routine is put into libmcidas.a, so the link step not finding it
is very strange.

Can you check the following:

- there is an a.o in ~/mcidas2004/src
- a.o is included in libmcidas.a:

<as 'mcidas'>
cd ~/mcidas2004/src
nm libmcidas.a | grep a_

If you don't find the 'a_' entry point in libmcidas.a even though the
object file exists in the src directory, it means that 'ar' did not
correctly add the a.o object to libmcidas.a.  This is what I am betting
happened.

One "solution" would be:

touch a.o
make libmcidas.a
make mcx

Now, if the problem really is that a.o wasn't added to libmcidas.a,
then it is likely that other routines will come up missing as well.
The solution in each case would be the same as above.

By the way, the failure to add all object modules to the library is a
problem under OSF/1; we have run this problem with multiple applications
we support.

>Thanks, and have a good weekend.

Please let me know if you find that your libmcidas.a did not have
the a_.o module in it, or if your problem looks like something
different.  Also, please tell me the approach you took to modifying
colorutil.for.  Thanks!

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.