To all whom it may concern, terragear has seen some bigger updates recently
and we are constantly working on improving the toolchain. This also includes
some cleanup and thus removal of older tools where better alternatives have
been developed in the last 12+ years.
I created a branch, named
To whom it may concern, the former terragear-cs repositories on
Gitorious as well as on the FlightGear MapServer have been renamed to
just terragear without the -cs.
Please update your .git/config files accordingly.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about
Hi all,
just checking out the lattest code as of 15min ago and found that
genapts is not being built/installed.
I checked my build process and found no errors and the program was
missing
can anyone help?
localhost terragear-cs # make install
[ 3%] Built target poly2tri
[ 10%] Built target
Maybe there is a missing dependency that silently discard genapt from the build
Regards,
-Fred
- Mail original -
De: Jason Cox
À: flightgear-devel@lists.sourceforge.net
Envoyé: Samedi 3 Mars 2012 23:41:41
Objet: [Flightgear-devel] terragear not building and installing genapts
Hi
@lists.sourceforge.net
Envoyé: Samedi 3 Mars 2012 23:41:41
Objet: [Flightgear-devel] terragear not building and installing genapts
Hi all,
just checking out the lattest code as of 15min ago and found that
genapts is not being built/installed.
I checked my build process and found no errors
Hello,
I think I've reached a good point to start applying changes to the
terragear repo. I can either start issuing merge requests, or, given
access, apply changes on a dev branch.
Which method is preferred by the terragear maintainers?
A couple other questions about future development.
1)
Hi Peter,
Peter Sadrozinski wrote:
I think I've reached a good point to start applying changes to the
terragear repo. I can either start issuing merge requests, or, given
access, apply changes on a dev branch.
I'd say have a branch, send me your Gitorious account name, please.
A couple
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server.
Artifacts are archived.
And the 64 bit flavor is available too
Regards,
-Fred
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
On Tue, 2011-11-08 at 22:15 +0100, Frederic Bouvier wrote:
- Mail original -
On 8 Nov 2011, at 19:59, Frederic Bouvier wrote:
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server.
Artifacts are archived.
Brilliant, thanks Fred.
I am still not sure about the
On 9 Nov 2011, at 15:32, Geoff McLane wrote:
In Ubuntu linux, because I do NOT have OSG installed in
any 'standard' place, in my makefg script, I do -
export CXXFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
export CFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
to get terragear-cs to cmake build...
In Ubuntu linux, because I do NOT have OSG installed in
any 'standard' place, in my makefg script, I do -
export CXXFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
export CFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
to get terragear-cs to cmake build...
Maybe the CFLAGS is not needed. I did try
On Wed, 2011-11-09 at 17:56 +0100, Frederic Bouvier wrote:
In Ubuntu linux, because I do NOT have OSG installed in
any 'standard' place, in my makefg script, I do -
export CXXFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
export CFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
to get terragear-cs to
Christian Schmitt wrote:
Can confirm the fix as well. It works all as expected. Waiting for your last
feedback now, Martin, before preparing the merge.
I'm pretty certain the crash in 'fgfs-construct' is unrelated, just the
usual issue we already know. Therefore I'd vote to merge the CMake
Martin Spott wrote:
I'm pretty certain the crash in 'fgfs-construct' is unrelated, just the
usual issue we already know. Therefore I'd vote to merge the CMake
branch - just in case, we'd fix the remaining issues in master.
Done. If someone could remove the cmake branches, that'd be nice. :)
On 8 Nov 2011, at 09:57, Christian Schmitt wrote:
Done. If someone could remove the cmake branches, that'd be nice. :)
I'll do so, thanks for the merge.
Onwards with fixing the fgfs-construct crashes!
James
--
Hi,
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server. Artifacts are
archived.
Regards,
-Fred
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
Fred wrote:
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server. Artifacts are
archived.
Wow, thanks a lot!! I've been waiting for that ever since 2009 :)
Gijs --
On 8 Nov 2011, at 19:59, Frederic Bouvier wrote:
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server. Artifacts are
archived.
Brilliant, thanks Fred.
James
--
RSA(R) Conference 2012
Save $700 by Nov 18
- Mail original -
On 8 Nov 2011, at 19:59, Frederic Bouvier wrote:
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server.
Artifacts are archived.
Brilliant, thanks Fred.
I am still not sure about the right method to exclude OSG from the build.
I added
James Turner wrote:
This is fixed now, though I don't really understand how it ever
worked - rawdem.c wasn't checking a particular return code nicely,
now it does.
Thanks a lot, things are looking much better now ! I'll perform a few
more tests and will report back.
In the meantime we
On 7 Nov 2011, at 11:33, Martin Spott wrote:
Thanks a lot, things are looking much better now ! I'll perform a few
more tests and will report back.
In the meantime we managed to established a method to reliably create
topologically clean !! CORINE land cover from the publicly available
On Mon, Nov 7, 2011 at 12:33 PM, Martin Spott martin.sp...@mgras.net wrote:
James Turner wrote:
This is fixed now, though I don't really understand how it ever
worked - rawdem.c wasn't checking a particular return code nicely,
now it does.
Thanks a lot, things are looking much better now !
Martin Spott wrote:
Thanks a lot, things are looking much better now ! I'll perform a few
more tests and will report back.
Can confirm the fix as well. It works all as expected. Waiting for your last
feedback now, Martin, before preparing the merge.
In the meantime we managed to
On 3 Nov 2011, at 18:51, James Turner wrote:
... going to be something really obscure when we track this down, I guess
This is fixed now, though I don't really understand how it ever worked -
rawdem.c wasn't checking a particular return code nicely, now it does.
James
On 2 Nov 2011, at 19:48, Martin Spott wrote:
Fixed now, at least, it generated a ton of .dem files for me.
Really ? And you're on simgear/next and terragear-cs/cmake-integration
without local changes ?
With some local changes to Simgear/next, but I am 'fairly sure' they don't
relate to
James Turner wrote:
On 2 Nov 2011, at 19:48, Martin Spott wrote:
Fixed now, at least, it generated a ton of .dem files for me.
Really ? And you're on simgear/next and terragear-cs/cmake-integration
without local changes ?
With some local changes to Simgear/next, but I am 'fairly sure'
James Turner wrote:
With some local changes to Simgear/next, but I am 'fairly sure' they don't
relate to path/file/string handling. (Some changes in the SGOceanTile
handling)
I just tested this as well (without your fix) and it works here too. Even
when using Martin's pathnames.
Christian Schmitt wrote:
Martin: Can you tell me under which OS this is happening? So I can try to
reproduce it in a VM.
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Martin.
--
Unix _IS_ user friendly - it's just selective
Martin Spott wrote:
Christian Schmitt wrote:
Martin: Can you tell me under which OS this is happening? So I can try to
reproduce it in a VM.
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
I guess it matters, because I get exactly
Martin Spott wrote:
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Ok, I observed the following: compiling the raw2ascii as Release leads to
the error (on Debian). When compiling as Debug it works here.
Chris
On Thu, Nov 3, 2011 at 8:19 AM, Christian Schmitt wrote:
Martin Spott wrote:
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Ok, I observed the following: compiling the raw2ascii as Release leads to
the error (on Debian). When compiling
On 3 Nov 2011, at 13:19, Christian Schmitt wrote:
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Ok, I observed the following: compiling the raw2ascii as Release leads to
the error (on Debian). When compiling as Debug it works here.
James Turner wrote:
I've pushed a fix to Simgear, updated the tests, and now I can run hgtchop
happily with latest simgear and terragear.
Not only can I hgtchop, but also build scenery chunks again. So from my
point of view the problems are solved. Are there any objections against
pushing
Christian Schmitt wrote:
Not only can I hgtchop, but also build scenery chunks again. So from my
point of view the problems are solved. Are there any objections against
pushing the changes to master?
Yes, raw2ascii doesn't work with both simgear and terragear-cs
HEAD and therefore demchop
Hi Jason
You can open a terminal in the terragear-cs directory and type:
git show
The first lines show the commit ID, committer and short description for
the last commit, and the commit ID is the version information you are
looking for,
Hope this helps,
Tom
On Tue, Nov 1, 2011 at 2:43
Martin Spott wrote:
Yes, raw2ascii doesn't work with both simgear and terragear-cs
HEAD and therefore demchop is still untested. I'll provide a test
case as soon as time permits - spare time is a bit tight these days.
Ok, try this - get the data files from:
On 2 Nov 2011, at 18:33, Martin Spott wrote:
In normal operation, raw2ascii should almost immediately start
writing lots of files to ${WORKDIR}/SRTM-30-ASCII/e020n90/, but with
current simgear/terragear-cs I'm just getting an insane number of
lines:
Thanks Martin, will take a look.
James
On 2 Nov 2011, at 18:51, James Turner wrote:
In normal operation, raw2ascii should almost immediately start
writing lots of files to ${WORKDIR}/SRTM-30-ASCII/e020n90/, but with
current simgear/terragear-cs I'm just getting an insane number of
lines:
Thanks Martin, will take a look.
Fixed
Tom
thanks for that
terragear-cs81244fb0fe41dfc9d87b28baffdd5754b3801952
simgear 6250f675db9fdd6f2aef7be43207cd0ac0b6baeb
Jason
On Wed, 2011-11-02 at 07:12 -0700, Tom P wrote:
Hi Jason
You can open a terminal in the terragear-cs directory and type:
git show
The
James Turner wrote:
On 2 Nov 2011, at 18:51, James Turner wrote:
In normal operation, raw2ascii should almost immediately start
writing lots of files to ${WORKDIR}/SRTM-30-ASCII/e020n90/, but with
current simgear/terragear-cs I'm just getting an insane number of
lines:
Thanks Martin,
Jason Cox wrote:
I would try a larger area, say 1x1 deg or larger and then and then you
will see the list grow to include tiles that are no longer needed.
I created a 2x3 degree area. No problems. What terragear-cs version do you
use and against which simgear do you compile it?
Will now
Chris,
short of knowing how to tell versions of code with git all I can say is
that I pulled the repo on the 20th of October for both terragear-cs and
compiled it against the main simgear of the same day.
If there is a way to ask git the version then let me know and I will
report back for you.
Ok so I am replying to myself.
after running fgfs-construct for the last 10+ hours at nice -20 and
still going I have the following info.
I ran lsof on the PID and have found that it is still holding all SRTM2
arr and fit files open. This is the probable cause of the memory leak
that I am
Hi Jason,
I just tried to reproduce this issue here. Generating some scenery around
LOWI with 850 airport layouts, I only see always two SRTM files open: the
arr.gz and fit.gz for the tile that is currently built. So no problems here.
What confuses me a bit is you using SRTM-2 files. What is
Christian Schmitt wrote:
Jason Cox wrote:
I ran lsof on the PID and have found that it is still holding all SRTM2
arr and fit files open. This is the probable cause of the memory leak
that I am seeing.
What confuses me a bit is you using SRTM-2 files. What is this and how does
hgtchop
Thats correct.these are the files created from SRTM data by hgtchop and
terrafit
Jason
On Mon, 2011-10-31 at 11:30 +, Martin Spott wrote:
Christian Schmitt wrote:
Jason Cox wrote:
I ran lsof on the PID and have found that it is still holding all SRTM2
arr and fit files open. This is
Christian,
what I am finding i that the larger the area being built the more of
these files are being opened and not closed.
I would try a larger area, say 1x1 deg or larger and then and then you
will see the list grow to include tiles that are no longer needed.
Jason
On Mon, 2011-10-31 at
Jason Cox wrote:
[...]--xdist=15 --ydist=35
[...]
is it not appropriate to issue a build of such a large area?
Not really ;-)
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Jason Cox wrote:
is it not appropriate to issue a build of such a large area?
should I use smaller chunks?
should terragear not be releasing the memory after building a tile?
Generally speaking, sometimes it works, sometimes it doesn't. And yes, it
should free unused memory after finishing a
Chris,
As I am not a programmer, what info do you need and who do I collect it?
Jason
On Sat, 2011-10-29 at 13:47 +0200, Christian Schmitt wrote:
Jason Cox wrote:
is it not appropriate to issue a build of such a large area?
should I use smaller chunks?
should terragear not be
Hi all,
I am currently build a large chunk of scenery for SE Australia and have
found a problem with terragear's memory usage. most of the data I am
building is low quality until I get to around S30 to S35 however I have
only gotten to S36 using the following command ad the memory usage of
Christian Schmitt wrote:
[...] These changes are not yet in the master tree, but can be tested in the
topics/cmake-integration branch. Please do so, if possible, so we can iron
out any showstoppers.
Apparently directory path handling has been changed recently in a way
which prevents
On 26 Oct 2011, at 13:13, Martin Spott wrote:
Apparently directory path handling has been changed recently in a way
which prevents 'terrafit' from recursively walking the given directory
tree.
This issue is with cmake-integration/CMake, cmake-integration/Autoconf
but master/Autoconf is
Martin Spott wrote:
Apparently directory path handling has been changed recently in a way
which prevents 'terrafit' from recursively walking the given directory
tree.
This issue is with cmake-integration/CMake, cmake-integration/Autoconf
but master/Autoconf is fine. I'm also observing a
On 26 Oct 2011, at 13:34, Martin Spott wrote:
I was interrupted when writing the above As an addition I'd
propose to separate the de-PLIB-ifying from the 'cmake-integration'
into a separate branch/topic/whatever because the move to CMake as a
build system appears to be successful.
A
On Wed, 2011-10-26 at 13:19 +0100, James Turner wrote:
On 26 Oct 2011, at 13:13, Martin Spott wrote:
Apparently directory path handling has been changed recently in a way
which prevents 'terrafit' from recursively walking the given directory
tree.
This issue is with
James Turner wrote:
Can you describe / give me a minimal test setup?
Difficult, because 'hgtchop' doesn't work any more either, not even
with terragear-cs/master ;-)
Try this one for the preparational step - adapt from my setup:
DATADIR=${HOME}/archive/GIS/GISData/SRTM/version2_1/HGT/SRTM3
Geoff McLane wrote:
An error something like -
'do not know how to make main.c from main.o'
which I did NOT understand... seems reversed!
And why 'main.c', since the Makefile.am shows
only -
raw2ascii_SOURCES = main.cxx rawdem.c rawdem.h
There is no main.c here???
Hi,
this is caused
James Turner wrote:
A fair suggestion! I originally combined them because it was easier not to
worry about PLIB when creating the CMake files, but I wasn't expecting the
slightly-complex changes to de-PLIB the file handling code.
Let me see how hard it would be, to un-pick the changes.
On Wed, 2011-10-26 at 15:38 +0200, Christian Schmitt wrote:
Geoff McLane wrote:
An error something like -
'do not know how to make main.c from main.o'
which I did NOT understand... seems reversed!
And why 'main.c', since the Makefile.am shows
only -
raw2ascii_SOURCES = main.cxx
James Turner wrote:
Can you describe / give me a minimal test setup?
I'm really running out of ideas and my buget of testing time for today
(maybe this week) is exhausted. I've tested various pairings of
'simgear' and 'terragear-cs', unfortunately without getting a 'hgtchop'
creating
On 26 Oct 2011, at 18:43, Martin Spott wrote:
I've tested various pairings of
'simgear' and 'terragear-cs', unfortunately without getting a 'hgtchop'
creating subdirectories and/or files. Anyhow I'd like to hear from
others being more successful with using recent versions of the
Hi there,
maybe you have noticed some exceptionally high activity in recent days/weeks
on the Terragear repo. Well, there is one particular reason for it: It now
supports the cmake build system and, as of today, does no longer depend on
plib. These changes are not yet in the master tree, but
Martin Spott wrote:
We're not yet there. On a first test earlier today, 'genapts' ended in
a segfault with the recent changes but I ran out of time, thus I
have not yet verified if the source change in 'simgear' really was the
culprit,
Confirmed here. And I thought first it was the
Martin Spott wrote:
We're not yet there. On a first test earlier today, 'genapts' ended in
a segfault with the recent changes but I ran out of time, thus I
have not yet verified if the source change in 'simgear' really was the
culprit,
Confirmed here. And I thought first it was the
Whil I was trying to catch up with old *Terra*-EMail, I found this
one:
Geoff McLane wrote:
Maybe you missed my 'little' question buried deep
in my, as usual ;=(), quite log posts, but I was
asking about the 'content' of mapserver
simgear-cs git...
simgear-cs had been a requirement for
Csaba Halász wrote:
Also note, installing libgdal1-dev would have pulled in most of these
automatically.
BTW, for those who are running Debian, I'd recommend to pull the
respective GIS packages from:
http://debian.gfoss.it/
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just
Geoff McLane wrote:
I am sorry Martin. I read your post MANY times,
but you will have to provided more clues for this
old brain to cotton onto ;=)). I do not quite catch
what you can mean by scenery root node?
In order to tell FlightGear where to find its Scenery we're currently
feeding a
I am asking because I am currently working on Alaska elevation data for
the relief. I had to clip 6 px overlap and I converted the .flt data to
DEM format. HGT can not handle 1800x1800 px, but there is also a demchop
in terragear, right?
I like to share the data when it is useful for scenery
When someone wants to run experiments with this data, you can find
some test data in .dem format here:
http://maptest.fgx.ch/public/2arc-alaska-dem/n70w140.zip
Thanks a lot, Yves
Am 07.10.11 12:07, schrieb HB-GRAL:
I am asking because I am currently working on Alaska elevation data for
the
Hi all
Can terragear handle 2 arc second elevation data ? I read only about 1
arc and 3 arc data for the terragear toolchain.
Cheers, Yves
--
All the data continuously generated in your IT infrastructure contains a
You might need to do some work with the tool that chops up the dem's into
TerraGear tile sizes. There are different terrain formats so you might need
to adapt the code to read a different format as well. This part sounds like
it should be pretty straightforward if you have clear docs for the
While we're a it: The main terragear-cs repository has now moved to
Gitorious as a new repository within the FlightGear project, so those,
who'd like to develop TerraGear using Gitorious don't need to maintain
their private spin-off's.
Instead, feel invited to create personal clones of the main
Christian Schmitt wrote:
Hi there,
i just want to announce that I added support for the 850 apt.dat runways
to genapts. This work is thought as a compliment to the currently ongoing
development towards curved taxiways.
The current state is that genapts reads runways and creates them
Hi there,
i just want to announce that I added support for the 850 apt.dat runways to
genapts. This work is thought as a compliment to the currently ongoing
development towards curved taxiways.
The current state is that genapts reads runways and creates them
accordingly.
Features:
-different
Durk Talsma wrote:
I'm explicitly deleting all the Triangle and Edge objects. This has
improved performance a lot I'm still not able to process the entire
Eurasian continent in one pass, after this fix, the total number of
.fit files that can be created on my linux box has gone up from
On Sunday, August 14, 2011 15:20:10 Durk Talsma wrote:
Hi Adrian,
I realize that it's almost three quarters of a year since your message was
posted, but it wasn't until today that it caught my attention.
Hi Durk,
As they say, it's never too late to fix a bug. I remember encountering these
Hi Adrian,
I realize that it's almost three quarters of a year since your message was
posted, but it wasn't until today that it caught my attention. Earlier this
weekend I decided to pull the latest version of terragear-cs from it's GIT
repository, in order to see whether I could build some
On Thu, 2011-06-02 at 03:12 +0200, Geoff McLane wrote:
Hi Jason,
When you say a 'long time', do you mean more than
this, like DAYS? ;=(( Just trying to get an idea
of how 'patient' one MUST be... before deciding
something is really going 'wrong'...
I have found that the standard set
Geoff McLane wrote:
Thanks. It is good to know that the -
Default=x, where x = 0-2 is 'normal', but
Chris reported that it was still running after
6 hours, or more... and still unable to exactly
find where this is output, in the code...
You won't be able to find Default in the sources as
Chris/Geoff,
I normally see reams of these and other similar lines.
I think that you are seeing some form of count for terrain type.
My usual output has other textures mixed in there and only ever 3 as
the number expressed.
If you are using a hight level of detail (OSM residental) and processing
Geoff McLane wrote:
It is certainly _NOT_ 'normal' behavior, and
historically (I assume Curt ;=)) implemented some
draconian 'rlimit' - setrlimit(RLIMIT_CPU,timeout),
to abort after a period of time, which is just
NOT available in my WIN32 environment, to avoid
such a 'forever' loop...
Hi,
Geoff, I applied both of your patches, see here:
https://gitorious.org/papillon81/terragear-cs
Until now I had no crashes or negative effects on the resulting scenery.
However, there IS a problem, unrelated to your patches, for which I hope to
get some help.
I create large chunks of scenery
Hi Chris,
Glad the rough 'fixes' I provided worked a little
for you... have yet to clone your 'papillon81'
clone, and try it... but...
While it is agreed on this list everyone seems to
really _LOVE_ extreme brevity, (perhaps except
me ;=)), your post just did not tell me
enough ;=((
I
On Sat, 28 May 2011, Geoff McLane wrote:
Hi all,
I read (everywhere) that a vector erase invalidates
all current iterators - see say -
http://www.cplusplus.com/reference/stl/vector/erase/
so I really do not understand why genfans.cxx has lasted
so long like it is ;=((
When it does a -
On Sun, 2011-05-29 at 09:55 +0200, Anders Gidenstam wrote:
On Sat, 28 May 2011, Geoff McLane wrote:
Hi all,
I read (everywhere) that a vector erase invalidates
all current iterators - see say -
http://www.cplusplus.com/reference/stl/vector/erase/
so I really do not understand why
Geoff McLane wrote:
It certainly works better for me ;=)) And removes
another reason why fgfs-construct can abort
without apparent reason!
Hi,
you mean segfaults with no apparent reason? I experience them under Linux
when building huge scenery chunks and if your patch improves the situation,
On Sun, 2011-05-29 at 11:45 +0200, Christian Schmitt wrote:
Geoff McLane wrote:
It certainly works better for me ;=)) And removes
another reason why fgfs-construct can abort
without apparent reason!
Hi,
you mean segfaults with no apparent reason? I experience them under Linux
when
Hi all,
I read (everywhere) that a vector erase invalidates
all current iterators - see say -
http://www.cplusplus.com/reference/stl/vector/erase/
so I really do not understand why genfans.cxx has lasted
so long like it is ;=((
When it does a -
tris.erase( t_current );
it should reset
Hi Csaba,
you have probably forgotten to run apt-file update
recently.
LOL! Up until a few days ago, when you mentioned it, I
had never heard of 'apt-file' ;=)) let alone updated it!
Up until just a few wee years ago, I was a windows ONLY
person, and still do most stuff in there, but I now
On Mon, 2011-05-02 at 19:52 +0200, Csaba Halász wrote:
[]
unixodbc-dev: /usr/lib/libodbcinst.so
The last is the one to install (it will pull in the dependencies as needed).
Hi Csaba,
Many thanks for the pointer. Have now installed -
$ sudo apt-get install unixodbc-dev
and that certainly also
On Tue, May 3, 2011 at 7:33 PM, Geoff McLane ubu...@geoffair.info wrote:
But even after that install, the command -
$ apt-file search libodbcinst.so
still shows 'nothing' ;=((
apt-file search searches the package lists, not the installed files.
If it shows nothing, that means you have
On Mon, May 2, 2011 at 7:41 PM, Geoff McLane ubu...@geoffair.info wrote:
BUT ran out of PUFF on the next -lodbcinst ;=))
There seems NO libodbcinst* in my system, although
there is a -
/usr/bin/odbcinst
which, when run, just outputs -
unixODBC 2.2.11
but how to get a 'library'???
$
Geoff McLane wrote:
Hi Martin,
Maybe you missed my 'little' question [...]
I hear your voice, I'm just a little bit too busy with real life for
writing an appropriate response. I hope I'll be able to do so before
LinuxTag,
Martin.
--
Unix _IS_ user friendly - it's just selective
Hi Martin,
Maybe you missed my 'little' question buried deep
in my, as usual ;=(), quite log posts, but I was
asking about the 'content' of mapserver
simgear-cs git...
In windows I was able to build terragear-cs
using 'standard' gitorious simgear, and others,
as far as I see so far, seem to have
On Thu, Apr 28, 2011 at 12:46 AM, Arnt Karlsen a...@c2i.net wrote:
On Wed, 27 Apr 2011 15:13:21 +0200, Geoff wrote in message
1303910001.6472.18.camel@DELL02:
..if you bother to try that approach with my post to the list,
you may see I addressed the list with this implied question:
In file
On Thu, 2011-04-28 at 13:40 +0200, Csaba Halász wrote:
[]
NULL has never been officially defined in any C++ header that I know.
So code that relies on that is broken.
[]
Hi Csaba,
It is interesting you say that... do you have a reference?
Always interested to learn, know more ;=))
But the 2
On Thu, Apr 28, 2011 at 6:24 PM, Geoff McLane ubu...@geoffair.info wrote:
On Thu, 2011-04-28 at 13:40 +0200, Csaba Halász wrote:
[]
NULL has never been officially defined in any C++ header that I know.
So code that relies on that is broken.
[]
It is interesting you say that... do you have a
Hi Gijs,
together with some other updates
Oops, you need to ADD Road between Rice and
Rock. A missing material...
I was quite surprised when cs_sand got matched with
Sclerophyllous - which I had to look up - until
I patched the CSMater list ;=)) adding Road...
Just one missing so no patch
On Wed, 27 Apr 2011 01:48:16 +0200, Arnt wrote in message
20110427014816.1e848151@celsius.local:
..snip local fixes.
..next run dies with:
./maketg PLIBPATH=/usr BOOSTPATH=/usr OSGPATH=/usr TGUPD NOPAUSE
snip
make[3]: Leaving directory
`/home/arnt/FG-git/terragear-cs/src/Lib/TriangleJRS'
1 - 100 of 221 matches
Mail list logo
