Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
On 02/16/2010 01:45 PM, John Denker wrote: OK, I think we can put this sub-issue to bed. I fixed it so that compiling and installing simgear no longer requires the OSG or OpenThreads runtime libraries. The *.h header files are still required. This turned out to be easier than I thought it would be. It took hours, not days. The patch can be found at: http://gitorious.org/~jsd/fg/sport-simgear/commits/sport = I still haven't fixed any of the issues over on the FG side of things, and this little patch actually makes that *more* necessary. *Somebody* needs to be doing the OSG checks. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
On 02/08/2010 08:34 AM, Geoff McLane wrote: > you seem to be yelling something. On 02/16/2010 11:47 AM, Geoff McLane wrote: > It seems WHATEVER the reason is, IF it involves > a SimGear AC_CHECK_LIB() then _REMOVE_ the > AC_CHECK_LIB() from SG configure.ac ;=)) > > There is no reason to check 'libraries' on a > 'library' build, point blank! SG is a set of > libraries, and need have _NO_ library checks > to build them! -- Using exclamation points does not make incorrect statements more correct. -- Using all caps does not make incorrect statements more correct. -- Using underlined all caps seems to be going a bit far. -- Accusing other people of yelling is, ummm, inconsistent to say the least. Try setting a good example. We need to distinguish *) what the actual dependencies of simgear are *) what the dependencies should be *) what dependencies are checked by ./configure As previously explained more than once, the fact is, at the moment, several parts of simgear do depend on OpenThreads. It is therefore entirely appropriate for ./configure to check for this, so that if needed, an informative error message can be given to the user. Several people have suggested re-arranging simgear to remove this dependency. If somebody wants to do that, great, please go ahead. After the actual dependency is removed, then it would be appropriate to remove the dependency-check from ./configure. Then and not sooner. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
Geoff McLane wrote: > It seems Erik's previous patch to SG configure.ac > did remove some Apple framework library checks, > but did not go far enough IMHO to REMOVE ALL > AC_CHECK_LIB() in a 'library' build. > > That is, remove the check - > -o "x$ac_cv_lib_OpenThreads_OpenThreadsGetVersion" != "xyes" > and the whole AC_CHECK_LIB() check block preceeding > it! There is one file in SimGear that depends on OpenThreads, thats why the check is there. Granted you will only find out by doing a 'make check'. Erik -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
On Mon, 2010-02-15 at 14:59 -0700, John Denker wrote: > The reason for fussing with SG first is simple: Again, thanks Erik for patching the SG patch ;=)) Have yet to update and try SG again, but... It seems WHATEVER the reason is, IF it involves a SimGear AC_CHECK_LIB() then _REMOVE_ the AC_CHECK_LIB() from SG configure.ac ;=)) There is no reason to check 'libraries' on a 'library' build, point blank! SG is a set of libraries, and need have _NO_ library checks to build them! It seems Erik's previous patch to SG configure.ac did remove some Apple framework library checks, but did not go far enough IMHO to REMOVE ALL AC_CHECK_LIB() in a 'library' build. That is, remove the check - -o "x$ac_cv_lib_OpenThreads_OpenThreadsGetVersion" != "xyes" and the whole AC_CHECK_LIB() check block preceeding it! Or conversely, what is the 'wisdom' for keeping such library checks in SG library build? Any test executables that rely on OSG libraries should be moved to FG, where we _DO_ do copious OSG library checks. John, I will try to get around to testing your patch of your acinclude.m4 patch in FG, where it matters. It looks good on simple inspection... As you may understand, I am all for helping Joe User have an easy life, and have dedicated a big part of my web site to doing just that, building and running FG... and my 'makefg' scripts... so my perspective is definitely Joe User - ME!? ;=)) Regards, Geoff. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
On 02/15/2010 11:53 AM, Geoff McLane wrote:
> Just did a full SG cvs update, and this
> acinclude.m4 patch _BREAKS_ the SG build for me!
OK. It's a bug.
Thanks for testing.
Here's the patch. Please try again.
The reason for fussing with SG first is simple: this
is where Joe User is going to get into trouble. It
doesn't matter how good the FG configuration is if
Joe cannot get to that stage. And trust me, SG
will not build if it cannot find the OpenThreads
libraries, which are bundled in with OSG these days,
and located in lib64/ by default.
A lot of stuff I do makes more sense if you look
at it from the Joe User point of view.
I will fix up the FG side of things eventually.
commit 5764d1b7da5cb25947f6ada47aa45fe6b2272cec
Author: John Denker
Date: Mon Feb 15 14:50:29 2010 -0700
Fix sneaky bug: 'mylibdir' variable getting trampled.
diff --git a/acinclude.m4 b/acinclude.m4
index 889cbf4..0059bbf 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -113,14 +113,14 @@ for subexdir in $subexdirs ; do
dnl On 64-bit machines, if lib64/ exists and is not identical to lib/
dnl then it should be listed here, listed ahead of lib/.
mylibdir64="${exdir}/lib64${subexdir}"
-mylibdir="${exdir}/lib${subexdir}"
+mylibdir32="${exdir}/lib${subexdir}"
if test "x86_64" = $(uname -m) \
- -a ! ${mylibdir64} -ef ${mylibdir} ; then
+ -a ! ${mylibdir64} -ef ${mylibdir32} ; then
wi_EXTRA_LDIR($mylibdir64)
fi
-wi_EXTRA_LDIR($mylibdir)
+wi_EXTRA_LDIR($mylibdir32)
progdir="${exdir}/bin${subexdir}"
wi_EXTRA_PDIR($progdir)
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
On Sun, 2010-02-14 at 15:22 +0100, Erik Hofman wrote: > John Denker wrote: > > In this case it appears that adding about five lines > > of code to acinclude.m4 will remove the need for at > > least five paragraphs of documentation. It turns > > out to be quite possible to each the configuration > > system to search lib64. > > Both patches have been committed to CVS. > Hi John, Erik, Re: README.OSG ` Thank you Erik for adding the README.OSG updates to FlightGear. You might note this file was previously also 'mirrored' in SimGear, but maybe it is sufficient that it is at least in FG. Thanks. Even if I do say so myself, I think it now gives 'quality' information to the user, should they run into an OSG shared library problem. And thank you for adding the patch to FG configure.ac. Now tests/gl-info runs fine. Re: Patching acinclude.m4 Concerning the SG acinclude.m4 changes, I guess I am really misunderstanding something here ;=(( Sorry if this is true... 1. The change has been done only to SimGear acinclude.m4! Why to SimGear? Is there, was there a problem in SimGear? What is the problem being overcome in SG by this patch? I _THOUGHT_ all this discussion was about FlightGear! And the fact that, by default, cmake of OSG, installs the OSG libraries in $prefix/lib64 when in x86_64!!! SimGear is a set of static libraries only, thus NEVER needs to 'find' OSG libraries. Libraries do _NOT_ link with other 'libraries'!!! As far as I can see, NONE of the SG 'test' executables, like decode_binobj, lowtest, socktest, tcp_client, waytest, TestRenderTexture, testserial, etc... require linking with OSG libraries. SG libraries do NOT need OSG libraries... includes, yes, but libraries, no. The problem I read was when LINKING FG, specifically a FG tests program, but it would be the same when later linking fgfs itself, with OSG libraries. How can changes to SG effect this FG link failure? BUT UGH: Just did a full SG cvs update, and this acinclude.m4 patch _BREAKS_ the SG build for me! I do like the more 'informative' output though ;=)) 2. But even if we now modify FG's acinclude.m4 to correctly find OSG libraries in $prefix/lib64, then you only move the problem back to when trying to RUN gl-info, or fgfs, or any others program dependant on OSG shared libraries. So, to 'run' anything which includes these OSG shared libraries, the user must KNOW about one, or all, of :- (a) Using 'export LD_LIBRARY_PATH=...', like export LD_LIBRARY_PATH=/path/to/lib[64][:/other/paths] (b) Making and using a lib -> lib64 link, if the $prefix is unique, and does not contain a 'lib' folder (c) Using /etc/ld.so.conf and ldconfig, to setup the $prefix/lib64 in the ld cache. (d) And maybe other solutions... So yes, such a patch to FG could make the build appear 'easier', but still leaves the 'user' with a later, perhaps bigger problem to overcome ;=((. And again, these user 'options' are now enumerated in the README.OSG. 3. _ALL_ of this can be _AVOIDED_ completely if the user knows about, and uses the OSG cmake option - '-D LIB_POSTFIX=' seemingly the single root cause of ALL THIS!!! Using this puts the OSG shared libraries in the 'standard' place, namely $prefix/lib. If this option is used, then :- (a) SG will build using --with-osg=$prefix to allow it to find OSG $prefix/include. This has never been a problem, has it? (b) FG will build using --with-osg=$prefix to allow it to find _BOTH_ OSG $prefix/include _AND_ equally important, $prefix/lib (c) Executables using OSG shared libraries can be run without any special provision, if OSG installed in /usr/[local/]lib, or with a simple /etc/ld.so.conf change if otherwise, or using LD_LIBRARY_PATH for a temporary solution. All that by adding one parameter to cmake when building OSG libraries from source. Does not seem a _BIG_ thing... 4. While I too thought of, and mentioned 'fixing' the auto-make to deal with this non-standard OSG install into 'lib64', I later canceled it, due to it being only _PART_ of the problem. It does seem cmake OSG is the root cause, and I really question what should be done in FG make process to 'fix' this, other than fully explaining possible 'fixes' in README.OSG, which is now done ;=)) BUT, ok, I too 'like' the idea of improving the FG auto-make process, so added the fixes from SG to FG acinclude.m4, to give it a try... using a scenario where OSG libraries are installed in $prefix/lib64 *** IT FAILED! *** Yes, it got through the FG ./configure --with-osg=$prefix ... but the Makefiles generated FAILED to add a path for the SG, and other libraries. They _DO_ have a path for OSG 'lib64' libraries. So the main link line (truncated) for fgfs was :- g++ -DPKGLIBDIR=\"/home/geoff/fg/fg8/install/fgfs/share/FlightGear\" \ -g -O2 -I/home/geoff/fg/fg8/install/simgear -D_REENTRANT \ -L/home/geoff/fg/fg8/install/OSG282/lib64 -o fgfs bootstrap.o lib
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
John Denker wrote: > In this case it appears that adding about five lines > of code to acinclude.m4 will remove the need for at > least five paragraphs of documentation. It turns > out to be quite possible to each the configuration > system to search lib64. Both patches have been committed to CVS. Erik -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
On 02/12/2010 10:00 AM, Geoff McLane wrote:
>
> RE: README.OSG UPDATE
>
> I have now beefed up the FG README.OSG
> information
>
> I think I have tried to cover everything,
> very carefully!
Thank you for your constructive contributions to the
configuration system, both in terms of debugging the
code and debugging the documentation. I know this is
both tricky and laborious.
As a rule, whenever I see a piece of code that requires
a long stretch of tricky documentation, I have to
suspect that it would be easier and better to upgrade
the code than to upgrade the documentation.
In this case it appears that adding about five lines
of code to acinclude.m4 will remove the need for at
least five paragraphs of documentation. It turns
out to be quite possible to each the configuration
system to search lib64.
I think I've got it to the point where somebody
who wants to compile OSG from source can do so on
a 64-bit machine using the same simple procedures
that have always worked on 32-bit machines. In
simple cases specifying --with-osg=/some/dir will
now suffice.
The attached patch applies on top of the big patch
I submitted about 12 hours ago.
The attached patch contains only a few lines of
"interesting" code. The patch looks bigger than
that because I tried to normalize some of the
indentation and other trivial issues.
commit 237265e977cf775c5adbff813517381a2d4abe3c
Author: John Denker
Date: Fri Feb 12 13:20:13 2010 -0700
Fix it so that configuration works (mostly) as easily on
64-bit machines as on 32-bit machines, even for users who
have compiled OSG from source and need to specify --with-osg=/some/dir.
Also minor cleanup of the source.
Also minor improvements to the logging.
diff --git a/acinclude.m4 b/acinclude.m4
index 851e120..0d645d9 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -23,6 +23,8 @@ if test -r $incdir ; then
fi
echo " + added -I$incdir" 1>&AS_MESSAGE_LOG_FD
fi
+else
+echo " + IDIR is not accessible: '$myincdir'" 1>&AS_MESSAGE_LOG_FD
fi
])
dnl
@@ -49,6 +51,8 @@ if test -r $mylibdir ; then
fi
echo " + added -L$mylibdir" 1>&AS_MESSAGE_LOG_FD
fi
+else
+echo " + LDIR is not accessible: '$mylibdir'" 1>&AS_MESSAGE_LOG_FD
fi
])
dnl
@@ -71,6 +75,8 @@ if test -r $progdir ; then
echo " + appended $progdir to \$PATH"
1>&AS_MESSAGE_LOG_FD
;;
esac
+else
+ echo " + PDIR is not accessible: '$progdir'" 1>&AS_MESSAGE_LOG_FD
fi
])
dnl
@@ -94,23 +100,32 @@ if test "$subexdirs" = "" ; then
subexdirs="-"
fi
for subexdir in $subexdirs ; do
-if test "$subexdir" = "-" ; then
- subexdir=""
-else
- subexdir="/$subexdir"
-fi
-for exdir in $exdirs ; do
- if test "$exdir" != "/usr" || test "$subexdir" != ""; then
- incdir="${exdir}/include${subexdir}"
- wi_EXTRA_IDIR($incdir)
+if test "$subexdir" = "-" ; then
+subexdir=""
+else
+subexdir="/$subexdir"
+fi
+for exdir in $exdirs ; do
+if test "$exdir" != "/usr" || test "$subexdir" != ""; then
+incdir="${exdir}/include${subexdir}"
+wi_EXTRA_IDIR($incdir)
+
+dnl On 64-bit machines, if lib64/ exists and is not identical to lib/
+dnl then it should be listed here, listed ahead of lib/.
+mylibdir64="${exdir}/lib64${subexdir}"
+mylibdir="${exdir}/lib${subexdir}"
+
+if test "x86_64" = $(uname -m) \
+ -a ! ${mylibdir64} -ef ${mylibdir} ; then
+wi_EXTRA_LDIR($mylibdir64)
+fi
- mylibdir="${exdir}/lib${subexdir}"
- wi_EXTRA_LDIR($mylibdir)
+wi_EXTRA_LDIR($mylibdir)
- progdir="${exdir}/bin${subexdir}"
- wi_EXTRA_PDIR($progdir)
- fi
-done
+progdir="${exdir}/bin${subexdir}"
+wi_EXTRA_PDIR($progdir)
+fi
+done
done
])
dnl
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
Hi, Again thank you Erik for updating the configure.ac files... This continues to work fine... RE: README.OSG UPDATE I have now beefed up the FG README.OSG information per the attached patch. I think I have tried to cover everything, very carefully! But someone in the 'know' should check that OSG 2.7.8 is still the earliest acceptable OSG version! Maybe this has changed too! Note, if acceptable, this amended file should also be added to SimGear. Strangely, I tried to experiment with the option advised by cmake, namely :- $ sudo make install_ld_conf BUT 'make' advised no such target exists! And make help does _NOT_ list it as a target ;=(). cmake advises of the target but then does not seem to generate it??? Digging deeper into the OSG source, there is a generated file available for copy :- /packaging/ld.so.conf.d/openscenegraph.conf which shows even if such a make target did existed, and this was copied to /etc/ld.so.conf.d, it would be INCORRECT, not only for my case, where I use a strictly local-to-source install directory, but in _ALL_ cases. It contains the lines - # openscenegraph library configuration /usr/locallib64 which is _REAL_ screwy!!! Surely that should be /usr/local/lib64 But I most certainly do NOT want to get into BUGS in the OSG cmake process... but will try, if I find the time, to send something to their 'bug' list... You will see my amended README.OSG has a note to this effect, at least saying 'If' this target exists... Can others find this 'target'? Anyone tried it? I did experiment a little with adding my own /etc/ld.so.conf.d/openscenegraph.conf file, containing the single line - /home/geoff/fg/fg8/install/OSG282/lib (I had used the '-D LIB_POSTFIX=' on this build) and then tried using - $ sudo ldconfig -v but it seems this ONLY helps at runtime! That is, I could now run 'fgfs', and others, without '$ export LD_LIBRARY_PATH=/path/to/lib' and they would find the OSG shared libraries, and $ ldconfig -p | grep libosg showed these shared libraries now in the cache, but it did _NOT_ help with ./configure AC_CHECK_LIB(osg,osgGetVersion, ,...) I still had to add --with-osg=$prefix for this, which perhaps makes sense... the auto-conf tools do _NOT_ use the ld runtime cache for their library search! Anyway, I hope it is seen fit to add this README.OSG update soonest to FG and SG CVS. RE: FG configure.ac _ALSO_, this diff contains the changes to FG configure.ac to allow for the correct build of tests/gl-info.cxx. This has been discussed before, and I think Jari has tested to MAC host option as well. Regards, Geoff. attached: fg200-diff03.patch Index: README.OSG === RCS file: /var/cvs/FlightGear-0.9/source/README.OSG,v retrieving revision 1.2 diff -u -r1.2 README.OSG --- README.OSG 20 Dec 2008 09:12:31 - 1.2 +++ README.OSG 12 Feb 2010 14:54:18 - @@ -3,8 +3,11 @@ You *must* have OpenSceneGraph (OSG) installed to build this version of FlightGear. -Notice that FlightGear 1.9.0 requires at least version 2.7.8. Using earlier -versions of OSG will yield serious rendering bugs. +Notice that from FlightGear version 1.9.0, OSG version 2.7.8 or later +*must* be used. Using earlier versions of OSG will yield serious +rendering bugs. If you are using an 'older' distribution, this may mean +a suitable version of OSG may not be availble through the usual package +repositories. You can get the latest version of OSG from: @@ -25,3 +28,66 @@ make sudo make install +Also later release versions of OpenSceneGraph can be obtained by +svn, or you can use the OSG development svn 'trunk', but be warned, +OSG is always in heavy development, and at certain moments +in time, it may not compile completely, so, as usual, it is +recommended that you stay with released versions. + +Installation notes: + +In some unix/linux distributions, particularly 64-bit +systems, OSG may install its shared libraries in other than +/usr/lib, /usr/local/lib or $prefix/lib! + +This does not seem to effect binary installation, which is +to $prefix/bin, nor header installation, which remains +$prefix/include. Just the shared libraries, and perhaps +only for 64-bit systems, or higher as, and when available. + +The default is /usr/local/lib64 or $prefix/lib64 in +64-bit systems. This may cause problems with the auto-conf +tools when configuring and compiling FlighGear, since +even using the configure option --with-osg=$prefix +will not 'fix' the problem. + +The are various ways to deal with this, which mainly depend +on whether you just want one version of OSG 'globally' +installed, or desire to be able to build, and run, FlightGear +against 'different' versions of OSG. + +There is a parameter, -D LIB_POSTFIX= or -D LIB_POSTFIX="" +which can be passed to cmake OSG to force the OSG library +installation into the 'standard' "$prefix/lib". + +OSG cmake advises of a post installation step - + $ sudo make install_ld_conf +which, if
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
Geoff McLane wrote: > It _ONLY_ gives an early indication, something which > could have been _SEEN_ had the config.log been read! I > know, the config.log is long and boring, [...] Nah, 'configure' also prints a nicely readable status to STDOUT, so, for these simple cases like OSG libraries not being found you don't even have to browse the boring 'config.log' ;-) > PS: Thanks Martin. Will try the -D LIB_POSTFIX="" > and maybe that is the silver bullet ;=)) It's probably not the silver bullet but at my end it's been serving as a nice and quite 'clean' solution. Apparently at least some of the distribution package manintainers are doing exactly this. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Modifying OSG lib checks in FG configure.ac
Well, it seems there _ARE_ already 8 checks for OSG libraries, but with no action if-found, or if-not-found :- AC_CHECK_LIB(osg,osgGetVersion) AC_CHECK_LIB(osgUtil,osgUtilGetVersion) AC_CHECK_LIB(osgDB,osgDBGetVersion) AC_CHECK_LIB(osgText,osgTextGetVersion) AC_CHECK_LIB(osgGA,osgGAGetVersion) AC_CHECK_LIB(osgViewer,osgViewerGetVersion) AC_CHECK_LIB(osgSim,osgSimGetVersion) AC_CHECK_LIB(osgParticle,osgParticleGetVersion) So if not found the only effect would be an output to config.log of not found... Then for some unknown reason osgFX is added unconditionally!!! LIBS="$LIBS -losgFX $opengl_LIBS" We later do a check for the OSG version header - AC_CHECK_HEADER(osg/Version) and ABORT if this is NOT found, but that is a "$prefix/include" check, not 'lib'. So it seems we only need - (a) osgFX to be checked like the others, (b) put a consequence if found or not found. Ref: AC_CHECK_LIB(library, function, [if-found], [if-not-found], [other-libraries]) In fact, it would seem sufficient to just check the primary 'osg' library, since it would be rare case indeed if it was found, and the others not... but this is debatable... Something like :- OSG_OK="no" then the per host type checks - ... AC_CHECK_LIB(osg,osgGetVersion,[OSG_OK="yes"]) ... Then - if test "$OSG_OK" != "yes"; then echo echo "You *must* have the OSG libraries installed on" echo "your system to build and run FlightGear!" echo "Have they been installed in a 'lib64' folder?" echo echo "Please see README.OSG for more details." echo echo "configure aborted." exit fi And maybe along with this, the README.OSG could be updated, and beefed up with more information, especially about this known 'lib64' cmake install situation. But after doing this I bounce back to the 'problem'. This configure.ac check does _NOT_ in any way fix the 'problem' that OSG cmake can use a non-standard 'lib64' directory. It _ONLY_ gives an early indication, something which could have been _SEEN_ had the config.log been read! I know, the config.log is long and boring, and it not even wholly sufficient to search for 'no', since some no's are ok. But MOST CERTAINLY, when a compile/link error occurs, it should be one of the first files carefully scanned. And to be sure, this is NOT a FG 'configuration snafu' as the earlier subject suggests! HTH Regards, Geoff. PS: Thanks Martin. Will try the -D LIB_POSTFIX="" and maybe that is the silver bullet ;=)) -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
