Hi,

____________(1)______________________

I am using some "Numerical Recipes in C" routines in my C code.
(I am using ludcmp() & lubksb().)
These are used to find inverse of a matrix.

After compiling my c code, I get following warning messages.
I have not understood them at all.
What is the meaning of these and why did they pop up and how to remove them?

nrutil.h is a header file which contains #define statements (besides other things) like:

_________________________(2)_____________

Also, for the same code, I get these warning messages:

In function `main':
warning: assignment from incompatible pointer type
warning: passing arg 1 of `free_vector' from incompatible pointer type

This is fragment of my code corresponding to these 2 warning messages:

Any help will be appreciated.

Regards,
smp

Well, you should not get those messages about nrutil.h -- so, what compiler options are you using?

I build the recipes as a library (if you'd like the Makefiles for both the library and "x" test routines, let me know and I'll make them available for you). The library is named "libnr.a" and installed a local "lib" directory so it is searched by the linker.

Compiling xludcmp.c produces
The message about fmin is because that function is defined in the math library (it really should be removed from nr.h but I haven't gotten around to doing that as yet).

The compiler arguments -FPIC and -m64 are for a 64-bit system; they would not be used in a 32-bit system.

What I'm thinking is that you might have the compiler warnings set? That would be -Wall or something? You probably don't need that level of warnings when using the Recipes and you might consider not using the full-boat warnings.

Hope this helps some.

Yes. I am using -Wall option while compiling. If I do not use -Wall option, I do not get this list of warning messages.

But, I have not understood what you have said before this:

Will you please explain me in detail and step by step, if you do not mind. I am not expert in C nor in linux.

Thanks and Regards,
smp

OK, here goes -- in, pretty much, every operating system there are "libraries" which essentially are a collection of similar compiled functions. In Linux/UNIX these are called libraries where in, say, Microsoft Land they're called dynamic link libraries (DLL). The ones we're concerned about are the Linux ones, so let's talk about them.

If you compile a bunch of source code in a particular way so that you wind up with one or more object files (those are the ".o" files), and none of those object files contains a "main" (C programs will always have a "main" and there can only be one in a given program), you can create an archive file containing all those object files. When you compile a program that requires one or more functions external to the program; i.e., you don't include those functions in the source code, the linking process will search in the archive and select what is needed to form the executable (where you just type the name and hit the return key). How that's done is by including the "-llibname" command line directive; e.g., with the Recipes, you pretty much always are going to include "-lm," which is saying "search in the library (the l) named libm.a (or libm.so). libm.a and libm.so both contain exactly the same object files but the format of libm.a and libm.so are different (.a is static, .so is dynamic and the difference isn't important for this).

All the "system" functions that you commonly use; e.g., printf(), scanf() and so on are kept in system library files, yes, individual files and there are a whole lot of 'em. When you write a C program and place those "#include" directives at the top of the source, that's where you get the function prototype and, when you compile your program, the entire process that winds up with an executable file goes and finds all the stuff it needs to do that -- it's really rather elegant.

Now, Numerical Recipes: all the recipe source code files (not the test or demo programs) can be compiled to object code and that object code can be inserted into a library file that can be searched by a program to locate what are called unsatisfied globals -- if you, say, tried to compile xludcmp.c just by itself, you'd find that ludcmp.o (plus the math functions) would be unsatisfied globals (they'd be missing).

So, what's with make?

The make utility uses a file of instructions, a Makefile, to successfully compile a program. Essentially, the Makefile simply tells the compiler system what's needed to, uh, make an executable program. If you've built any of the utilities that aren't included in your Linux distribution -- the ones where you configure, make, make install -- that's what is going on; configure builds a Makefile containing all the instructions specific to your platform hardware and software.

I've been using the Numerical Recipes (both the C and FORTRAN) since the first editions and long ago (about 20 years or so) created Makefiles for building the library of the Recipes' functions and a separate Makefile for building all the test or demo programs. I'm kind of old-fashioned and I use what's called a Makefile generator to create those (instead of the GNU utilities that create the configure routines). If you'd like to try it, I'll be more than happy to provide the Makefiles (and a little guide for using them) for the second edition of Numerical Recipes (haven't upgraded since, alas, stopped doing heavy math stuff a while ago). One Makefile compiles all the Recipes and creates a library named libnr.a, the other compiles all the test or demo programs to executable programs using libnr.a and any other system libraries (like the math library) where necessary.

I hope the the above is not too confusing; you may want to look at the manual page for ar, used to manage archive files for a little more information.

1 members found this post helpful.

Thank you so much.
Yes. I would like to see your Makefiles (with guide).

Regards,
smp

Hi,

You can download http://ronayne.dyndns.org/downloads/...recipes.tar.gz. It contains two directories, examples and recipes. Each of those directories contain two files, README and Makefile.

If you extract the archives (tar xzvf numerical_recipes.tar.gz), it will create the directories and files; if you do that where you already have a directory named examples and one named recipes (which, if I remember correctly is where the Numerical Recipes source code are found), untaring will simply write the README and Makefile into those directories (try it somewhere else first, say, in /tmp).

Read the README. Edit the Makefile as needed (instructions in the README).

Hope this helps some.

Thanks.

Regards,
smp

Is this solved? Please flag it as such. Thanks.