Re: [Flightgear-devel] configuration snafu
On 02/12/2010 01:34 AM, I wrote: I haven't yet made the corresponding fixes to the FG side of things. Well, I finally got around to it. The patch can be found in the usual place: http://gitorious.org/~jsd/fg/sport-model/commits/sport The commit message says: Fix bug: substrings in LDFLAGS Fix bug: substrings in CPPFLAGS Fix bug: now check libraries (not just headers) for plib. 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. Check for working CXX compiler. More informative error messages. Spelling. Slightly more informative logging. More parallel to SimGear version. == I also ported some of the better ideas from the FG side back to the SG side: http://gitorious.org/~jsd/fg/sport-simgear/commits/sport = For today, the headline is that I've finally got it to the point where I can do make distclean ; make for SG and FG and the whole thing compiles without so much as a warning ... and without requiring 64-bit users to say any weird incantations over the compile scripts. The same procedures that have always worked on 32-bit machines now work on 64-bit machines, AFAICT. There are still major weaknesses in the configure/build system. Some things that never worked right (on 32-bit machines or otherwise) still don't work. I will discuss those in a separate thread. And I'll wait a while before discussing them, so nobody will get confused about which bug is which. There sure was a big nest of bugs in acinclude.m4. It's funny how when those get fixed, the issues that some people tried to call a bug between keyboard and chair and an unfortunate mistake aren't problems anymore. And there's much less need for new, arcane documentation. As soon as these fixes get committed, I will consider the 64-bit configuration snafu a closed issue. Things are definitely moving in the right direction. -- 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] configuration snafu
On 02/09/2010 03:08 AM, Erik Hofman wrote:
I've updated configure of both FlightGear and SimGear to bail out if the
OpenScenegraph libraries are not found.
Thanks! That is a significant improvement.
That helped directly ... and also helped indirectly,
by giving me a valuable clue about how to fix some
of the other bugs in the autoconfiguration setup.
The commit message should be self-explanatory.
This deals with the SG side of things, which is
where Joe User will usually first encounter
problems. I haven't yet made the corresponding
fixes to the FG side of things.
commit 4eb51bb90f4e8c2ca9842ad248b5e0eb57e400f7
Author: John Denker j...@av8n.com
Date: Fri Feb 12 01:25:25 2010 -0700
Fix bug: substrings in LDFLAGS
Fix bug: substrings in CPPFLAGS
Fix bug: now check libraries (not just headers) for plib.
More informative error messages.
Spelling.
Slightly more informative logging.
diff --git a/acinclude.m4 b/acinclude.m4
index 9e46179..851e120 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -6,19 +6,23 @@ dnl
AC_DEFUN([wi_EXTRA_IDIR], [
incdir=$1
if test -r $incdir ; then
- case $CPPFLAGS in
- *-I${incdir}*)
- # echo+ already had $incdir 16
- ;;
- *)
- if test $CPPFLAGS = ; then
- CPPFLAGS=-I$incdir
- else
- CPPFLAGS=$CPPFLAGS -I$incdir
- fi
- echo+ found $incdir 16
- ;;
- esac
+already=
+for CPPflag in $CPPFLAGS ; do
+ if test _$CPPflag = _-I${incdir} ; then
+already=yes
+break
+fi
+done
+if test -n $already ; then
+echo+ already had -I$incdir 1AS_MESSAGE_LOG_FD
+else
+if test $CPPFLAGS = ; then
+CPPFLAGS=-I$incdir
+else
+CPPFLAGS=$CPPFLAGS -I$incdir
+fi
+echo+ added -I$incdir 1AS_MESSAGE_LOG_FD
+fi
fi
])
dnl
@@ -28,19 +32,23 @@ dnl
AC_DEFUN([wi_EXTRA_LDIR], [
mylibdir=$1
if test -r $mylibdir ; then
- case $LDFLAGS in
- *-L${mylibdir}*)
- # echo+ already had $mylibdir 16
- ;;
- *)
- if test $LDFLAGS = ; then
- LDFLAGS=-L$mylibdir
- else
- LDFLAGS=$LDFLAGS -L$mylibdir
- fi
- echo+ found $mylibdir 16
- ;;
- esac
+already=
+for LDflag in $LDFLAGS ; do
+ if test _$LDflag = _-L${mylibdir} ; then
+already=yes
+break
+fi
+done
+if test -n $already ; then
+echo+ already had -L$mylibdir 1AS_MESSAGE_LOG_FD
+else
+if test $LDFLAGS = ; then
+LDFLAGS=-L$mylibdir
+else
+LDFLAGS=$LDFLAGS -L$mylibdir
+fi
+echo+ added -L$mylibdir 1AS_MESSAGE_LOG_FD
+fi
fi
])
dnl
@@ -50,12 +58,9 @@ dnl
AC_DEFUN([wi_EXTRA_PDIR], [
progdir=$1
if test -r $progdir ; then
- case $PATH in
- *:${progdir}*)
- # echo+ already had $progdir 16
- ;;
- *${progdir}:*)
- # echo+ already had $progdir 16
+ case :$PATH: in
+ *:${progdir}:*)
+ echo+ already had $progdir in \$PATH
1AS_MESSAGE_LOG_FD
;;
*)
if test $PATH = ; then
@@ -63,7 +68,7 @@ if test -r $progdir ; then
else
PATH=$PATH:$progdir
fi
- echo+ found $progdir 16
+ echo+ appended $progdir to \$PATH
1AS_MESSAGE_LOG_FD
;;
esac
fi
diff --git a/configure.ac b/configure.ac
index 710a42f..38ae49f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -437,11 +437,18 @@ esac
AM_CONDITIONAL(HAVE_FRAMEWORK_PLIB, test x$ac_cv_framework_PLIB != x)
AC_CHECK_HEADER(plib/ul.h)
-if test x$ac_cv_header_plib_ul_h != xyes; then
+
+AC_CHECK_LIB(plibul,ulInit)
+if test x$ac_cv_header_plib_ul_h != xyes \
+ -o x$ac_cv_lib_plibul_ulInit != xyes ; then
echo
echo You *must* have the plib library installed on your system to build
echo SimGear!
echo
+echo LIBS: '$LIBS'
+echo LDFLAGS: '$LDFLAGS'
+echo CPPFLAGS: '$CPPFLAGS'
+echo
echo Please see README.plib for more details.
echo
echo configure aborted.
@@ -507,15 +514,22 @@ case ${host} in
fi
;;
esac
+
AM_CONDITIONAL(HAVE_FRAMEWORK_OSG, test x$ac_cv_framework_osg != x)
AC_CHECK_HEADER(osg/Version)
+
if test x$ac_cv_header_osg_Version != xyes -o
Re: [Flightgear-devel] configuration snafu
Jari Häkkinen wrote:
I had to remove one line in the simgear/configure.ac to get through
compilation:
@@ -497,7 +509,6 @@ case ${host} in
dnl instead of OSG frameworks on Mac OS X
dnl
AC_CHECK_LIB(OpenThreads,OpenThreadsGetVersion)
-LDFLAGS=$LDFLAGS -L$with_osg
fi
;;
*)
The problem is that -L$with_osg will evaluate to a plain -L resulting in
linker issues during build.
Odd, that part was hardly touched but I've removed it.
Thanks for the report.
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] configuration snafu
Do we not support the --with-osg=/path on the mac platform?
Regards,
Curt.
On Wed, Feb 10, 2010 at 2:11 AM, Erik Hofman wrote:
Jari Häkkinen wrote:
I had to remove one line in the simgear/configure.ac to get through
compilation:
@@ -497,7 +509,6 @@ case ${host} in
dnl instead of OSG frameworks on Mac OS X
dnl
AC_CHECK_LIB(OpenThreads,OpenThreadsGetVersion)
-LDFLAGS=$LDFLAGS -L$with_osg
fi
;;
*)
The problem is that -L$with_osg will evaluate to a plain -L resulting in
linker issues during build.
Odd, that part was hardly touched but I've removed it.
Thanks for the report.
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
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
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] configuration snafu
Curtis Olson wrote: Do we not support the --with-osg=/path on the mac platform? As far as I know it should. 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] configuration snafu
On Wed, Feb 10, 2010 at 7:13 AM, Erik Hofman wrote: Curtis Olson wrote: Do we not support the --with-osg=/path on the mac platform? As far as I know it should. Ok, I probably should have looked at the patch in the larger framework. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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] configuration snafu
Erik Hofman wrote: leee wrote: But isn't one of the tasks of ./configure to test that it can find the libs it needs, and isn't this the real problem? Is it not the case that ./configure has run ok, presumably believing that it has found the libs it needs, but then generated a makefile that fails because it can't find them? That was what I thought the problem was. Using non-standard configurations is far from forbidden on linux; that's why there are options (parameters) to override normal defaults, but ./configure should be checking for consistency and failing when it finds inconsistency, not giving the appearance that all is well. Agreed. I'll see if I can fix it somewhere this week (unless someone else beats me to it). I've updated configure of both FlightGear and SimGear to bail out if the OpenScenegraph libraries are not found. SimGear has a simple check for OpenThreads and OSG version number and a more extensive error report. FlightGear checks for every required library separately. I did comment out some lines for MacOS framework users in SimGear because I don't think they are needed there. Please report if I was wrong. Erik -- 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
Re: [Flightgear-devel] configuration snafu
Hi John, Erik, Jari, Sid, Curt, Csaba, et al
Thanks Erik. cvs updated, and all works in
my Ubuntu 64-bits... and remember I use
a 'non-standard' local prefix OSG install,
so I can link and run against different
OSG versions at will...
Your addition of -
AC_CHECK_LIB(osg,osgGetVersion, ,
[AC_MSG_ERROR(OpenSceneGraph library not found.)],)
etc for each OSG library looks great, and glad you
brought osgFX in from the cold ;=)).
Of course John, and perhaps others, will feel -
OpenSceneGraph library not found.
is too brief, not informative enough, does not
really 'help' with the problem, will leave Joe
User in the cold ;=)), but I think it is fine,
and to the point.
And to those who MAY forget, or not know,
or understand, after this cvs update you
_MUST_ start with the autogen.sh step, to
re-generate the 'configure' script.
In my case, to be REAL SURE I am using the
new stuff, I do, in fgfs/source :-
$ rm -vf configure
$ rm -r -vf autom4te.cache
$ rm -vf config.log
$ rm -vf Makefile
because I have been caught out before ;=))
Jari, I too would like to add more
information in the summary at the end of
FG configure.ac. And most certainly, when
I have a problem, that is sometimes how I
track it down. But in general there seems
some resistance, reluctance to do this...
To be fair, we do have much MORE info
there than I see in many, many other .ac
(or .in) files...
Sid, I think you would need to use -
sudo make install_ld_conf
which adds an openscenegraph.conf file to
the /etc/ld.so.conf.d folder, with the line -
${CMAKE_INSTALL_PREFIX}lib${LIB_POSTFIX}
but have never tried this...
John, so all is revealed ;=))
Q: Why you would point out a problem in
linking in FG tests and then look in
simgear's config.log?
Your page item :-
http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit
is about linking the 'tests/est-epsilon' binary.
This is only in flightgear... look in FG,
specifically fgfs/source/config.log!
In general -
(a) Do NOT confuse header (include) checks
with library function (lib) checks. They are
unrelated, and look in different places.
(b) Do NOT confuse compiling/linking a
'library' - simgear, with compiling/linking
an executable - fgfs, est-epsilon, etc. There
are some BIG differences.
As Csaba points out, while building a libraries,
like SG, only the 'includes' are needed. Libraries
do not 'link' with libraries. The libraries are only
needed for the final binary executable, fgfs,
tests, etc linking.
And of course, if they are 'shared' libraries,
as opposed to 'static' libraries, then they will
also need to be found at execution runtime...
$ export LD_LIBRARY_PATH=/path/to/lib[:/other/paths]
can be used to expand the search for the 'shared'
libraries, or, as mentioned, more permanently
through the ld.so.conf.d folder...
It is clear the OSG install, installs its
headers in the native, standard, (correct) place -
$prefix/include. So that is ok. They are
found...
And all this has only been about is the fact
that it installs its libraries in a non-native,
non-standard place, $prefix/lib64! But can
be instructed _NOT_ to do this with a cmake
config option -D LIB_POSTFIX=
So, in your case you are pointing out that the
OSG headers can be found. Never said they couldn't.
We only search for one OSG header in both SG FG
configure.ac, and that is the osg/Version header.
eg - AC_CHECK_HEADER(osg/Version)
My statement was only about finding the OSG
_LIBRARIES_, only in FG configure.ac... so will
NOT repeat what is true ;=))
Maybe I have overlooked something ...
Hell YES!
but IMHO whatever it is, Joe User is likely
to overlook it also.
As you suggested, do _NOT_ be so quick to put
Joe User down ;=)) He may be smarter than you
think.
I hope this closes this 'heavy' issue ;=))
Regards,
Geoff.
--
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
Re: [Flightgear-devel] configuration snafu
On 2010-02-09 11.08, Erik Hofman wrote:
Erik Hofman wrote:
I've updated configure of both FlightGear and SimGear to bail out if the
OpenScenegraph libraries are not found. SimGear has a simple check for
OpenThreads and OSG version number and a more extensive error report.
FlightGear checks for every required library separately.
I did comment out some lines for MacOS framework users in SimGear
because I don't think they are needed there. Please report if I was wrong.
I had to remove one line in the simgear/configure.ac to get through
compilation:
@@ -497,7 +509,6 @@ case ${host} in
dnl instead of OSG frameworks on Mac OS X
dnl
AC_CHECK_LIB(OpenThreads,OpenThreadsGetVersion)
-LDFLAGS=$LDFLAGS -L$with_osg
fi
;;
*)
The problem is that -L$with_osg will evaluate to a plain -L resulting in
linker issues during build.
Otherwise the changes works for me on a mac setup with no use of OSG
frameworks.
Jari
--
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] configuration snafu
On Saturday 06 February 2010 21:29:23 Csaba Halász wrote: Well, I still think the sensible thing is to expect *native* libraries in /lib, whatever native may be. If you are on 64 bit, that means 64 bit libraries go into /lib and not /lib64. The only situation I would expect /lib64 is if I am on a 32 bit system. If I am sitting on a 64 bit machine and I need 32 bit libraries, I put the 32 bit libraries elsewhere separated from my native libs (which is what debian does - you get /lib32). On x86_64, _both_ 32 and 64 bit are native. So it's a pretty arbitrary choice, which libraries you put in lib and if you have an accompanying lib32 or lib64 directory. openSUSE for example puts 32 bit libs in lib and has lib64 directories which has the nice advantage, that there has never been a compatibility problem. Running 32 bit Java/Flash/wine/... on an otherwise 64 bit system is a non-issue. No chroot or workarounds like that needed. I only could wonder when I read about problems, why distributions would do that to their users... Stefan -- 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
Re: [Flightgear-devel] configuration snafu
On Mon, 2010-02-08 at 10:30 +0100, Stefan Seifert wrote: On Saturday 06 February 2010 21:29:23 Csaba Halász wrote: Well, I still think the sensible thing is to expect *native* libraries in /lib, whatever native may be. If you are on 64 bit, that means 64 bit libraries go into /lib and not /lib64. The only situation I would expect /lib64 is if I am on a 32 bit system. If I am sitting on a 64 bit machine and I need 32 bit libraries, I put the 32 bit libraries elsewhere separated from my native libs (which is what debian does - you get /lib32). On x86_64, _both_ 32 and 64 bit are native. So it's a pretty arbitrary choice, which libraries you put in lib and if you have an accompanying lib32 or lib64 directory. openSUSE for example puts 32 bit libs in lib and has lib64 directories which has the nice advantage, that there has never been a compatibility problem. Running 32 bit Java/Flash/wine/... on an otherwise 64 bit system is a non-issue. No chroot or workarounds like that needed. I only could wonder when I read about problems, why distributions would do that to their users... Stefan I think this touches the real question - what does 'native' mean? I do not particularly agree that on x86_64 _both_ 32 and 64 are 'native'. Native should mean 64-bits, in a 64-bit system, and thus /usr/lib should contain (only or at least mainly) 64-bit libraries. This seems how my Ubuntu 8.04 64-bits considers things, probably since it is 'debian' based, and thus also has a /usr/lib32, presumably for 32-bit backward compatible libraries. And in fact, perhaps really the problem is that the auto-tool macro AC_CHECK_LIB() has yet to catch up with this... Maybe it should first append 'lib' to the $prefix, and check there, the 'native' place to look, and if the OS is 64-bit, also try appending 'lib64'... and then generate the appropriate /I path/lib[64] for the make files... or is that asking too much ;=)) But then that would also require the dynamic shared library loader to do likewise, but at least it can be helped through /etc/ld.so.conf... And maybe there is a way to tell the OSG cmake this fact so it would use /usr/lib or $prefix/lib, in this all 64-bit system... and thus alleviate the 'link' step, but cmake is another world of 'options' I have yet to fully explore... And it only seems to use '$prefix/lib64' during the post build 'install' step, since it creates and uses just 'lib' in the source build folder ;=() Lots to 'understand' here... That is can we instruct cmake to go native ;=)) and thus on 64-bit system not generate yet 'another' folder name? Regards, Geoff. -- 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
Re: [Flightgear-devel] configuration snafu
Geoff McLane wrote: That is can we instruct cmake to go native ;=)) and thus on 64-bit system not generate yet 'another' folder name? Yup, as already mentioned, adding -D LIB_POSTFIX= to the 'cmake' command line should do the job (as far as I remember it's been added upon my very own request ;-) 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
Re: [Flightgear-devel] configuration snafu
On Mon, 2010-02-08 at 11:22 +, Martin Spott wrote:
Geoff McLane wrote:
That is can we instruct cmake to go native ;=))
and thus on 64-bit system not generate yet 'another'
folder name?
Yup, as already mentioned, adding
-D LIB_POSTFIX=
to the 'cmake' command line should do the job (as far as I remember
it's been added upon my very own request ;-)
Martin.
Hi Martin,
Yes, you had mentioned this before, but I had missed
its significance... sorry.
It seems OSG cmake does offer GOOD information, if you
take the time to READ it ;=))
quote
The build system is configured to instal libraries to /usr/local/lib64
Your applications may not be able to find your installed libraries
unless you:
set your LD_LIBRARY_PATH (user specific) or
update your ld.so configuration (system wide)
You have an ld.so.conf.d directory on your system, so if you wish to
ensure that
applications find the installed osg libraries, system wide, you could
install a
openscenegraph specific ld.so configuration with:
sudo make install_ld_conf
-- Configuring done
-- Generating done
-- Build files have been written to: /home/geoff/fg/fg8/OSG282
NOTE WELL: Read the above CAREFULLY. It may contain warnings, and
important advice.
/quote
And of course I have to ADMIT, this is the first time
I have stopped to READ IT ALL CAREFULLY ;=() My big
'makefg' build script has a NOPAUSE switch, which I
certainly use far _TOO_ often so it all flashes by...
It not only warns about the -
'/usr/local/lib64' but goes on to tell you how to
set it up system wide for runtime :-
sudo make install_ld_conf
Fantastic stuff...
Of course I already override the install to
/usr/local/lib64 with my cmake :-
-D CMAKE_INSTALL_PREFIX:PATH=$prefix
and now I have added your -
-D LIB_POSTFIX=
BUT, YUK, YUK, YUK, it generated an ERROR on OSG install!!!
It seems somehow the got added so it generated
a BAD command line in file cmake_install.cmake :-
FILE(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/pkgconfig
TYPE FILE FILES...
instead of probably
FILE(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/pkgconfig TYPE
FILE FILES...
UGH! So now I am trying with just :-
-D LIB_POSTFIX=
This looks, feels like a cmake bug???
Regards,
Geoff.
--
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
Re: [Flightgear-devel] configuration snafu
One thing I'd like to clarify: I wish people wouldn't be so quick to assume that Joe User is a non-programmer and/or an idiot. I never said that, and I never meant to imply that. Let's suppose Joe has a PhD in biochemistry, and has written 100,000 lines of code in the last few years. There are *lots* of scenarios where Joe and other non-idiots might want to compile OSG from source. -- For starters, Joe might have access but *not* root access to a super-high-end graphics system. -- Maybe Joe has root access but doesn't want to use it for this purpose, for security reasons. -- Maybe Joe wants to install multiple versions, for comparison purposes. -- Maybe Joe's distro provides a slightly elderly version of OSG, not advanced enough for use with FG, and Joe doesn't want to upgrade his entire software base just so he can try out some game. One of the things I like about Linux is that it allows users to do things without requiring every user to be superuser. I emphasize yet again that messing with ld.so.conf is nowhere near being a solution (let alone a documented solution, much less an out-of-the-box solution) in use-case scenarios of this sort. The inappropriateness of messing with ld.so.conf is particularly obvious in scenarios where there are multiple installed versions. In such scenarios, appropriate solutions include passing LD_LIBRARY_PATH in the environment at runtime, or passing rpath options to the linker at link-time. I remain quite aware that there are ways of getting things to work in Joe's scenarios -- quite a few ways actually -- but they all involve doing something that the average biochemist will find non-obvious. The LIB_POSTFIX flag, for example, is a fine idea, but it is not mentioned anywhere in the OSG *or* FG documentation so far as I can tell. The claim that Joe User can install OSG and FG from source out of the box is untenable. === The claim that I wrongly specified putting OSG into lib64 is entirely baseless. None of my configuration options specify anything of the sort. The configuration flags specify a higher-level directory; OSG creates the lib64 directory all by itself. This is the OSG default behavior. More generally, I must disagree with the claims that the problems arise because OSG has been installed in a wrong place. The crux of the argument is that ./configure has two phases, one where it finds stuff to make sure all needed components have been installed, and another where it emits makefiles. Common sense suggests that the first phase and the second phase should play by the same rules. In particular, the first phase of ./configure operates by compiling tiny test programs. I'm still waiting for somebody to explain why the ./configure script knows how to compile these test programs just fine, but doesn't know how to compile SG and FG. -- 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
Re: [Flightgear-devel] configuration snafu
Ok -D LIB_POSTFIX=
worked fine inside my script. Maybe this is
due to the shell removing the if done at
a command line, but not if inside a script???
In the cmake_install.cmake file it now has :-
FILE(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/pkgconfig TYPE
FILE FILES...
But cmake should have seen the length of = was
really zero content...
Anyway BINGO! They installed in my $prefix/lib ;=))
No 'link' step required...
SUCCESS! Another small step for mankind, no, no...
John, I do not remember anyone suggesting 'you'
wrongly put OSG into 'lib64'. We all agree, and I
have shown the cmake output, that TELLS YOU THIS!
WARNS YOU UP FRONT that this was going to happen.
I still can not exactly understand you want
from the FG ./configure, and actually you really
mean autogen.sh, since this is when 'configure'
script is created, from configure.ac, and other
things...
And in my book, if Joe User is using linux/unix
he _IS_ a programmer in a general sense, and is
most certainly not an idiot.
I would NOT yet foist *nix on my wife for
example, not because she is an idiot - quite
the contrary ;=)) - but because she is NOT yet
prepared to be a 'programmer'. To have to fiddle
around, change and understand things...
You jump on this out-of-the-box, but to me
NOTHING in *nix is out-of-the-box! There is
almost NOTHING I have done that did NOT require
me, at some level, to get into 'programming'.
To move something, to change the permissions,
create links, learn about SWITCHES to this,
to that tool, etc, etc, etc... AND some of
these absolutely require superuser status, at
least temporarily through 'sudo'.
In fact one might say that this is the FUN
of *nix ;=))
Even to install it, I had to remind myself a
lot more about HDD partitions, had to answer
questions I most certainly knew nothing about...
the only thing that got me initialized was
a reasonable set of defaults - like SG/FG
has a reasonable set of defaults.
But back to configure... yes it sometimes
generates little 'test' programs, compiles and
runs these, and depending on the result
either of the compile, or the running, will
make certain decisions.
So sometimes, it is due to the fact that this
tiny test program FAILED to compile, is the
test itself. But whether we set the configure
script to ABORTS at this point, with message,
largely depends on so many other things...
But that seems beside the point. The configure
script _DID_ tell you it could _NOT_ find the
OSG libraries - you just ignore it. You did not
heed its clear indication that you were headed
into trouble...
So it seems even if we had some MORE documentation
in SG/FG to say - CHECK THE CONFIGURE SCRIPT
FINDS ALL THE NECESSARY LIBRARIES - there
can be a problems specifically with OSG
libraries, and where they are installed -
you would have IGNORED it, the same way you
ignored the content of config.log, which
TOLD YOU it was having a problem.
And how much documentation should we have
in SG/FG about downloading, configuring,
compiling, installing prerequisites packages
depends. Some would say it is sufficient to
say SG/FG depend on OSG say 2.8.1 or higher
(or whatever the number is)...
Others like me, usually want a little more
than this. And now that we know about it,
and have 'solved' it, this OSG cmake lib64
could/should be mentioned, but none of us
want to attempt to fully document all the
options on each prerequisite - you should
be prepared to read their documentation.
So what more do you want us to do???
Here we are TRYING hard to help you, and
you seem to be yelling something. Before your
long rant I was going to say ---
==
And after John tests and checks this, I hope he will
_REMOVE_ this suggested configuration 'snafu' from
his BUG list ;=()
There may be others issues, but this 'lib64' item
seems closed - bludgeoned to death ;=))
Although I still see no particular problem in slightly
improving the FG configure.ac script, and README.OSG,
it now does NOT seem so essential...
The build quickly aborted on not finding -losgFX,
and a review of the config.log would show in fact
NO OSG libraries had been found, which should alert
one to an OSG 'installation' issue.
That is, is this sufficient TLC for now? ;=)) We
have the silver bullet - cmake -D LIB_POSTFIX=!
But now! Wow, if in the mind to, the number of
posts on this thread will mount exponentially ;=))
I will opt out of it for now, with the problem
solved.
Who ever claimed 'that Joe User can install OSG
and FG from source out of the box' is a liar,
if not an idiot to boot ;=)) Like all good things,
it comes at a price, with considerable effort,
but I and others do our best to HELP.
John, if you want more help, perhaps write to
me direct off list, and I WILL do my VERY best to
quietly explain...
Regards,
Geoff.
PS: Have updated my makefg accordingly -
http://geoffair.net/tmp/makefg
to version 1.1.5
Re: [Flightgear-devel] configuration snafu
John Denker wrote: I wish people wouldn't be so quick to assume that Joe User is a non-programmer and/or an idiot. I think nobody does, I just expect Joe User to _read_ what's being prominently presented to him. _Especially_ when he's having some programming experience - actually this doesn't make much of a difference - then we should expect him to follow common, basic rules like reading accompagnying README's, reading 'configure' output and the such. If he deliberately takes a short-cut around these rules and fails while doing so, then it's hard to blame the result as being a software bug. I think the entire discussion sparks from the fact that you're having the habit of declaring everything you don't understand as being a bug. So, could this basically be a bug between keyboard and chair ? As a reminder, citing yourself: Here's yet another area that needs some TLC: There appears to be little or no chance that the autoconf system will do the right thing on 64-bit machines. [...] This is currently item #45 on this list of bugs: http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit; Obviously the autoconf system is doing pretty much the right thing on most of the affected 64-bit machines - people just need to employ basic skills they're supposed to have learnt in elementary school. [... lots of blather removed ...] Do I sense an attempt to cloud an unfortunate mistake by spreading the discussion into as many directions as possible ? 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
Re: [Flightgear-devel] configuration snafu
On 02/08/2010 08:34 AM, Geoff McLane wrote: But that seems beside the point. The configure script _DID_ tell you it could _NOT_ find the OSG libraries - you just ignore it. You did not heed its clear indication that you were headed into trouble... That statement is completely false. There was no indication from ./configure that there was any impending trouble. The first and only sign of trouble was when the make step failed in a surprising way. Here we are TRYING hard to help you, and you seem to be yelling something. Before your long rant I was going to say --- I spoke softly for a long time and was ignored. When people announce that the bug is closed, based on completely false assumptions, I feel I should explain why the assumptions are false. When the number of false assumptions becomes large, the explanation becomes lengthy. I also point out, again, that I am not asking anybody to help me. I have workarounds for this bug. Have had for years. I am just trying to help Joe User. I was slapped for pointing this out previously, but it remains true. -- 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
Re: [Flightgear-devel] configuration snafu
John Denker wrote: I also point out, again, that I am not asking anybody to help me. I have workarounds for this bug. Have had for years. I am just trying to help Joe User. I was slapped for pointing this out previously, but it remains true. I'm not exactly sure you're actually helping the non complaining Joe User by scaring away the few developers that are left. Erik -- 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
Re: [Flightgear-devel] configuration snafu
But John, what IS the _BUG_ you refer to? Your bug list page only points out osgFX library could not be found. This is NOT a BUG!!! Definitely a user OSG installation problem, but _NOT_ a SG/FG BUG! If you had read the screen during the ./configure ... step you would have seen something like :- Checking for osgGetVersion in -losg: no That 'no' is a 'clear indication' of trouble pending... And after the fact, in the config.log, like - ... configure:13918: checking for osgGetVersion in -losg configure:13953: g++ -o conftest -g ... blah blah... configure:13959: $? = 0 configure:13977: result: no ... That result: 'no' is a 'clear indication' that a libosg, containing an exported function osgGetVersion, can NOT be found, using the 'standard' and -L/paths/... given to g++, and continuing with 'make' is likely to FAIL... As you have read, I have suggested that we abort during the configure step in case of this 'no', for this important library, but that is only a 'choice'. If the person 'sees' the 'no', says oops, and does something to fix it, like install the OSG libraries in a 'standard' place... then there is no reason to have aborted the configure step... and they can continue with make... But I agree, it does seem better to abort, but not essential. But that seems beside the point. The configure script _DID_ tell you it could _NOT_ find the OSG libraries - you just ignore it. You did not heed its clear indication that you were headed into trouble... That statement is completely TRUE, or do you somehow think the 'no' means 'yes'? ;=)) Or Joe User should not have to read the screen, or the config.log, or know libosg is essential! Yes, helping Joe User is definitely what we are trying to do. And at some point 'everybody', Joe User included, has to realize that it is their responsibility to install prerequisites such that SG/FG can find and use them... And where we can we do add some information on how to achieve this... Agreed, perhaps there could be MORE of this - always more docs... and the configure scripts - which can always be extended, and extended, and improved... The fact that cmake OSG defaults to putting their libraries into a non-standard place, 'lib64', is the responsibility of 'cmake' and/or 'OSG', and while SG/FG might or might not have some mention of this in its documentation, it frankly should not need to. I personally think you should move this 'BUG', if you insist on calling it that, to the cmake and/or OSG boards. Explain to them that they should make the -D LIB_POSTFIX= option clearer, or eliminate it, since you think a Joe User is never going to find it, and even if he/she does, will not use it. Too messy, complicated - just not out-of-the-box ;=)) Joe User does not want to read lengthy scrolling screen message, so it is not enough to advise where the default install will go ;=)) And further that you feel Joe User does NOT want to be involved in complicated superuser things like - sudo make install_ld_conf so this should be removed. Joe User does not like or understand flexibility - sudo is no-go ;=)) And while you are at, get to the automake tools community, and suggest to them that the AC_CHECK_LIB() macro sucks, since it can it find a library that you definitively know Joe User installed. Maybe you even saw him/her do it ;=)) But no, you do not know WHERE it was installed - Joe User should not have to 'know' this type of information. He ran the 'install' script, and that should be enough - it is in-the-box ;=)) I am sure we in the FG community wish you well in this worthy endeavor, as does Joe User ;=)) Finally, what _ARE_ your so called 'workarounds for this bug', that you have 'had for years'. Please _SHARE_ this information, no matter how complicated it is to explain, so we can _ALL_ benefit. Regards, Geoff. -- 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
Re: [Flightgear-devel] configuration snafu
On 2/8/10 6:58 PM, Geoff McLane wrote: As you have read, I have suggested that we abort during the configure step in case of this 'no', for this important library, but that is only a 'choice'. If the person 'sees' the 'no', says oops, and does something to fix it, like install the OSG libraries in a 'standard' place... then there is no reason to have aborted the configure step... and they can continue with make... But I agree, it does seem better to abort, but not essential. I think it is helpful to actually report potential problems found in the end of the configure script. For each important 'no' found a flag can be set and in the end of the configure script a warning message AC_MSG_WARN (or a fatal message AC_MSG_ERROR) can be displayed to inform the user that there are unresolved issues. The problem is that there are quite a few 'no's that are not fatal and for newcomers to fg/sg it is not easy to understand which 'no' to ignore. Personally I keep track of failed checks and report them in the end of my configure.ac's. I even conclude with printing all important variables like # Some more messages. AC_MSG_NOTICE([ Ready to compile the executables of svndigest $VERSION The following flags and libs will be used: +++ Compiler: $CXX Preprocessor flags: $SD_CPPFLAGS $CPPFLAGS CPPFLAGS: $CPPFLAGS DEFAULT_CPPFLAGS: $DEFAULT_CPPFLAGS APR_CPPFLAGS: $APR_CPPFLAGS SVN_CPPFLAGS: $SVN_CPPFLAGS PLPLOT_CPPFLAGS: $PLPLOT_CPPFLAGS C++ flags: CXXFLAGS: $CXXFLAGS DEFAULT_CXXFLAGS: $DEFAULT_CXXFLAGS Linker flags: LDFLAGS: $LDFLAGS APR_LDFLAGS: $APR_LDFLAGS SVN_LDFLAGS: $SVN_LDFLAGS PLPLOT_LDFLAGS: $PLPLOT_LDFLAGS Libraries: LIBS $LIBS APR_LIBS $APR_LIBS SVN_LIBS $SVN_LIBS PLPLOT_LIBS $PLPLOT_LIBS +++]dnl ) and I even end with AC_MSG_NOTICE([Now type 'make all check'.]) to indicate what the user should do next. Of course, any fatal failures will make configure to not display the last message. sg/fg configure.ac is not providing the above service (sg/fg does print some final messages) is not a bug but could be added to some list as a feature request. Cheers, Jari -- 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
Re: [Flightgear-devel] configuration snafu
On 02/08/2010 10:58 AM, Geoff McLane wrote: But John, what IS the _BUG_ you refer to? Thank you for asking. Your bug list page only points out osgFX library could not be found. This is NOT a BUG!!! Definitely a user OSG installation problem, but _NOT_ a SG/FG BUG! Are you asking me or telling me? If you had read the screen during the ./configure ... step you would have seen something like :- Checking for osgGetVersion in -losg: no That 'no' is a 'clear indication' of trouble pending... I'm telling you, again, that statement is completely false. No such indication, clear or otherwise, is observed chez moi when reproducing the bug I am talking about. A detailed typescript of the configuration step can be found at http://www.av8n.com/fly/fgfs/bad-configure.logg The log file written by ./configure itself is at: http://www.av8n.com/fly/fgfs/config.log The corresponding typescript of the make step is at: http://www.av8n.com/fly/fgfs/bad-make.logg Unless grep is lying to me, no failed check for osg can be seen during the configuration step. grep -i osg bad-configure.logg + ./configure --with-osg=/games/orig/usr --with-plib=/games/orig/usr --prefix=/games/orig/usr osg prefix is /games/orig/usr checking osg/Version usability... yes checking osg/Version presence... yes checking for osg/Version... yes And after the fact, in the config.log, like - ... configure:13918: checking for osgGetVersion in -losg configure:13953: g++ -o conftest -g ... blah blah... configure:13959: $? = 0 configure:13977: result: no Again, completely untrue. grep -i osg config.log $ ./configure --with-osg=/games/orig/usr --with-plib=/games/orig/usr --prefix=/games/orig/usr configure:8397: checking osg/Version usability configure:8397: checking osg/Version presence configure:8397: checking for osg/Version ac_cv_header_osg_Version=yes HAVE_FRAMEWORK_OSG_FALSE='' HAVE_FRAMEWORK_OSG_TRUE='#' osg_FRAMEWORKS='' That result: 'no' is a 'clear indication' that a libosg, containing an exported function osgGetVersion, can NOT be found, using the 'standard' and -L/paths/... given to g++, ... Still completely false. But that seems beside the point. The configure script _DID_ tell you it could _NOT_ find the OSG libraries - you just ignore it. You did not heed its clear indication that you were headed into trouble... This is getting kinda repetitious. They say a word to the wise suffices. There's more I could say, but I'll stop here. Maybe I have overlooked something ... but IMHO whatever it is, Joe User is likely to overlook it also. -- 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
Re: [Flightgear-devel] configuration snafu
For whatever it's worth, it's possible for different systems (or different versions of libraries) to lay out their functions in different libraries. So often the point of a library or function check is to pull in a library if it exists on that system (or if the desired function is in that particular library.) And if the library doesn't exist, it isn't necessarily always an error. Depending on the layout of a particular system, we certainly wouldn't want to link against a library that doesn't exist. The autoconf check can account for this. The automake/autoconf system could always use more love (can't we all?) :-) but let's be careful and proceed with a good understanding of all the nuances. Curt. On Mon, Feb 8, 2010 at 3:12 PM, Jari Häkkinen j...@flygarna.se wrote: On 2/8/10 6:58 PM, Geoff McLane wrote: As you have read, I have suggested that we abort during the configure step in case of this 'no', for this important library, but that is only a 'choice'. If the person 'sees' the 'no', says oops, and does something to fix it, like install the OSG libraries in a 'standard' place... then there is no reason to have aborted the configure step... and they can continue with make... But I agree, it does seem better to abort, but not essential. I think it is helpful to actually report potential problems found in the end of the configure script. For each important 'no' found a flag can be set and in the end of the configure script a warning message AC_MSG_WARN (or a fatal message AC_MSG_ERROR) can be displayed to inform the user that there are unresolved issues. The problem is that there are quite a few 'no's that are not fatal and for newcomers to fg/sg it is not easy to understand which 'no' to ignore. Personally I keep track of failed checks and report them in the end of my configure.ac's. I even conclude with printing all important variables like # Some more messages. AC_MSG_NOTICE([ Ready to compile the executables of svndigest $VERSION The following flags and libs will be used: +++ Compiler: $CXX Preprocessor flags: $SD_CPPFLAGS $CPPFLAGS CPPFLAGS: $CPPFLAGS DEFAULT_CPPFLAGS: $DEFAULT_CPPFLAGS APR_CPPFLAGS: $APR_CPPFLAGS SVN_CPPFLAGS: $SVN_CPPFLAGS PLPLOT_CPPFLAGS: $PLPLOT_CPPFLAGS C++ flags: CXXFLAGS: $CXXFLAGS DEFAULT_CXXFLAGS: $DEFAULT_CXXFLAGS Linker flags: LDFLAGS: $LDFLAGS APR_LDFLAGS: $APR_LDFLAGS SVN_LDFLAGS: $SVN_LDFLAGS PLPLOT_LDFLAGS: $PLPLOT_LDFLAGS Libraries: LIBS $LIBS APR_LIBS $APR_LIBS SVN_LIBS $SVN_LIBS PLPLOT_LIBS $PLPLOT_LIBS +++]dnl ) and I even end with AC_MSG_NOTICE([Now type 'make all check'.]) to indicate what the user should do next. Of course, any fatal failures will make configure to not display the last message. sg/fg configure.ac is not providing the above service (sg/fg does print some final messages) is not a bug but could be added to some list as a feature request. Cheers, Jari -- 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 -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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
Re: [Flightgear-devel] configuration snafu
On Mon, Feb 8, 2010 at 10:20 PM, John Denker j...@av8n.com wrote: On 02/08/2010 10:58 AM, Geoff McLane wrote: If you had read the screen during the ./configure ... step you would have seen something like :- Checking for osgGetVersion in -losg: no That 'no' is a 'clear indication' of trouble pending... I'm telling you, again, that statement is completely false. No such indication, clear or otherwise, is observed chez moi when reproducing the bug I am talking about. A detailed typescript of the configuration step can be found at http://www.av8n.com/fly/fgfs/bad-configure.logg I think you two are looking at different config.log files. Geoff is talking about FlightGear itself and you, John, about SimGear. Apparently SimGear's configure script isn't as pedantic as FlightGear's and doesn't check for the presence of the libraries. It is really only a problem because it tries to build proptest - otherwise, to just create the simgear libraries, it wouldn't need to link against OSG. The relevant parts from FlightGear's configure script could be applied to SimGear - assuming they are working, of course. By the way, I have already suggested putting the test programs into a separate make target. I am not saying that as a fix to the current problem - even though as a side effect it would allow a build without OSG libraries. -- Csaba/Jester -- 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
Re: [Flightgear-devel] configuration snafu (John Denker)
On 09/02/10 00:57, flightgear-devel-requ...@lists.sourceforge.net wrote: On openSUSE 11.3 Milestone 1 x86_64, I couldn't coax it into looking in /usr/local/lib64. config.log:- configure:16223: gcc -o conftest -g -O2 -D_REENTRANT -I/usr/local/include -L/usr/local/lib -L/usr/X11R6/lib conftest.c -lOpenThreads -losgFX -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm 5 /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/ld: cannot find -losgFX collect2: ld returned 1 exit status configure:16230: $? = 1 configure: failed program was: | /* confdefs.h. */ Regards Sid. === Message: 2 Date: Mon, 08 Feb 2010 08:53:47 -0700 From: John Denker j...@av8n.com Subject: Re: [Flightgear-devel] configuration snafu To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Message-ID: 4b70338b.2000...@av8n.com Content-Type: text/plain; charset=ISO-8859-1 On 02/08/2010 08:34 AM, Geoff McLane wrote: But that seems beside the point. The configure script _DID_ tell you it could _NOT_ find the OSG libraries - you just ignore it. You did not heed its clear indication that you were headed into trouble... That statement is completely false. There was no indication from ./configure that there was any impending trouble. The first and only sign of trouble was when the make step failed in a surprising way. Here we are TRYING hard to help you, and you seem to be yelling something. Before your long rant I was going to say --- I spoke softly for a long time and was ignored. When people announce that the bug is closed, based on completely false assumptions, I feel I should explain why the assumptions are false. When the number of false assumptions becomes large, the explanation becomes lengthy. I also point out, again, that I am not asking anybody to help me. I have workarounds for this bug. Have had for years. I am just trying to help Joe User. I was slapped for pointing this out previously, but it remains true. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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
Re: [Flightgear-devel] configuration snafu
On Saturday 06 Feb 2010, Ron Jensen wrote: [snip...] ./configure --datadir=$parent/bogus \ --with-osg=$parent/usr \ --with-simgear=$parent/usr \ --with-plib=$parent/usr \ --prefix=$parent/usr Isn't exactly a stock setup... And neither is shuffling libraries into non-standard directories. The system does not seem to be highly customised and generating a makefile that doesn't work cannot be passed off as just not working in the way expected. The issue seems to be the makefile expects to find OSG's libraries in $parent/usr/lib where they were specified to be, and he/his system placed them in a non-standard place. Look at his command line again. g++ -g -O2 -I/games/orig/usr -D_REENTRANT -L/games/orig/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm -losgFX -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm /usr/bin/ld: cannot find -losgFX He *told* it osg was in $parent/usr/ (and I am assuming $parent=/games/orig) and the makefile is telling g++ to look in -L/games/orig/usr/lib for libraries. But isn't one of the tasks of ./configure to test that it can find the libs it needs, and isn't this the real problem? Is it not the case that ./configure has run ok, presumably believing that it has found the libs it needs, but then generated a makefile that fails because it can't find them? That was what I thought the problem was. Using non-standard configurations is far from forbidden on linux; that's why there are options (parameters) to override normal defaults, but ./configure should be checking for consistency and failing when it finds inconsistency, not giving the appearance that all is well. LeeE -- 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
Re: [Flightgear-devel] configuration snafu
leee wrote: But isn't one of the tasks of ./configure to test that it can find the libs it needs, and isn't this the real problem? Is it not the case that ./configure has run ok, presumably believing that it has found the libs it needs, but then generated a makefile that fails because it can't find them? That was what I thought the problem was. Using non-standard configurations is far from forbidden on linux; that's why there are options (parameters) to override normal defaults, but ./configure should be checking for consistency and failing when it finds inconsistency, not giving the appearance that all is well. Agreed. I'll see if I can fix it somewhere this week (unless someone else beats me to it). By the way: I don't dislike the idea of switching to CMake but I have no experience in creating configuration files for it myself. Erik -- 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
Re: [Flightgear-devel] configuration snafu
Hi All, Wow, don't you love it when a topic generates real interest. I count over 30 posts on this so far... and I can not help but add one more ;=)) To try to directly address the problem as posted on - http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit the case of a 'missing' osgFX So the question is where is osgFX installed? And this, as others have pointed out, would depend on what was fed to cmake, if OSG is compiled from source, or where the package manager put it... I suspect it is in a 'lib64' folder, either /usr/lib64 or maybe /usr/local/lib64, or /games/orig/usr/lib64 Why OSG cmake does this I have no idea. Maybe cmake thinks it is being 'smart' ;=() If it is in /games/orig/usr/lib64, and there is no /games/orig/usr/lib, or it is empty, then creating a link lib - lib64 with /games/orig/usr $ ln -s lib64 lib will get the compile/link to complete. If it is in /usr/lib64 or /usr/local/lib64, then we know there is already a /usr/lib and /usr/local/lib, so the 'link' solution can NOT be used. I guess the only solution for this would be to move everything out of the 'lib64' into lib... or indeed into somewhere like - /games/orig/usr/lib[64] And be aware, except for the /usr/lib move you will then have to add a 'fix' when ever you run 'fgfs', since now the dynamic shared runtime library loader will also not be able to find osgFX, and all the other OSG shared libraries... To run 'fgfs' you will have to do - export LD_LIBRARY_PATH=/games/orig/usr/lib64 or export LD_LIBRARY_PATH=/games/orig/usr/lib if you created the suggested 'link'. And this will also apply when you run say fgviewer, or others that depend on the OSG shared libraries, so can be a bit of a pain... Or this can be made 'permanent' by adding another say osg.conf to /etc/ld.so.conf.d since my /etc/ld.so.conf contains a line - include /etc/ld.so.conf.d/*.conf Something I think maybe cmake OSG should have done... Now whether or not this can be classified as a FG 'bug' is a mute point. As Lee and others have pointed out, I do think FG auto configuration could have a check for say osgFX, or osgDB, and politely exit with message before it is seen in the actual compile/link... I have NO problems compiling, linking, and running in my Ubuntu 64-bit, and to share how I get around all this - $someroot in my case is '/home/geoff/fg/fg7' but can be just about anything... 1. OSG - I use - cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS=-O3 \ -D CMAKE_C_FLAGS=-O3 \ -D CMAKE_INSTALL_PREFIX:PATH=$someroot/install/OSG281 This installs the OSG libraries in $someroot/install/OSG281/lib64 And the OSG headers are thus installed in $someroot/install/OSG281/include and say osgviewer binary in $someroot/install/OSG281/bin Then in this folder $someroot/install/OSG281 I make a link lib - lib64 2. PLIB ./configure --prefix=$someroot/install/plib \ --exec-prefix=$someroot/install/plib 3. SG ./configure --prefix=$someroot/install/simgear \ --exec-prefix=$someroot/install/simgear \ --with-osg=$someroot/install/OSG281 \ --with-plib=$someroot/install/plib \ --with-jpeg-factory \ --with-boost=$someroot/install/boost 4. FG ./configure --prefix=$someroot/install/fgfs \ --exec-prefix=$someroot/install/fgfs \ --with-osg=$someroot/install/OSG281 \ --with-simgear=$someroot/install/simgear \ --with-plib=$someroot/install/plib This is using OSG release 281, but this approach gives me the flexibility of using the later 282, of even the OSG svn trunk... likewise with various release versions, or svn, of plib... perhaps the only case for using non-standard directory installations... Of course, I have ALL this in a script - http://geoffair.net/tmp/makefg so I do NOT have to remember each time... and that script generates a run_fgfs.sh script, that does the export LD_LIBRARY_PATH thingy before running fgfs... And as you can read in that script, I have a 'switch' to install OSG in the 'standard' path, /usr/lib etc, but never got that working ;=() I will add and test a few additions to configure.ac to 'search' for the OSG libraries, like we do for most others, and present it shortly... and maybe others, like Erik says, have ideas on this... maybe it would also be possible to ferret out even a 'lib64' installation... HTH, Regards, Geoff. -- 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
Re: [Flightgear-devel] configuration snafu
leee wrote: But isn't one of the tasks of ./configure to test that it can find the libs it needs, and isn't this the real problem? Yup, and if it doesn't find OSG libraries, then it'll be going to write approx. eight messages in sequence about OSG libraries not being found. The only point which might be debatable here is wether you'd expect 'configure' to exit ungracefully at this point for those users who don't care to understand 'configure's output. BUT those who don't are probably not the primary target group for compiling FlightGear and all it's dependencies from source. BTW, FlightGear's 'configure' behaves similarly wrt. other libraries - seems to be like being the FlightGear way of dealing with missing libraries, Martin. P.S.: The compile-time linker on Debian/Lenny/AMD64 is happily going to pick the libraries from /usr/lib64/ if you move the files there. You just have to point the runtime-linker at the directory in order to start FlightGear. -- 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
Re: [Flightgear-devel] configuration snafu
Geoff McLane wrote: Why OSG cmake does this I have no idea. Maybe cmake thinks it is being 'smart' ;=() OSG is destined to compile and work on a lot more Unix systems than those who are supported by FlightGear (at least nowadays, we were having a few more in the past). Quite a few of these systems are following conventions about the naming of library-directories which are different from the respective habits on Linux. Thus, storing 64-bit libraries in $prefix/lib64/ (on platforms which might support different word-sizes) doesn't look that bad as being cross-platform solution, 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
Re: [Flightgear-devel] configuration snafu
Curtis Olson wrote: I don't doubt that there could be some lib vs. lib64 inconsistencies, but FilghtGear builds right out of the box for me on 64bit Fedora 12 ... no hitches at all that I recall and it has done so for quite some time. Same for me on slackware64. Jon -- 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
Re: [Flightgear-devel] configuration snafu
On Saturday 06 February 2010 12:15:15 pm Jon Stockill wrote: Curtis Olson wrote: I don't doubt that there could be some lib vs. lib64 inconsistencies, but FilghtGear builds right out of the box for me on 64bit Fedora 12 ... no hitches at all that I recall and it has done so for quite some time. Same for me on slackware64. And Suse 11.1... -- 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
Re: [Flightgear-devel] configuration snafu
On Fri, Feb 5, 2010 at 11:05 PM, John Denker j...@av8n.com wrote: On 02/05/2010 02:38 PM, Curtis Olson wrote: I don't doubt that there could be some lib vs. lib64 inconsistencies, but FilghtGear builds right out of the box for me on 64bit Fedora 12 ... no hitches at all that I recall and it has done so for quite some time. Chez moi plib and simgear install into lib/ while osg installs into lib64/ How do you get around that? How do recommend I get around that? On 64 bit systems /lib64 should really be a symlink to /lib (similarly for /usr/lib64) as that is the native architecture. I say copy the stuff from lib64 to lib and create the symlink. -- Csaba/Jester -- 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
Re: [Flightgear-devel] configuration snafu
On 02/06/2010 07:54 AM, Csaba Halász wrote: On 64 bit systems /lib64 should really be a symlink to /lib (similarly for /usr/lib64) as that is the native architecture. I say copy the stuff from lib64 to lib and create the symlink. That is one way of doing it. By my count there are at least four different workarounds for the configuration snafu: -- LIB_POSTFIX during OSG compilation -- moving or copying the OSG libraries -- symlink -- LDFLAGS during SG and FG compilation/linkage The fact that workarounds exist for this bug seems to be rather strong evidence that the bug exists. The claim that everything just works out of the box is untenable. One option would be to document one or more of these workarounds. A better option would be to fix things like acinclude.m4 so that workarounds are no longer necessary, so that things really do work out of the box. -- 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
Re: [Flightgear-devel] configuration snafu
John Denker wrote: The fact that workarounds exist for this bug seems to be rather strong evidence that the bug exists. The sole fact that you're getting in trouble with the way you are doing things on your very local setup doesn't prove a single bug, 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
Re: [Flightgear-devel] configuration snafu
On Sat, Feb 6, 2010 at 4:18 PM, John Denker j...@av8n.com wrote: On 02/06/2010 07:54 AM, Csaba Halász wrote: On 64 bit systems /lib64 should really be a symlink to /lib (similarly for /usr/lib64) as that is the native architecture. I say copy the stuff from lib64 to lib and create the symlink. That is one way of doing it. No, see my previous message. By my count there are at least four different workarounds for the configuration snafu: -- LIB_POSTFIX during OSG compilation -- moving or copying the OSG libraries -- symlink -- LDFLAGS during SG and FG compilation/linkage The fact that workarounds exist for this bug seems to be rather strong evidence that the bug exists. The claim that everything just works out of the box is untenable. The autoconf scripts do need to be brought into the modern 64 bit world, ideally in a way that still permits building 32 bit binaries on 64 bit systems. However, it does seem to work out of the box for most people, which is why the bug remains. I suspect it works because 1) ld has /usr/local/lib64 in its default search path, so OSG libraries are picked up, 2) people don't realize that they are polluting /usr/local/lib with 32 bit simgear libraries, 3) the flightgear compilation command includes -L/usr/local/lib even on 64 bit libraries, so everything seems hunky-dory, or 4) people (like myself) never install simgear and flightgear in the system directories. One option would be to document one or more of these workarounds. A better option would be to fix things like acinclude.m4 so that workarounds are no longer necessary, so that things really do work out of the box. Yes. We can stop flaming about it. Tim -- 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
Re: [Flightgear-devel] configuration snafu
On Sat, Feb 6, 2010 at 5:17 PM, Tim Moore timoor...@gmail.com wrote: On Sat, Feb 6, 2010 at 4:18 PM, John Denker j...@av8n.com wrote: On 02/06/2010 07:54 AM, Csaba Halász wrote: On 64 bit systems /lib64 should really be a symlink to /lib (similarly for /usr/lib64) as that is the native architecture. I say copy the stuff from lib64 to lib and create the symlink. That is one way of doing it. No, see my previous message. On native 64 bits systems there is no point in having a separate /lib and /lib64 - I certainly don't see any. Debian does provide the symlinks as I said. The autoconf scripts do need to be brought into the modern 64 bit world, ideally in a way that still permits building 32 bit binaries on 64 bit systems. However, it does seem to work out of the box for most people, which is why the bug remains. Yes, I guess most people just build for their native system. If not, I expect they would install into separate prefixes anyway. A fix would be nice, but I suppose most other bugs on your JD's list are more important. -- Csaba/Jester -- 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
Re: [Flightgear-devel] configuration snafu
On Sat, Feb 6, 2010 at 1:39 PM, Csaba Halász wrote: On native 64 bits systems there is no point in having a separate /lib and /lib64 - I certainly don't see any. Debian does provide the symlinks as I said. You can't ever think of a situation where you might need 64 bit and 32 bit versions of the same library? Not if you build everything 64bit clean from scratch which debian can probably do for their base installation. But what do you do if you want to install some precompiled application where source code is not available, and you are sitting on a 64 bit machine, but it needs 32 bit versions of some of your libraries? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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
Re: [Flightgear-devel] configuration snafu
On Sat, Feb 6, 2010 at 8:39 PM, Csaba Halász csaba.hal...@gmail.com wrote: On Sat, Feb 6, 2010 at 5:17 PM, Tim Moore timoor...@gmail.com wrote: On Sat, Feb 6, 2010 at 4:18 PM, John Denker j...@av8n.com wrote: On 02/06/2010 07:54 AM, Csaba Halász wrote: On 64 bit systems /lib64 should really be a symlink to /lib (similarly for /usr/lib64) as that is the native architecture. I say copy the stuff from lib64 to lib and create the symlink. That is one way of doing it. No, see my previous message. On native 64 bits systems there is no point in having a separate /lib and /lib64 - I certainly don't see any. Debian does provide the symlinks as I said. Do you run any 32 bit applications on your 64 bit system, like Google Earth? They expect 32 bit libraries in /lib. It's possible that the Debian runtime loader plays games to look in some other place for 32 bit libs or appends a suffix to them; I don't know. On Fedora, the 32 bit libs have the same names as the 64 bit libs and are installed in /lib, /usr/lib, etc. The autoconf scripts do need to be brought into the modern 64 bit world, ideally in a way that still permits building 32 bit binaries on 64 bit systems. However, it does seem to work out of the box for most people, which is why the bug remains. Yes, I guess most people just build for their native system. If not, I expect they would install into separate prefixes anyway. A fix would be nice, but I suppose most other bugs on your JD's list are more important. I try to ignore the autoconf stuff, but I'll see what I can do. Cmake, anyone? :) Tim -- 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
Re: [Flightgear-devel] configuration snafu
On Saturday 06 Feb 2010, Martin Spott wrote: John Denker wrote: The fact that workarounds exist for this bug seems to be rather strong evidence that the bug exists. The sole fact that you're getting in trouble with the way you are doing things on your very local setup doesn't prove a single bug, Martin. If ./configure is generating a makefile that doesn't work then there is clearly a bug. Saying that because the bug doesn't exist because it isn't widespread is just being in denial, and is an excuse (not a reason) for doing nothing about it. LeeE -- 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
Re: [Flightgear-devel] configuration snafu
On Sat, Feb 6, 2010 at 8:49 PM, Curtis Olson curtol...@gmail.com wrote: On Sat, Feb 6, 2010 at 1:39 PM, Csaba Halász wrote: On native 64 bits systems there is no point in having a separate /lib and /lib64 - I certainly don't see any. Debian does provide the symlinks as I said. You can't ever think of a situation where you might need 64 bit and 32 bit versions of the same library? Not if you build everything 64bit clean from scratch which debian can probably do for their base installation. But what do you do if you want to install some precompiled application where source code is not available, and you are sitting on a 64 bit machine, but it needs 32 bit versions of some of your libraries? Well, I still think the sensible thing is to expect *native* libraries in /lib, whatever native may be. If you are on 64 bit, that means 64 bit libraries go into /lib and not /lib64. The only situation I would expect /lib64 is if I am on a 32 bit system. If I am sitting on a 64 bit machine and I need 32 bit libraries, I put the 32 bit libraries elsewhere separated from my native libs (which is what debian does - you get /lib32). To reiterate, I am not saying it shouldn't be fixed. -- Csaba/Jester -- 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
Re: [Flightgear-devel] configuration snafu
leee wrote: On Saturday 06 Feb 2010, Martin Spott wrote: John Denker wrote: The fact that workarounds exist for this bug seems to be rather strong evidence that the bug exists. The sole fact that you're getting in trouble with the way you are doing things on your very local setup doesn't prove a single bug, If ./configure is generating a makefile that doesn't work then there is clearly a bug. A bug is not necessarily the same as a on my very custom setup it doesn't work the way as I would expect. Several people are having severe dificulties to understand the difference, especially when they're starting to deal with non-trivial components in their setup. Saying that because the bug doesn't exist because it isn't widespread is just being in denial, and is an excuse (not a reason) for doing nothing about it. I don't mean not to do anything about it. But I don't agree with people crying bug on every occasion just because they just don't understand the implications of what they're doing. 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
Re: [Flightgear-devel] configuration snafu
On Saturday 06 Feb 2010, Martin Spott wrote: leee wrote: On Saturday 06 Feb 2010, Martin Spott wrote: John Denker wrote: The fact that workarounds exist for this bug seems to be rather strong evidence that the bug exists. The sole fact that you're getting in trouble with the way you are doing things on your very local setup doesn't prove a single bug, If ./configure is generating a makefile that doesn't work then there is clearly a bug. A bug is not necessarily the same as a on my very custom setup it doesn't work the way as I would expect. Several people are having severe dificulties to understand the difference, especially when they're starting to deal with non-trivial components in their setup. Saying that because the bug doesn't exist because it isn't widespread is just being in denial, and is an excuse (not a reason) for doing nothing about it. I don't mean not to do anything about it. But I don't agree with people crying bug on every occasion just because they just don't understand the implications of what they're doing. Cheers, Martin. This is hardly a case of on my very custom setup it doesn't work the way as I would expect. The system does not seem to be highly customised and generating a makefile that doesn't work cannot be passed off as just not working in the way expected. Neither do people normally 'cry' bug whenever they have a problem. This sort of exaggeration and misrepresentation of the circumstances doesn't get anyone anywhere. John's 'Joe' the non-C++ programmer is a valid scenario. Implying that the problem only occurs when people don't understand the implications of what they're doing is like suggesting that people who can't do their own automobile maintenance and repairs shouldn't drive, or indeed, that people who can't fly an aircraft shouldn't travel by air. LeeE -- 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
Re: [Flightgear-devel] configuration snafu
leee wrote: John's 'Joe' the non-C++ programmer is a valid scenario. Implying that the problem only occurs when people don't understand the implications of what they're doing is like suggesting that people who can't do their own automobile maintenance and repairs shouldn't drive, or indeed, that people who can't fly an aircraft shouldn't travel by air. In the contrary, Martin is suggesting that people who don't know how to build a car should buy one. He might have a point.. Erik -- 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
Re: [Flightgear-devel] configuration snafu
On Sat, 2010-02-06 at 23:02 +, leee wrote: On Saturday 06 Feb 2010, Martin Spott wrote: leee wrote: On Saturday 06 Feb 2010, Martin Spott wrote: John Denker wrote: The fact that workarounds exist for this bug seems to be rather strong evidence that the bug exists. The sole fact that you're getting in trouble with the way you are doing things on your very local setup doesn't prove a single bug, If ./configure is generating a makefile that doesn't work then there is clearly a bug. A bug is not necessarily the same as a on my very custom setup it doesn't work the way as I would expect. Several people are having severe dificulties to understand the difference, especially when they're starting to deal with non-trivial components in their setup. Saying that because the bug doesn't exist because it isn't widespread is just being in denial, and is an excuse (not a reason) for doing nothing about it. I don't mean not to do anything about it. But I don't agree with people crying bug on every occasion just because they just don't understand the implications of what they're doing. Cheers, Martin. This is hardly a case of on my very custom setup it doesn't work the way as I would expect. ./configure --datadir=$parent/bogus \ --with-osg=$parent/usr \ --with-simgear=$parent/usr \ --with-plib=$parent/usr \ --prefix=$parent/usr Isn't exactly a stock setup... And neither is shuffling libraries into non-standard directories. The system does not seem to be highly customised and generating a makefile that doesn't work cannot be passed off as just not working in the way expected. The issue seems to be the makefile expects to find OSG's libraries in $parent/usr/lib where they were specified to be, and he/his system placed them in a non-standard place. Look at his command line again. g++ -g -O2 -I/games/orig/usr -D_REENTRANT -L/games/orig/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm -losgFX -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm /usr/bin/ld: cannot find -losgFX He *told* it osg was in $parent/usr/ (and I am assuming $parent=/games/orig) and the makefile is telling g++ to look in -L/games/orig/usr/lib for libraries. Neither do people normally 'cry' bug whenever they have a problem. No, most people don't. This sort of exaggeration and misrepresentation of the circumstances doesn't get anyone anywhere. I don't find Martin's statements to be an exaggeration. John's 'Joe' the non-C++ programmer is a valid scenario. Implying that the problem only occurs when people don't understand the implications of what they're doing is like suggesting that people who can't do their own automobile maintenance and repairs shouldn't drive, or indeed, that people who can't fly an aircraft shouldn't travel by air. But people who can't fly an aircraft shouldn't expect to be able to solo, either. This is why package managers provide pre-built installable packages. Ron -- 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] configuration snafu
I'm glad to see people are cleaning up the autoconf stuff. Here's yet another area that needs some TLC: There appears to be little or no chance that the autoconf system will do the right thing on 64-bit machines. I'm hoping this will be easy for some autoconf guru to fix. I would imagine there are well-known standard techniques for coping with lib/lib64 issues. This is currently item #45 on this list of bugs: http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit -- 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
Re: [Flightgear-devel] configuration snafu
I don't doubt that there could be some lib vs. lib64 inconsistencies, but FilghtGear builds right out of the box for me on 64bit Fedora 12 ... no hitches at all that I recall and it has done so for quite some time. Regards, Curt. On Fri, Feb 5, 2010 at 11:11 AM, John Denker j...@av8n.com wrote: I'm glad to see people are cleaning up the autoconf stuff. Here's yet another area that needs some TLC: There appears to be little or no chance that the autoconf system will do the right thing on 64-bit machines. I'm hoping this will be easy for some autoconf guru to fix. I would imagine there are well-known standard techniques for coping with lib/lib64 issues. This is currently item #45 on this list of bugs: http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit -- 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 -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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
Re: [Flightgear-devel] configuration snafu
On 02/05/2010 02:38 PM, Curtis Olson wrote: I don't doubt that there could be some lib vs. lib64 inconsistencies, but FilghtGear builds right out of the box for me on 64bit Fedora 12 ... no hitches at all that I recall and it has done so for quite some time. Chez moi plib and simgear install into lib/ while osg installs into lib64/ How do you get around that? How do recommend I get around that? Obviously there are ways, but the only ways I know are complicated and devious ... not exactly out-of-the-box. -- 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
Re: [Flightgear-devel] configuration snafu
On Fri, Feb 5, 2010 at 4:05 PM, John Denker wrote: Chez moi plib and simgear install into lib/ while osg installs into lib64/ How do you get around that? How do recommend I get around that? Obviously there are ways, but the only ways I know are complicated and devious ... not exactly out-of-the-box. Well, I'm not sure I'm doing anything special. It has just worked for me so I have never dug in and tried to think about /lib vs. /lib64 with respect to FlightGear and it's dependencies. I've heard of others who have built just fine on 64bit machines, and 64 bit has been out in the wild for a few years now. Do you have details of the configure or make error you are seeing posted somewhere? My grandmother always said I had more luck than sense ... Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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
Re: [Flightgear-devel] configuration snafu
John Denker wrote: Chez moi plib and simgear install into lib/ while osg installs into lib64/ How do you get around that? Either install OSG from your favourite distribution or build with -D LIB_POSTFIX= 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
Re: [Flightgear-devel] configuration snafu
On 02/05/2010 03:17 PM, Curtis Olson wrote: Do you have details of the configure or make error you are seeing posted somewhere? Yes. Please take a look at http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit As it says there: make[1]: Entering directory `/mnt/games/orig/fgs/tests' g++ -DHAVE_CONFIG_H -I. -I../src/Include -I/games/orig/usr/include -I/usr/local/include -g -O2 -I/games/orig/usr -D_REENTRANT -MT est-epsilon.o -MD -MP -MF .deps/est-epsilon.Tpo -c -o est-epsilon.o est-epsilon.cxx mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po g++ -g -O2 -I/games/orig/usr -D_REENTRANT -L/games/orig/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm -losgFX -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm /usr/bin/ld: cannot find -losgFX collect2: ld returned 1 exit status The problem is not confined to the tests/ directory. If I let the make continue, there will be numerous errors. Basically every ld step fails. Additional root-cause analysis can be found on the aforementioned web page. If you need more details than that, please let me know. -- 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
Re: [Flightgear-devel] configuration snafu
How about ./configure --prefix=$parent Curt. On Fri, Feb 5, 2010 at 4:46 PM, John Denker j...@av8n.com wrote: On 02/05/2010 03:17 PM, Curtis Olson wrote: Do you have details of the configure or make error you are seeing posted somewhere? Yes. Please take a look at http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit As it says there: make[1]: Entering directory `/mnt/games/orig/fgs/tests' g++ -DHAVE_CONFIG_H -I. -I../src/Include -I/games/orig/usr/include -I/usr/local/include -g -O2 -I/games/orig/usr -D_REENTRANT -MT est-epsilon.o -MD -MP -MF .deps/est-epsilon.Tpo -c -o est-epsilon.o est-epsilon.cxx mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po g++ -g -O2 -I/games/orig/usr -D_REENTRANT -L/games/orig/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm -losgFX -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm /usr/bin/ld: cannot find -losgFX collect2: ld returned 1 exit status The problem is not confined to the tests/ directory. If I let the make continue, there will be numerous errors. Basically every ld step fails. Additional root-cause analysis can be found on the aforementioned web page. If you need more details than that, please let me know. -- 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 -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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
Re: [Flightgear-devel] configuration snafu
And for whatever it's worth, I've been using the default paths for installing osg (i.e. not specifying any other prefix, I don't know if that is a key difference in our setups.) Curt. On Fri, Feb 5, 2010 at 5:22 PM, Curtis Olson wrote: How about ./configure --prefix=$parent Curt. On Fri, Feb 5, 2010 at 4:46 PM, John Denker wrote: On 02/05/2010 03:17 PM, Curtis Olson wrote: Do you have details of the configure or make error you are seeing posted somewhere? Yes. Please take a look at http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit As it says there: make[1]: Entering directory `/mnt/games/orig/fgs/tests' g++ -DHAVE_CONFIG_H -I. -I../src/Include -I/games/orig/usr/include -I/usr/local/include -g -O2 -I/games/orig/usr -D_REENTRANT -MT est-epsilon.o -MD -MP -MF .deps/est-epsilon.Tpo -c -o est-epsilon.o est-epsilon.cxx mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po g++ -g -O2 -I/games/orig/usr -D_REENTRANT -L/games/orig/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm -losgFX -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm /usr/bin/ld: cannot find -losgFX collect2: ld returned 1 exit status The problem is not confined to the tests/ directory. If I let the make continue, there will be numerous errors. Basically every ld step fails. Additional root-cause analysis can be found on the aforementioned web page. If you need more details than that, please let me know. -- 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 -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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
Re: [Flightgear-devel] configuration snafu
I'm assuming a UNIX/Linux system. Does configure run clean? Look for libraries that it cannot find. If that's the problem, and if you're on a linux system, you'll need to tell configure where to find the libraries. I usually run: ./configure --help do.it Add comments before every line, then at the top put ./configure along with whatever flags configure needs. Hope that's helpful. ln is the linker and it is looking for the entry points to a library for a function used in the code. Curtis Olson wrote: How about ./configure --prefix=$parent Curt. On Fri, Feb 5, 2010 at 4:46 PM, John Denker j...@av8n.com mailto:j...@av8n.com wrote: On 02/05/2010 03:17 PM, Curtis Olson wrote: Do you have details of the configure or make error you are seeing posted somewhere? Yes. Please take a look at http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit As it says there: make[1]: Entering directory `/mnt/games/orig/fgs/tests' g++ -DHAVE_CONFIG_H -I. -I../src/Include -I/games/orig/usr/include -I/usr/local/include -g -O2 -I/games/orig/usr -D_REENTRANT -MT est-epsilon.o -MD -MP -MF .deps/est-epsilon.Tpo -c -o est-epsilon.o est-epsilon.cxx mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po g++ -g -O2 -I/games/orig/usr -D_REENTRANT -L/games/orig/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm -losgFX -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm /usr/bin/ld: cannot find -losgFX collect2: ld returned 1 exit status The problem is not confined to the tests/ directory. If I let the make continue, there will be numerous errors. Basically every ld step fails. Additional root-cause analysis can be found on the aforementioned web page. If you need more details than that, please let me know. -- 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 mailto:Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ -- 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 -- “I am for doing good to the poor, but I differ in opinion of the means. I think the best way of doing good to the poor, is not making them easy in poverty, but leading or driving them out of it. In my youth I travelled much, and I observed in different countries, that the more public provisions were made for the poor, the less they provided for themselves, and of course became poorer. And, on the contrary, the less was done for them, the more they did for themselves, and became richer.” – Ben Franklin -- 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
Re: [Flightgear-devel] configuration snafu
Curtis Olson wrote: It has just worked for me so I have never dug in and tried to think about /lib vs. /lib64 with respect to FlightGear and it's dependencies. I'd like to add that Brisa's script (an automated compilation script for PLIB, OSG, SG, FG, FGCOM, and FGRun) makes a simlink, OpenSceneGraph/lib that points to OpenSceneGraph/lib64 on 64-bit machines. This works for me out of the box. I hope this helps. -- 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
