>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.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly 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.