>From: "=?ISO-8859-1?Q?Marianne=20K=F6nig?=" <address@hidden> >Organization: EUMETSAT >Keywords: 200306160918.h5G9IYLd025247 McIDAS-X Linux libf2c.a Hi Marianne, >I am sorry to say that - but it did not workl. I am actually using the >/usr/lib/local/libf2c.a (see my error message below), and this is the only >libf2c I have on my system. This is very strange. The only times I have seen a link failure like the one you sent previously was when the shared f2c library was being searched instead of the static one. MAIN__ is only found in the static library. >I did an ar -t libf2c.a and it listed a main.o as an entry. I have a >feeling it has to do with this underscore business (that for some reason >mcidas expects a main_.o (?)). > >Because: >I also use a c subroutine that my msgsadir.f calls (called read_filelist), and >in the HP source code the routine simply starts with > >void read_filelist_ .... The inclusion of the trailing underscore is typically done for C routines that are callable by Fortran routines since Fortran is typically expecting the trailing underscore. >My Linux then complained that it did not find read_filelist__ (2 underscores), >and I never undrstood where the second udnerscore comes from. Compiler flags can be set to use one or two trailing underscores. >So I simply changed (within my C code) the read_filelist_ to read_filelist__ . I don't think that this is the correct approach. You should change this back to a single trailing underscore. >And after that this complaint about main__ (again 2 underscores) came up. >Any more ideas? Yes, change read_filelist__ back to read_filelist_ and then set the following Unix environment variables: CC=gcc CPPFLAGS=-Df2cFortran FC=mcfc CXX= STRIP=-Wl,-s export CC CPPFLAGS FC CXX STRIP (of course, use the appropriate syntax for the shell you are running in). and then retry your build. Here is the real problem from my end. I do not use the SSEC build procedures, and I rarely use the gcc/f2c/mcfc compiler combination (I did build v2003 on RedHat 7.3 Linux using this combination after our exchange yesterday, and things worked fine). My approach would be to add my own server build to the McIDAS makefile (~mcidas/mcidas2002/src/makefile) and then run 'make' by hand. The problem with this approach is that you are forced into modifying the SSEC makefile each time you upgrade. This can be a problem unless you really know what you are doing. I have to do this anyway, since I have to make lots of modifications to the SSEC distribution to produce my own. A different and better approach would be for you to setup a makefile of your own that would build all of your local code in a separate directory. I helped one of my sites do this in their ~mcidas/mcidas/src directory. I setup their system to install their binaries in the ~mcidas/mcidas/bin directory (and local data files in the ~mcidas/mcidas/data directory). I then had to adjust their PATH to include ~mcidas/mcidas/bin _before_ ~mcidas/bin and to include ~mcidas/mcidas/data in their MCPATH _before_ ~mcidas/data. Now, then can develop their own routines and build them running make by hand: <login as 'mcidas'> cd mcidas/mcidas/src <modify routines as needed; add build of new ones to the Makefile which is in this directory (that I created using ~mcidas/mcidas2002/src/makefile as a guide> make <routine_name.k> >Or how can I change my environment to use the gcc/g77 instead of gcc/f2c/mcfc? If you were using my distribution of McIDAS, this would be done by setting VENDOR= in the makefile to -g77, but the SSEC v2002 version of mccomp.sh is not setup to handle this (I think it is in v2003). I have been working to get the SSEC distribution to look as much like mine as possible. This is a constant struggle, however, since there are different ideas about how things should be done. >I hate myself. You are _so_ close to being done -- really --. Don't despair now! >Another wine for you. Yahoo :-) 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.