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 LDFLA
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 ho
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
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 an
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
> >
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=
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 check
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_
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 mak
* confdefs.h. */
Regards
Sid.
===
Message: 2 Date: Mon, 08 Feb 2010 08:53:47 -0700 From: John Denker
Subject: Re: [Flightgear-devel] configuration snafu To:
FlightGear developers discussions
Message-ID:
<4b70338b.2
On Mon, Feb 8, 2010 at 10:20 PM, John Denker 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
>
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 particul
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 o
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
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 :-
C
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 h
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.
Th
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
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 sho
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 *
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 l
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
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
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
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 sy
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 w
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
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 becau
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..
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 e
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 in
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 troub
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
On Sat, Feb 6, 2010 at 8:49 PM, Curtis Olson 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 o
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
On Sat, Feb 6, 2010 at 8:39 PM, Csaba Halász wrote:
> On Sat, Feb 6, 2010 at 5:17 PM, Tim Moore wrote:
> >
> > On Sat, Feb 6, 2010 at 4:18 PM, John Denker wrote:
> >>
> >> On 02/06/2010 07:54 AM, Csaba Halász wrote:
> >>
> >> > On 64 bit systems /lib64 should really be a symlink to /lib (simila
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
versio
On Sat, Feb 6, 2010 at 5:17 PM, Tim Moore wrote:
>
> On Sat, Feb 6, 2010 at 4:18 PM, John Denker 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
On Sat, Feb 6, 2010 at 4:18 PM, John Denker 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.
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 fri
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
On Fri, Feb 5, 2010 at 11:05 PM, John Denker 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
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
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
-
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, OpenScene
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
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.
>
>
>
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/f
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++
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 i
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 exac
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
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 wrote:
> I'm glad
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
54 matches
Mail list logo
