Richard Hornby wrote: > I have also tried searching for sg_geodesy.cxx with the same result > - apparently only one installation on /usr/local/.. lib ..include > and ..source (orig download).
That's a source file; but you're problem is with the linker. You should be looking for the "libsgmath.a" that contains the compiled results. > Next question could be - how to find out (command line) whether > there is any other version of SG present anywhere? On most distros, "locate libsg" should work, I believe. Another good trick is posting the linker command that is producing the error. Here's a dissection of a fgfs linkage from my own machine, so that you can follow along and compare with yours. My apologies in advance if some of this stuff is review. But many, if not most, of the build errors reported on this list could be solved with a quick tutorial on how to read a linker error. :) Ignore the commentary and extra line endings, obviously. It starts with a compiler front end. FlightGear uses "g++", other projects you see might use "gcc" (even for C++ programs sometimes) or the lower-level "ld" linker: g++ A few generic arguments appear to be generated by the Makefile (in this case: optimizer flag, debug flag, and a preprocessor define), which are ignored by the linker: -O2 -g -DPKGLIBDIR=\"/home/andy/fg/lib/FlightGear\" Some library path directives. Pay close attention to these: they are the directories where the linker will search first (!) for libraries before looking in the system standard places (/lib, /usr/lib, sometimes /usr/local/lib). -L/home/andy/fg/lib -L/usr/X11R6/lib [Note that "/home/andy/fg/lib" appears first here: this comes from the --prefix argument that I pass to configure, and is the reason why my builds are robust in the face of junk that might accumulate in /usr/local.] Object files, which are the result of invoking the compiler on a source file. FlightGear actually passes only one to the final link: bootstrap.o Lots and lots of static libraries; basically one per directory in the FlightGear (but not simgear or plib!) build tree. These have their entire contents linked into the final executable, and work essentially just like .o files when used in this manner. I'm only showing two here for brevity: ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a Lots and lots of external library references. A "-lFOO" argument tells the linker to search for missing functions in a library named "libFOO.a" (or .so, for dynamic libraries) in one of the directories specified by the -L arguments, and if it can't find it there in one of the system library directories. This is where you'll find references to the simgear library that you're having trouble with. You'll also see the Plib libraries appear in these arguments, along with system stuff like the X11 libraries, OpenGL, math library, etc... Again, most of these have been omitted for clarity: -lsgclouds3d -lsgephem And that's it. So if you find a missing symbol, you basically work backwards through the build to find where the problem is. The symbol you are looking for is, if I remember correct, defined in sg_geodesy.cxx. Examining the SimGear source shows you that this file lives in the "math" subdirectory, so a reasonable guess is that this should be picked up as part of the "-lsgmath" in the final link, and therefore that it lives in a "libsgmath.a" somewhere in either one of directories specified with -L, or one of the system library directories. Hunt down this file, kill it, and rebuild SimGear. Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
