This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Jake Wimberley <address@hidden> >Organization: Mississippi State University >Keywords: 200504230114.j3N1E5tp014199 McIDAS Debian libsdi.a Hi Jake, >Thank you for your prompt attention to my problem. No worries. >I initially tried >deleting and recreating libsdi.a with make, like you suggested. >However, this did not completely populate the library with the object >files you listed. (I think it stopped after swap2.o.) So I tried your >second suggestion, to add them by hand. I verified that the files were >in the library with the nm command, and it showed the full list of >object files. I then tried 'make mcx VENDOR=-g77' and it immediately >restarted with 'decoder' but gave the same error it did before, and >exited (output in the makelog looks identical to what it did before). I >noticed it said > >decoder.o(.text+0x17b3): In function `end_of_line': >: undefined reference to `wnvblk_' > >so I ran the command: > >nm libsdi.a | grep wnvblk_ > >and it returned: > >U wnvblk_ I just checked libsdi.a built on one of our Fedora Core 3 Linux systems and see that all that is there is a reference to wnvblk_. Closer inspections shows that wnvblk_ is supposed to be included in libmcidas.a, not libsdi.a. This tells me that your libmcidas.a is not complete probably for the same reason that libsdi.a wasn't. Try remaking libmcidas.a: <as 'mcidas'> cd ~mcidas/mcidas2004/src rm libmcidas.a make libmcidas.a VENDOR=-g77 >According to the manpage for nm, the 'U' means that this symbol is >undefined. That is correct. What is in libsdi.a is a reference to the wnvblk_ entry point which should be located in libmcidas.a. >I don't know anything about libraries or the make utility, >but is there something wrong with my system, causing this to remain >undefined when it should not? I am suspicious of the clock having been set during the build process causing one or more object files to not be added to libmcida.a. >Do I need to somehow restart compiling >McIDAS from the beginning? Removing libmcidas.a and making it should work. If it doesn't, I would start from the beginning: <as 'mcidas'> cd ~mcidas/mcidas2004/src make clobber make mcx VENDOR=-g77 >The version of make I have is the latest available (3.80). Do you have >info on the patch the Slackware user employed to solve this problem? Unfortunately, no. >One more thing: I have an older laptop running RedHat 8.0. Is it >possible to compile all or part of the software on that machine, to >avoid all these errors, and then move the compiled files to my Debian >system? I have been working with another site this morning on building the ldm-mcidas decoders under the latest Debian release since the binaries built under Fedora Core did not work. Because of this I would have to believe that a build under RH 8 would not work/work properly on your Debian machine. >Again, thank you for your help... I look forward to using McIDAS when I >complete the installation. Let's hope remaking libmcidas.a does the trick for you. >Regards Cheers, Tom -- 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.