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
