You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(4) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(12) |
Feb
(4) |
Mar
|
Apr
(6) |
May
(24) |
Jun
|
Jul
(1) |
Aug
(6) |
Sep
(16) |
Oct
(3) |
Nov
(40) |
Dec
(2) |
2003 |
Jan
(18) |
Feb
(14) |
Mar
(12) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(3) |
Aug
(3) |
Sep
(7) |
Oct
(30) |
Nov
(12) |
Dec
(1) |
2004 |
Jan
(4) |
Feb
(1) |
Mar
(23) |
Apr
(4) |
May
(9) |
Jun
(3) |
Jul
(13) |
Aug
(3) |
Sep
(2) |
Oct
(2) |
Nov
(6) |
Dec
(6) |
2005 |
Jan
(109) |
Feb
(40) |
Mar
(7) |
Apr
(7) |
May
(9) |
Jun
(10) |
Jul
|
Aug
(18) |
Sep
(18) |
Oct
(34) |
Nov
(9) |
Dec
(4) |
2006 |
Jan
(25) |
Feb
(3) |
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
(5) |
Aug
(8) |
Sep
(8) |
Oct
(25) |
Nov
(34) |
Dec
(12) |
2007 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
(2) |
Jul
(17) |
Aug
(10) |
Sep
(3) |
Oct
(5) |
Nov
(23) |
Dec
(70) |
2008 |
Jan
(50) |
Feb
(14) |
Mar
|
Apr
(15) |
May
(5) |
Jun
|
Jul
(2) |
Aug
(7) |
Sep
(5) |
Oct
(5) |
Nov
|
Dec
|
2009 |
Jan
(44) |
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
(129) |
Jul
(39) |
Aug
(6) |
Sep
(5) |
Oct
(20) |
Nov
(5) |
Dec
(9) |
2010 |
Jan
(10) |
Feb
(20) |
Mar
(17) |
Apr
(94) |
May
(114) |
Jun
(82) |
Jul
(1) |
Aug
(9) |
Sep
(2) |
Oct
(6) |
Nov
(10) |
Dec
(20) |
2011 |
Jan
(13) |
Feb
(5) |
Mar
(54) |
Apr
(4) |
May
|
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(9) |
Oct
(84) |
Nov
(7) |
Dec
(13) |
2012 |
Jan
(17) |
Feb
(5) |
Mar
(3) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
(1) |
Nov
(31) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Geoff M. <ub...@ge...> - 2021-03-04 21:14:12
|
Hi Russ, Sorry for the delay in getting back to you... Also in Ubuntu 20.04 I just re-cloned the hg source code, using - hg clone ssh://<name>@hg.code.sf.net/p/atlas/hgcode atlas Unless you have a sf.net account, and have uploaded a ssh *.pub, you should use the read-only clone - hg clone http://hg.code.sf.net/p/atlas/hgcode atlas And it built fine, using the info in the README doc - ``` To build under Unix, follow these steps: autoreconf --install ./configure --prefix=/media/Disk2/FG/fg24/install/atlas make make install ``` Note, I used a `local` folder for the install... The `make`, and `make install` ran without errors... this put the executable in - /media/Disk2/FG/fg24/install/atlas/bin I had previously downloaded `fgdata` - all 5.45GB worth, using - git clone https://git.code.sf.net/p/flightgear/fgdata fgdata **OR**, because sometimes SF breaks, from an official FG mirror - git clone https://gitlab.com/flightgear/fgdata.git in my case into - /media/Disk2/FG/fg24/install/flightgear/fgdata And I copied a big block of FG scenery 2.0 around KSFO, into - /media/Disk2/FG/fg24/install/S-KSFO about 1.6GB worth... Then in /media/Disk2/FG/fg24/install/atlas/bin, ran ./Atlas with - ./Atlas --fg-root=../../flightgear/fgdata --atlas=../share/Atlas --fg-scenery=../../S-KSFO Note, the 3 parameters, with relative paths, used... And an Atlas window came up - click the [Render] button, and in a short time had atlas with KSFO, and generate scenery... See screenshot: http://geoffair.com/tmp/tests/Screenshot_2021-03-04.png Maybe there is a problem with the `old code` in CVS, and the zip! Not sure... not tried... but everything works fine using the `hg` cloned code... HTH, Regards, Geoff. |
From: Geoff M. <ub...@ge...> - 2021-03-04 19:50:28
|
PS: Just ran `./Atlas --version` and it shows - "Atlas version 0.6.0" You showed version 0.3.0, so maybe, as suggested, the CVS, and tar.gz srcs are /NOT/ the latest version! Regards, Geoff. |
From: russ l. <ly...@gm...> - 2021-01-03 00:14:44
|
Ubuntu 20.04 g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Atlas version Atlas-0.3.0 (download today from Atlas Sourceforge site) When trying to build Atlas I get the following errors Error from CVS tiles.h:182:272: error: narrowing conversion of ‘255’ from ‘int’ to ‘char’ [-Wnarrowing] The above error appears once for each 0xff in the array. I can make this error go away by adding unsigned before char in the file. However, then there are the other conversion errors that stop the process. Error from tar.gz Atlas.cxx: In function ‘bool parse_nmea(char*)’: Atlas.cxx:347:6: error: ‘cout’ was not declared in this scope 347 | cout << " nav1_freq = " << nav1_freq_str << endl; | ^~~~ Atlas.cxx:347:51: error: ‘endl’ was not declared in this scope; did you mean ‘end’? 347 | cout << " nav1_freq = " << nav1_freq_str << endl; | ^~~~ | end make[3]: *** [Makefile:405: Atlas.o] Error 1 autogen.sh is missing What can I do? |
From: Geoff M. <ub...@ge...> - 2016-07-29 14:01:25
|
Hi Brian, There does seem a problem the `.` files, like .hgeol... I added a .hgignore in WIN32, and do not like what I see now in linux... it is mixed... I guess we would have to watch for this... maybe something could be added somewhere to fix this... The main thing is, it is correctly converting the src files... this avoids the noise and changes made by MSVC editor... Regards, Geoff. |
From: Geoff M. <ub...@ge...> - 2016-07-29 13:32:27
|
Hi Brian, Re: atlas-eol test repo In Windows got a sample.text with CRLF, and just LF in Ubuntu Added a 'win.txt' in Windows, with CRLF, and pushed, and when I pulled in linux I get just LF... The binary png remains unchanged in all cases... Strangely, the .hgeof remains unchanged, with LF only, but I can live with that... should never need be touched again... Then in linux, created a u.c, naturally with LF, and pushed... and as expected when pulled/updated in Windows, it has CRLF... All seems to be working... Regards, Geoff. |
From: Brian S. <bsc...@us...> - 2016-07-29 03:57:19
|
>>>>> "Geoff" == Geoff McLane writes: Geoff> Hi Brian, Re: New Atlas Mercurial repository Geoff> Many, many thanks for adding a Mercurial (hg) repo... I never Geoff> quite got with CVS commands, but hg seems much closer to git, Geoff> which I use all the time... so opens a way for me to Geoff> participate again... some learning... but looks good... [...] I created a test repository in the Atlas project on SourceForge called "EOL". It contains a .hgeol file. Clone it and see if you get the proper line endings. Brian -- Your file was so big. It might be very useful. But now it is gone. - Haiku error message |
From: Geoff M. <ub...@ge...> - 2016-07-28 17:57:46
|
Hi Brian, > ... Any development will be in local repositories ... Hmmm, yes, that is where all **change** starts... > ... only ... push ... when it's been checked... Well how do I get those changes **checked**? I have multiple windows and unix systems... I do most development in Windows 10 - 64-bit... But how do I **check** it in Ubuntu, Raspbian, etc, etc, ... without pushing anything... so I, and you, can pull and test the updates in **all** other systems... In git, this can be done in a **branch**... say `next`... we can all switch to `next`, pull and test... only when 100% satisfied would `next` be merged back to `master`... In reading more about Mercurial (hg) while it has some similarities, it seems branches are more persistent in hg, but maybe need to read and understand more on this... So there is still the question of how to push changes, and be able to do cross-platform checking, and not changing the **stable** `tip`, until tested and ready??? Re: native line endings Well, never did much in CVS, but quickly checking a few CVS repos I still have, including a 2013 Atlas cvs, **all** files are in the native, CRLF format in this case, so maybe CVS handled that also... maybe I had to do some setup to get that... do not remember... I think SVN was the same, but none to quickly check... The many, **many!**, git repos I work on, it is never a problem... that is all files have native eol, CRLF in Windows, LF in *nix... I remember some global config option on this... but once setup, just happens... Now, as I understand it, setting up hg requires the addition of a .hgeol file to the root... containing - [patterns] ** = native It seems this says nothing more than use `native` eol for all files locally, and continue the LF default in the remote... Of course, this does not apply to **binary** files - that is any file with `\0`... Look forward to your further testing of this... Re: Windows port As you may know the first step in this is accepting using CMake to do the configuration, and generation of native build files... Of course, the default in *nix is a Makefile... but each system has quite a number of build file systems supported... So that means replacing `configure.ac`, `Makefile.am`, etc, with a CMakeLists.txt file, and a CMakeModules/ directory... Once this is started, again I can make sure Atlas builds, in Windows with MSVC and MinGW (32/64-bit), even `nmake`, in multiple *nix with `make`... I can not test in a MAC... do not have one... but cmake is a very mature cross-platform tool... and do work with some other mac users in other projects, using cmake... Then for sure we can have multiple **new** binaries hosted on sourceforge ;=)). Re: Web Site - http://atlas.sourceforge.net/ If you like, I could tidy up a few broken links on the web site... like the CVS link, and add the new HG link, etc, etc, etc... but... > ... as long as there are few (ie, 1) main > developers... Hmmm, a `few` and `1` do not seem compatible! And can not be `developer(S)` if just one... so is this a typo??? Or, your preference **is** 1? Then I can go back to only working with my gitlab atlas-g (git) fork... and I have an idea for an atlas-hg GitHub (git) fork of the sf hg... no problem... sorry to have disturbed you... Just a bit confused... as stated, a great app, with some great features and additions, not yet offered by the `Phi` moving map... Regards, Geoff. |
From: Brian S. <bsc...@us...> - 2016-07-28 05:04:19
|
>>>>> "Geoff" == Geoff McLane writes: Geoff> Hi Brian, Re: New Atlas Mercurial repository Geoff> Many, many thanks for adding a Mercurial (hg) repo... I never Geoff> quite got with CVS commands, but hg seems much closer to git, Geoff> which I use all the time... so opens a way for me to Geoff> participate again... some learning... but looks good... I found Mercurial much easier to understand than Git (perhaps it just has better documentation), so I decided to go that route. I should say that for now I want to keep things dead simple - no branches, no bookmarks, no nothing - just a single repository that represents *stable* code. Any development will be in local repositories, and I only want to push to the SourceForge repository when it's been checked. I think that should work as long as there are few (ie, 1) main developers. If, in the future, there is more activity, then we might want to look at either adding branches, or a separate development clone. Geoff> The next problem I had is that hg does not write the source Geoff> files in native CRLF format of windows, and needed a few Geoff> steps to get that working... after quite a bit of reading... Just out of curiousity, what happened when using CVS? I never thought about the problem, but surely you must have encountered much the same thing before? Geoff> Summary: Mercurial Distributed SCM (version 3.8.4) - Windows Geoff> 10 - 64-bit [...] Geoff> So I am now in a position to do a Windows port, as in the Geoff> past... if there is any interest... Geoff> Before I do that will try a trivial file change, push, and Geoff> check that all is well... Geoff> But, the question is do you want to add a public .hgeol to Geoff> the repo? It seems like a good idea, but I want to play around with it first, and make sure I understand what's going on. I'll let you know when I have things set up (although you probably get notified about changes, and if a .hgeol file shows up in the repository, that means it's been set up). Geoff> Anyway, thanks for moving Atlas onward... your addition of Geoff> building the maps, on the fly, worked great with my terrasync Geoff> scenery... had a few hundred `map` in minutes... Excellent. Once we get this .hgeol business set up, then we can think about hosting a Windows excecutable on SourceForge. Brian -- Aborted effort. Close all that you have worked on. You ask far too much. - Haiku error message |
From: Geoff M. <ub...@ge...> - 2016-07-26 18:52:40
|
Hi Brian, Re: New Atlas Mercurial repository Many, many thanks for adding a Mercurial (hg) repo... I never quite got with CVS commands, but hg seems much closer to git, which I use all the time... so opens a way for me to participate again... some learning... but looks good... The first problem was choosing and setting up a `ssh` windows client... but got through that ;=)) Otherwise could only clone a RO copy... did that, and got it compiled, with MSVC10, and running, using a CMake configuration, and native build file generation... against both earlier SG (circa 3.5), and current next SG (2016.3.0)... The next problem I had is that hg does not write the source files in native CRLF format of windows, and needed a few steps to get that working... after quite a bit of reading... Summary: Mercurial Distributed SCM (version 3.8.4) - Windows 10 - 64-bit 1: Mercurial.ini - [as admin/sudo] $ hg config --global Set: [extensions] eol = 2: %USERPROFILE%\.hgrc (Windows) or $HOME/.hgrc (Mac/Linux) Add/Set: [eol] native = CRLF # def is LF for *nix only-consistent = False 3: In the repo, add if not existing: .hgeol [patterns] ** = native 4: OPTIONAL: If no public .hgeol in repo, then add it, and add to .hgignore, THEN $ hg co -C null # clear all the current files $ hg co tip # get them all back, hopefully with native eol So I am now in a position to do a Windows port, as in the past... if there is any interest... Before I do that will try a trivial file change, push, and check that all is well... But, the question is do you want to add a public .hgeol to the repo? Then other windows users, that clone it, will get files already in Windows format... if they have already done steps 1: and 2:... and saves them knowing, and doing steps 3: and 4: This should not change anything for the unix and mac clones... I understand that the repo is already in LF format... Anyway, thanks for moving Atlas onward... your addition of building the maps, on the fly, worked great with my terrasync scenery... had a few hundred `map` in minutes... And was flying... ;=)) Regards, Geoff. |
From: Brian S. <bsc...@us...> - 2015-04-30 05:02:50
|
>>>>> "CR" == Charles Ricketts writes: CR> Is this list even maintained anymore? It is. CR> I ran across a problem when the SVN downloaded some of the polar CR> maps. It caused a memory corruption. I looked through the code CR> and made this change: [...] Some problems have appeared with the new "Scenery 2.0" scenery. I don't use it, because it takes up way too much disk space and processor power, so I've only tested a few sample tiles. Can you tell me which tile is crashes on? You just need to print its name in TileMapper::render() (or wherever it crashes): printf("Rendering '%s'\n", _tile->name()); CR> Now, I have issues with polar rendering, which isn't wholly CR> unexpected. For example, this is Antarctica: CR> http://208.68.38.147/screens/2015-04-25_215815.png. Also, a CR> close-up of McMurdo Station CR> (http://208.68.38.147/screens/2015-04-26_050239.png). Weird CR> isn't it? Or maybe it's normal? Either way, that's nothing CR> like what the area around McMurdo station looks like. I'm CR> having difficulty determining exactly what is going on here. If CR> anybody could point me in the right direction, I would greatly CR> appreciate it! It looks weird for me too (although not exactly the same as yours, but presumably that's because you use Scenery 2.0). I also get problems in northerly latitudes (eg, N60.5, W141). I don't know if that has improved under Scenery 2.0. The poles cause all sorts of problems, for 2 main reasons: (1) Much of the scenery data came from a Space Shuttle mission. However, the shuttle doesn't go as far north or south as the poles, so the data fizzled out at some northerly/southerly latitude (I can't remember the number, but around 60 degrees). So the polar data came from somewhere else, and is not very good (at least in my experience). (2) Programming assumptions that work at lower latitudes won't work at the poles, and it would not surprise me if the TerraGear code is buggy when generating polar terrain. I should add that even if the terrain was correct, FlightGear itself shows (or showed - I haven't checked recently) bizarre behaviour at the poles. When I flew over the south pole once, the entire sky rotated 180 degrees as I passed. CR> I've also been updating the __scenery array as I pull new maps CR> from the SVN, I'll have that patch available shortly I believe CR> (getting rid of the Atlas "unrecognized chunk/map" errors). I presume that __scenery has to be changed because of the switch to Scenery 2.0? In that case, we have to take into account which version of the scenery the user is using (a lot of people are avoiding 2.0 because of the impact it has on performance). And what if someone is using a combination of the 2? This will require some thought. CR> I'd also like to do something about load times if possible. CR> With the whole map rendered, Atlas can take somewhere around 30 CR> minutes to start for me. I assume this is because my HDD has to CR> crank hard to dig through my filesystem structures in order for CR> Atlas to know if both a terrain chunk and rendered map are CR> available or what combination of those so it can color the tiles CR> properly initially. With a 5400 RPM HDD, this can take a very CR> long time. Just to be clear, you're saying it takes 30 minutes to start even though all the maps have been rendered? This seems a bit extreme, although I've never run Atlas with a full scenery dataset. When you start up, are you just looking at the area around KSFO (the default)? CR> I also noticed that if I removed folders within Terrain, I CR> suddenly no longer had maps for those areas (of course, they CR> still exist on my drive, but Atlas refused to load them because CR> I didn't have the matching Terrain). This didn't make any sense CR> to me since Atlas really has no way of knowing whether the maps CR> it has available are up to date or not. I wrote it assuming that if you had a map, then you must have had the scenery to generate it with. And presumably you would want to keep the scenery so that you could use it in FlightGear. However, it wouldn't be too difficult to load maps regardless of whether the corresponding scenery existed. CR> On the thought of Atlas knowing which tiles are up-to-date, CR> there should also probably be a way for Atlas to determine that. I've thought of comparing the map file date to the scenery file date, but I haven't checked to see how SVN assigns dates to files. If it's the date the file was downloaded to disk, that would work. If it's the date the file was updated on SVN, then it wouldn't (at least completely reliably). Another alternative would be the scenery file size, which would presumably change if it was updated, but again that wouldn't be completely reliable. Anyway, let me first know about the problematic polar tile(s), and then we can proceed from there. Brian -- Sent from my AIM-65 |
From: Charles R. <chu...@gm...> - 2015-04-28 20:18:39
|
Is this list even maintained anymore? Atlas hasn't been updated for ages.... I'm new to FlightGear. Well, that's not entirely true, I picked it up at some point in about 2006 but I'm back! I've been scouring the wiki and I came across Atlas. I love the program (more so than the browser map, IMO)! I also started downloading the TerraGear SVN as well to put on DVD's. I ran across a problem when the SVN downloaded some of the polar maps. It caused a memory corruption. I looked through the code and made this change: --- a/src/TileMapper.cxx 2015-04-26 04:25:16.992835776 -0500 +++ b/src/TileMapper.cxx 2015-04-26 04:16:32.344821726 -0500 @@ -176,7 +176,10 @@ // course). It's a bit scary, and it would be nice to have a // reliable way to determine buffer size limits. if (_width > _height) { - _width = _height; + _width = _height; + } + if( _height > _width ){ + _height = _width; } // Create the main framebuffer object and bind it to our context. I'm not sure how older maps were done, but it seems that newer maps are longer than they are wide at the poles now (I'm not entirely certain of that, I don't know yet how to read the map data), so this fix actually allowed the program to start and avoided the memory freeing of unallocated memory. The original memory problem happened in TileMapper.cxx at the delete[] here: GLubyte *image = new GLubyte[width * height * 3]; assert(image); glGetTexImage(GL_TEXTURE_2D, shrinkage, GL_RGB, GL_UNSIGNED_BYTE, image); // Save to a file. We save it in _atlas/size/_name.<type> (if // that makes any sense). SGPath file = _tile->mapsDir(); char str[3]; snprintf(str, 3, "%d", level); file.append(str); file.append(_tile->name()); if (_imageType == PNG) { file.concat(".png"); savePNG(file.c_str(), image, width, height, _maximumElevation); } else if (_imageType == JPEG) { file.concat(".jpg"); saveJPEG(file.c_str(), _JPEGQuality, image, width, height, _maximumElevation); } delete[] image; OpenGL showed no errors when I explicitly checked its error code, but obviously 'new GLubyte[width * height * 3]' wasn't doing what it was supposed to, which is why I'm sure the original "hack" was put into place. Now, I have issues with polar rendering, which isn't wholly unexpected. For example, this is Antarctica: http://208.68.38.147/screens/2015-04-25_215815.png. Also, a close-up of McMurdo Station (http://208.68.38.147/screens/2015-04-26_050239.png). Weird isn't it? Or maybe it's normal? Either way, that's nothing like what the area around McMurdo station looks like. I'm having difficulty determining exactly what is going on here. If anybody could point me in the right direction, I would greatly appreciate it! I've also been updating the __scenery array as I pull new maps from the SVN, I'll have that patch available shortly I believe (getting rid of the Atlas "unrecognized chunk/map" errors). I'd also like to do something about load times if possible. With the whole map rendered, Atlas can take somewhere around 30 minutes to start for me. I assume this is because my HDD has to crank hard to dig through my filesystem structures in order for Atlas to know if both a terrain chunk and rendered map are available or what combination of those so it can color the tiles properly initially. With a 5400 RPM HDD, this can take a very long time. I also noticed that if I removed folders within Terrain, I suddenly no longer had maps for those areas (of course, they still exist on my drive, but Atlas refused to load them because I didn't have the matching Terrain). This didn't make any sense to me since Atlas really has no way of knowing whether the maps it has available are up to date or not. In all honesty, if they're available they should be use. It may be useful to, say, distribute Atlas map packs so that others can use them or look at them via Atlas without already having the scenery -- just a thought. I mean, I surely don't want to keep 99G worth of Terrain on my drive just so I can see all my Atlas maps if I don't need the terrain presently. (In fact, I plan on backing up my Terrain and Atlas map files to DVD's on a continental basis so I can avoid this). On the thought of Atlas knowing which tiles are up-to-date, there should also probably be a way for Atlas to determine that. So, if an SVN update was pushed the maps that need to be refreshed will be. I was thinking perhaps hashing the files used to render the map and placing that hash in the JPEG/PNG comments, but then I realized that SimGear is used so those files don't have to be directly accessed. It would also have the disadvantage of having to read up to 100G from the disk drive just to do this check. Though, there must be some unique value that can be obtained via SimGear that can be used for this purpose... Chuck Ricketts |
From: Brian S. <bsc...@us...> - 2014-02-09 05:23:32
|
>>>>> "Brian" == Brian Schack writes: >>>>> "Florian" == Florian Franzmann writes: Florian> Hi, I'm getting the following error when trying to use Florian> atlas (cvs version) with flightgear 3.0.0-rc1: Florian> Loading airports from Florian> /usr/share/games/flightgear/Airports/apt.dat.gz Florian> AirportsOverlay::load: Florian> "/usr/share/games/flightgear/Airports/apt.dat.gz": unknown Florian> version 1000 Florian> I'm guessing that flightgear finally switched to X-Planes Florian> current format for apt.dat and atlas's parser will have to Florian> be rewritten? Brian> You guess correctly. I'll start work on it shortly (although Brian> if you hear nothing in a week or two, you might want to Brian> gently remind me :-)). And just to let you know, I haven't forgotten. However, my computer gave up the ghost last week, and my (used) replacement is decidedly flaky, crashing daily. So the update will take a bit more time. Brian -- Sent from my AIM-65 |
From: Brian S. <bsc...@us...> - 2014-02-02 17:58:14
|
>>>>> "Florian" == Florian Franzmann writes: Florian> Hi, I'm getting the following error when trying to use Florian> atlas (cvs version) with flightgear 3.0.0-rc1: Florian> Loading airports from Florian> /usr/share/games/flightgear/Airports/apt.dat.gz Florian> AirportsOverlay::load: Florian> "/usr/share/games/flightgear/Airports/apt.dat.gz": unknown Florian> version 1000 Florian> I'm guessing that flightgear finally switched to X-Planes Florian> current format for apt.dat and atlas's parser will have to Florian> be rewritten? You guess correctly. I'll start work on it shortly (although if you hear nothing in a week or two, you might want to gently remind me :-)). Brian -- Sent from my AIM-65 |
From: Florian F. <sif...@ha...> - 2014-02-02 11:39:46
|
Hi, I'm getting the following error when trying to use atlas (cvs version) with flightgear 3.0.0-rc1: Loading airports from /usr/share/games/flightgear/Airports/apt.dat.gz AirportsOverlay::load: "/usr/share/games/flightgear/Airports/apt.dat.gz": unknown version 1000 I'm guessing that flightgear finally switched to X-Planes current format for apt.dat and atlas's parser will have to be rewritten? best regards Florian Franzmann -- |
From: Brian S. <bsc...@us...> - 2013-12-03 05:13:35
|
>>>>> "Frederik" == Frederik Tilmann writes: Frederik> Can I ask whether Atlas is still under active Frederik> development. The 2.0 version of the scenery causes a crash Frederik> in Atlas / Map, because appararently the format of the . Frederik> There has been some discussion on this on the Flightgear Frederik> Forum Frederik> http://forum.flightgear.org/viewtopic.php?f=31&t=21304&p=195295 Frederik> but nobody really came forward with a solution for Atlas I read that post (and got a note from another user), and in an amazing coincidence, I just checked in some changes that should solve the problem. Let me know how they work for you. I'll also post to that thread to let people know about the changes. Brian -- Sent from my AIM-65 |
From: Frederik T. <fti...@ze...> - 2013-12-02 20:44:34
|
Can I ask whether Atlas is still under active development. The 2.0 version of the scenery causes a crash in Atlas / Map, because appararently the format of the . There has been some discussion on this on the Flightgear Forum http://forum.flightgear.org/viewtopic.php?f=31&t=21304&p=195295 but nobody really came forward with a solution for Atlas Cheers Frederik -- |
From: Pat <pat...@gm...> - 2013-09-01 15:40:34
|
Geoff, I'd been using cvs -z3 \ -d:pserver:ano...@at...:/cvsroot/atlas co \ Atlas in our download_and_compile.sh script. Is this still the right url? are your changes from last November in this archive? -Pat Callahan On Tue, 13 Nov 2012 17:36:46 +0100 Geoff McLane <ub...@ge...> wrote: > Hi all, > > Inviting all testers of a cmake build of > Atlas in all ports... it requires SG 2.9. > > Ok, I got my CMake working in both Windows > and Ubuntu linux, and hope it will also > work in the MAC ;=)) > > Attached is atlas-10-02.zip containing > the modified Atlas source and a build > folder. > > If the attachment fails, due to too large > for the list, or something, it is also > available at - > > http://geoffair.org/tmp/atlas-10-02.zip > > Choose a place to unzip it, and it should > create two(2) directories - > > .../Atlas-10 - the source, with a CMakeLists.txt > file, my windows changes, a nearly now > empty old msvc folder, a CMakeModules directory > with specialize cmake 'find' scripts for > SimGear, PLIB and GLEW, etc... most from FG... > > and > > .../build-atlas - an out-of-source build folder > with (hopefully) a helpful build-atlas.sh > script. ./build-atlas.sh -? will show you > its options... > > Also the source contains a new README.cmake.txt > with some information on using cmake, and > the Atlas dependencies... > > Of course it always depend where you have > SimGear, PLIB, etc installed as to what to > do... but using the build-atlas.sh this > would be - > > build-atlas $ ./build-atlas.sh \ > SGDIR=/path/to/2.9/sg/install \ > PLIBDIR=/path/to/plib/install > > The PLIB is only if you do NOT have PLIB > already 'system' installed... > > When you give these paths, a sg_path (and > plib_path) files will be created, thus you > only need to add these once. > > The build-atlas has a TODO.txt file with > some notes on things still to be done... > quite a LONG list at this time ;=(( > > Of course, at this stage this will ONLY > build against SimGear 2.9 static (git/next), > but as expressed this will change... > > Why in a zip? > > Well if it was a git repository I would have > done this in a new branch, for testing, and > only when all working merge back to master... > > But I am a little unsure how to do this with > cvs, although I am sure there is a way ;=)) > > Anyway, any and all testers welcome. And any > patches... > > And especially any HELP clearing up things in > the TODO.txt list file... > > If you have problems, I may be able to help > better if you do - > > $ ./build-atlas.sh CMAKE VERBOSE >tmplog.txt 2>&1 > > and send, attach or put the tmplog.txt somewhere > I can read it... > > Have FUN! > > Regards. > Geoff. > > NOT attached: atlas-10-02.zip - as suspected got a > too big notice and canceled it ;=)) > > As advised it can also be found at - > http://geoffair.org/tmp/atlas-10-02.zip > > > > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, > vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Atlas-devel mailing list > Atl...@li... > https://lists.sourceforge.net/lists/listinfo/atlas-devel |
From: Pat <pat...@gm...> - 2012-11-27 03:16:14
|
:~/build/stable$ ./run_atlas.sh Loading navaids from /home/pac1/build/stable/install/atlas/bin/../../fgfs/fgdata/Navaids/nav.dat.gz ... done Loading fixes from /home/pac1/build/stable/install/atlas/bin/../../fgfs/fgdata/Navaids/fix.dat.gz ... done Loading airways from /home/pac1/build/stable/install/atlas/bin/../../fgfs/fgdata/Navaids/awy.dat.gz ... done Loading airports from /home/pac1/build/stable/install/atlas/bin/../../fgfs/fgdata/Airports/apt.dat.gz ... done Failed to read palette 'default.ap' Failed to read palette 'default' WARNING: fntLoadTXF: Failed to open '/home/pac1/build/stable/fgfs/install/fgfs/Atlas/Fonts/Helvetica.100.txf' for reading. Required font file '/home/pac1/build/stable/fgfs/install/fgfs/Atlas/Fonts/Helvetica.100.txf' not found. pac1@spinnaker:~/build/stable$ while this is addressed in this post, http://www.flightgear.org/forums/viewtopic.php?f=31&t=8983 would it be better to have the build just take care of whatever needs to be done for the fonts. Here's how I start atlas: #!/bin/sh cd $(dirname $0) cd install/atlas/bin export LD_LIBRARY_PATH=../../plib/lib:../../OpenSceneGraph/lib:../../simgear/lib ./Atlas --fg-root=$PWD/../../fgfs/fgdata $@ Any additional suggestions on how to handle this? -pat |
From: Pat <pat...@gm...> - 2012-11-16 11:37:32
|
Illuminating post. Thanks Thorsten. So where does that leave us: Are there two things to consider? 1. then new cmake for Atlas not behaving in the standard way in the case of simgear. 2. other flightgear libraries such as plib do not have the lib/i386-linux-gnu pattern, at least when I build them with download_and_compile.sh on Ubuntu I'm seeing the following:after building: install/plib/lib/libplibfnt.a install/OpenSceneGraph/lib/libOpenThreads.so install/OpenSceneGraph/lib/osgPlugins-3.0.1 Excep for Simgear, does download_and_compile.sh only work for the single architecture you happen to be building on? From a partial reading* of https://wiki.ubuntu.com/MultiarchSpec the issue would arise in two places, cross platform builds and multi platform package management by distributions. My understanding is that a given package may comply with ubuntu's methods, or not. So more questions to consider: Is the ubuntu method an accepted standard yet, or if not, is it on the way to being one? Is Simgear compliant with the ubuntu methods Is OSG and PLIB * I'll be reading the whole thing later today. Right now I have to go to work... -Pat On Fri, 16 Nov 2012 08:47:55 +0100 ThorstenB <br...@gm...> wrote: > On 16.11.2012 01:52, Pat wrote: > >> But none of this explains why SG static > >> libraries got installed in lib/i386-linux-gnu > >> in the first place. > > It's the default for distros like Debian/Ubuntu. The idea is to allow > libraries for different architectures to be present in the same > system at the same time - so you can cross-compile for other > architectures, but never mix up libraries. Hence, the architecture > name is added to library directory names. See spec for Ubuntu: > https://wiki.ubuntu.com/MultiarchSpec > > The great thing is: you normally don't need to worry about these. The > system and CMake does it all for you. When it's necessary to encode > such paths into the CMake file manually, then something has already > gone wrong before. Also, when you add such paths to CMake manually, > it'll stop working for anyone who really has libraries for multiple > architectures installed - like for i386-linux-gnu, x86_64-linux-gnu > and maybe arm-linux-gnu - a manual CMake hack likely picks the wrong > path... > > cheers, > Thorsten > |
From: ThorstenB <br...@gm...> - 2012-11-16 07:47:58
|
On 16.11.2012 01:52, Pat wrote: >> But none of this explains why SG static >> libraries got installed in lib/i386-linux-gnu >> in the first place. It's the default for distros like Debian/Ubuntu. The idea is to allow libraries for different architectures to be present in the same system at the same time - so you can cross-compile for other architectures, but never mix up libraries. Hence, the architecture name is added to library directory names. See spec for Ubuntu: https://wiki.ubuntu.com/MultiarchSpec The great thing is: you normally don't need to worry about these. The system and CMake does it all for you. When it's necessary to encode such paths into the CMake file manually, then something has already gone wrong before. Also, when you add such paths to CMake manually, it'll stop working for anyone who really has libraries for multiple architectures installed - like for i386-linux-gnu, x86_64-linux-gnu and maybe arm-linux-gnu - a manual CMake hack likely picks the wrong path... cheers, Thorsten |
From: Pat <pat...@gm...> - 2012-11-16 00:52:30
|
> > Re: shared versus static > > Not sure what your concern is about this, > but OSG normally defaults to using shared > libraries, and SG and PLIB default to using > static. That is it! No big deal. Not an atlas question. Just noticed it after reading that static libraries can outperform shared libs. Is that even true? > > Yes, with effort it is possible to change > this default, but WHY get into this? Let's > build with the DEFAULT settings FIRST ;=)) > Go Defaults! > But none of this explains why SG static > libraries got installed in lib/i386-linux-gnu > in the first place. > Thats one for Francesco and the Flightgear devel list. -P |
From: Pat <pat...@gm...> - 2012-11-16 00:48:42
|
not yet. ended with:Building CXX object CMakeFiles/Atlas.dir/src/AirportsOverlay.cxx.o In file included from /home/pac1/build/Atlas/Atlas-10/src/AirportsOverlay.cxx:45:0: /home/pac1/build/Atlas/Atlas-10/src/AtlasWindow.hxx:35:24: fatal error: plib/puAux.h: No such file or directory compilation terminated. make[2]: *** [CMakeFiles/Atlas.dir/src/AirportsOverlay.cxx.o] Error 1 make[1]: *** [CMakeFiles/Atlas.dir/all] Error 2 make: *** [all] Error 2 full log follows pac1@spinnaker:~/build/Atlas/build-atlas$ ./build-atlas2.sh SIMGEAR_DIR=/home/pac1/build/master/install/simgear/ PLIBDIR=/home/pac1/build/master/install/plib build-atlas2.sh: version 1.0.1 2012-11-14 build-atlas2.sh: Loaded sg_path, giving SIMGEAR_DIR=/home/pac1/build/master/install/simgear/ build-atlas2.sh: Loaded plib_path, giving PLIBDIR=/home/pac1/build/master/install/plib build-atlas2.sh: Setting SG directory path from [SIMGEAR_DIR=/home/pac1/build/master/install/simgear/] build-atlas2.sh: Found [/home/pac1/build/master/install/simgear/]. Will use this path build-atlas2.sh: Setting PLIB directory path from [PLIBDIR=/home/pac1/build/master/install/plib] build-atlas2.sh: Found [/home/pac1/build/master/install/simgear/]. Will use this path build-atlas2.sh: Written 'PLIBDIR=/home/pac1/build/master/install/plib' to plib_path, so will not be needed next time build-atlas2.sh: Doing 'export SIMGEAR_DIR=/home/pac1/build/master/install/simgear/' build-atlas2.sh: Doing 'export PLIBDIR=/home/pac1/build/master/install/plib' build-atlas2.sh: Found 'CMakeCache.txt' - Skipping CMake build-atlas2.sh: Run CLEAN, add CMAKE, or remove to redo CMake configuration and generation build-atlas2.sh: ERROR: CMake did NOT generate a 'Makefile'! pac1@spinnaker:~/build/Atlas/build-atlas$ ./build-atlas2.sh SIMGEAR_DIR=/home/pac1/build/master/install/simgear/ PLIBDIR=/home/pac1/build/master/install/plib build-atlas2.sh: version 1.0.1 2012-11-14 build-atlas2.sh: Loaded sg_path, giving SIMGEAR_DIR=/home/pac1/build/master/install/simgear/ build-atlas2.sh: Loaded plib_path, giving PLIBDIR=/home/pac1/build/master/install/plib build-atlas2.sh: Setting SG directory path from [SIMGEAR_DIR=/home/pac1/build/master/install/simgear/] build-atlas2.sh: Found [/home/pac1/build/master/install/simgear/]. Will use this path build-atlas2.sh: Setting PLIB directory path from [PLIBDIR=/home/pac1/build/master/install/plib] build-atlas2.sh: Found [/home/pac1/build/master/install/simgear/]. Will use this path build-atlas2.sh: Written 'PLIBDIR=/home/pac1/build/master/install/plib' to plib_path, so will not be needed next time build-atlas2.sh: Doing 'export SIMGEAR_DIR=/home/pac1/build/master/install/simgear/' build-atlas2.sh: Doing 'export PLIBDIR=/home/pac1/build/master/install/plib' build-atlas2.sh: Doing 'cmake ../Atlas-10 ' -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found ZLIB: /usr/lib/i386-linux-gnu/libz.so (found version "1.2.7") -- Found JPEG: /usr/lib/i386-linux-gnu/libjpeg.so -- Found PNG: /usr/lib/i386-linux-gnu/libpng.so (found version "1.2.49") -- /home/pac1/build/master/install/plib/include -- adding runtime JS dependencies -- Found PLIB: optimized;/home/pac1/build/master/install/plib/lib/libplibfnt.a;debug;/home/pac1/build/master/install/plib/lib/libplibfnt.a;optimized;/home/pac1/build/master/install/plib/lib/libplibjs.a;debug;/home/pac1/build/master/install/plib/lib/libplibjs.a;optimized;/home/pac1/build/master/install/plib/lib/libplibnet.a;debug;/home/pac1/build/master/install/plib/lib/libplibnet.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpsl.a;debug;/home/pac1/build/master/install/plib/lib/libplibpsl.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpuaux.a;debug;/home/pac1/build/master/install/plib/lib/libplibpuaux.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpw.a;debug;/home/pac1/build/master/install/plib/lib/libplibpw.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsg.a;debug;/home/pac1/build/master/install/plib/lib/libplibsg.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsl.a;debug;/home/pac1/build/master/install/plib/lib/libplibsl.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsm.a;debug;/home/pac1/build/master/install/plib/lib/libplibsm.a;optimized;/home/pac1/build/master/install/plib/lib/libplibssg.a;debug;/home/pac1/build/master/install/plib/lib/libplibssg.a;optimized;/home/pac1/build/master/install/plib/lib/libplibssgaux.a;debug;/home/pac1/build/master/install/plib/lib/libplibssgaux.a;optimized;/home/pac1/build/master/install/plib/lib/libplibul.a;debug;/home/pac1/build/master/install/plib/lib/libplibul.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpu.a;debug;/home/pac1/build/master/install/plib/lib/libplibpu.a -- SimGear include directory: /home/pac1/build/master/install/simgear/include -- found SimGear version: 2.9.0 (needed 2.9.0) -- Looking for include file pthread.h -- Looking for include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found. -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- looking for static SimGear libraries -- Simgear SIMGEAR_CORE_LIBRARY_RELEASE /home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a -- Simgear SIMGEAR_CORE_LIBRARY_DEBUG /home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a -- Simgear SIMGEAR_SCENE_LIBRARY_RELEASE /home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearScene.a -- Simgear SIMGEAR_SCENE_LIBRARY_DEBUG /home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearScene.a -- Looking for clock_gettime in rt -- Looking for clock_gettime in rt - found -- found SimGear libraries -- Performing Test SIMGEAR_COMPILE_TEST -- Performing Test SIMGEAR_COMPILE_TEST - Success -- Found SimGear: optimized;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearScene.a;debug;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearScene.a;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a;optimized;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a;debug;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a (Required is at least version "2.9.0") -- *** LIB: ZLIB ZLIB_LIBRARIES=/usr/lib/i386-linux-gnu/libz.so -- *** LIB: PNG PNG_LIBRARIES=/usr/lib/i386-linux-gnu/libpng.so;/usr/lib/i386-linux-gnu/libz.so -- *** LIB: JPEG JPEG_LIBRARIES=/usr/lib/i386-linux-gnu/libjpeg.so -- *** LIB: PLIB PLIB_LIBRARIES=optimized;/home/pac1/build/master/install/plib/lib/libplibfnt.a;debug;/home/pac1/build/master/install/plib/lib/libplibfnt.a;optimized;/home/pac1/build/master/install/plib/lib/libplibjs.a;debug;/home/pac1/build/master/install/plib/lib/libplibjs.a;optimized;/home/pac1/build/master/install/plib/lib/libplibnet.a;debug;/home/pac1/build/master/install/plib/lib/libplibnet.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpsl.a;debug;/home/pac1/build/master/install/plib/lib/libplibpsl.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpuaux.a;debug;/home/pac1/build/master/install/plib/lib/libplibpuaux.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpw.a;debug;/home/pac1/build/master/install/plib/lib/libplibpw.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsg.a;debug;/home/pac1/build/master/install/plib/lib/libplibsg.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsl.a;debug;/home/pac1/build/master/install/plib/lib/libplibsl.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsm.a;debug;/home/pac1/build/master/install/plib/lib/libplibsm.a;optimized;/home/pac1/build/master/install/plib/lib/libplibssg.a;debug;/home/pac1/build/master/install/plib/lib/libplibssg.a;optimized;/home/pac1/build/master/install/plib/lib/libplibssgaux.a;debug;/home/pac1/build/master/install/plib/lib/libplibssgaux.a;optimized;/home/pac1/build/master/install/plib/lib/libplibul.a;debug;/home/pac1/build/master/install/plib/lib/libplibul.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpu.a;debug;/home/pac1/build/master/install/plib/lib/libplibpu.a -- *** LIB: SG SIMGEAR_CORE_LIBRARIES=/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a;optimized;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a;debug;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- Found X11: /usr/lib/i386-linux-gnu/libX11.so -- Found OpenGL: /usr/lib/i386-linux-gnu/libGL.so -- Found GLEW: /usr/lib/i386-linux-gnu/libGLEW.so -- Found GLUT: /usr/lib/i386-linux-gnu/libglut.so -- *** LIB: GL OPENGL_LIBRARIES=/usr/lib/i386-linux-gnu/libGLU.so;/usr/lib/i386-linux-gnu/libGL.so;/usr/lib/i386-linux-gnu/libSM.so;/usr/lib/i386-linux-gnu/libICE.so;/usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so -- *** LIB: GLEW GLEW_LIBRARIES=/usr/lib/i386-linux-gnu/libGLEW.so -- *** LIB: GLUT GLUT_LIBRARIES=/usr/lib/i386-linux-gnu/libglut.so;/usr/lib/i386-linux-gnu/libXmu.so;/usr/lib/i386-linux-gnu/libXi.so -- *** Building static library STATIC -- *** add_executable( Map src/Map.cxx;src/Bucket.cxx;src/Image.cxx;src/misc.cxx;src/Palette.cxx;src/Subbucket.cxx;src/TileMapper.cxx;src/Tiles.cxx src/Bucket.hxx;src/Image.hxx;src/misc.hxx;src/Palette.hxx;src/Subbucket.hxx;src/TileMapper.hxx;src/Tiles.hxx ) -- *** target_link_libraries( Map /usr/lib/i386-linux-gnu/libz.so;/usr/lib/i386-linux-gnu/libpng.so;/usr/lib/i386-linux-gnu/libz.so;/usr/lib/i386-linux-gnu/libjpeg.so;optimized;/home/pac1/build/master/install/plib/lib/libplibfnt.a;debug;/home/pac1/build/master/install/plib/lib/libplibfnt.a;optimized;/home/pac1/build/master/install/plib/lib/libplibjs.a;debug;/home/pac1/build/master/install/plib/lib/libplibjs.a;optimized;/home/pac1/build/master/install/plib/lib/libplibnet.a;debug;/home/pac1/build/master/install/plib/lib/libplibnet.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpsl.a;debug;/home/pac1/build/master/install/plib/lib/libplibpsl.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpuaux.a;debug;/home/pac1/build/master/install/plib/lib/libplibpuaux.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpw.a;debug;/home/pac1/build/master/install/plib/lib/libplibpw.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsg.a;debug;/home/pac1/build/master/install/plib/lib/libplibsg.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsl.a;debug;/home/pac1/build/master/install/plib/lib/libplibsl.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsm.a;debug;/home/pac1/build/master/install/plib/lib/libplibsm.a;optimized;/home/pac1/build/master/install/plib/lib/libplibssg.a;debug;/home/pac1/build/master/install/plib/lib/libplibssg.a;optimized;/home/pac1/build/master/install/plib/lib/libplibssgaux.a;debug;/home/pac1/build/master/install/plib/lib/libplibssgaux.a;optimized;/home/pac1/build/master/install/plib/lib/libplibul.a;debug;/home/pac1/build/master/install/plib/lib/libplibul.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpu.a;debug;/home/pac1/build/master/install/plib/lib/libplibpu.a;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a;optimized;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a;debug;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a;/usr/lib/i386-linux-gnu/libGLU.so;/usr/lib/i386-linux-gnu/libGL.so;/usr/lib/i386-linux-gnu/libSM.so;/usr/lib/i386-linux-gnu/libICE.so;/usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so;/usr/lib/i386-linux-gnu/libGLEW.so;/usr/lib/i386-linux-gnu/libglut.so;/usr/lib/i386-linux-gnu/libXmu.so;/usr/lib/i386-linux-gnu/libXi.so ) -- *** add_executable( Atlas src/AirportsOverlay.cxx;src/AirwaysOverlay.cxx;src/Atlas.cxx;src/AtlasBaseWindow.cxx;src/AtlasController.cxx;src/AtlasWindow.cxx;src/Background.cxx;src/Cache.cxx;src/CrosshairsOverlay.cxx;src/Culler.cxx;src/FixesOverlay.cxx;src/FlightTrack.cxx;src/FlightTracksOverlay.cxx;src/GLUTWindow.cxx;src/Geographics.cxx;src/Globals.cxx;src/Graphs.cxx;src/LayoutManager.cxx;src/NavData.cxx;src/NavaidsOverlay.cxx;src/Notifications.cxx;src/Overlays.cxx;src/Preferences.cxx;src/RangeRingsOverlay.cxx;src/Scenery.cxx;src/Search.cxx;src/Searcher.cxx;src/Bucket.cxx;src/Image.cxx;src/misc.cxx;src/Palette.cxx;src/Subbucket.cxx;src/TileMapper.cxx;src/Tiles.cxx src/AirportsOverlay.hxx;src/AirwaysOverlay.hxx;src/AtlasBaseWindow.hxx;src/AtlasController.hxx;src/AtlasWindow.hxx;src/Background.hxx;src/Cache.hxx;src/CrosshairsOverlay.hxx;src/Culler.hxx;src/FixesOverlay.hxx;src/FlightTrack.hxx;src/FlightTracksOverlay.hxx;src/GLUTWindow.hxx;src/Geographics.hxx;src/Globals.hxx;src/Graphs.hxx;src/LayoutManager.hxx;src/NavData.hxx;src/NavaidsOverlay.hxx;src/Notifications.hxx;src/Overlays.hxx;src/Preferences.hxx;src/RangeRingsOverlay.hxx;src/Scenery.hxx;src/Search.hxx;src/Searcher.hxx;src/Bucket.hxx;src/Image.hxx;src/misc.hxx;src/Palette.hxx;src/Subbucket.hxx;src/TileMapper.hxx;src/Tiles.hxx ) -- *** target_link_libraries( Atlas /usr/lib/i386-linux-gnu/libz.so;/usr/lib/i386-linux-gnu/libpng.so;/usr/lib/i386-linux-gnu/libz.so;/usr/lib/i386-linux-gnu/libjpeg.so;optimized;/home/pac1/build/master/install/plib/lib/libplibfnt.a;debug;/home/pac1/build/master/install/plib/lib/libplibfnt.a;optimized;/home/pac1/build/master/install/plib/lib/libplibjs.a;debug;/home/pac1/build/master/install/plib/lib/libplibjs.a;optimized;/home/pac1/build/master/install/plib/lib/libplibnet.a;debug;/home/pac1/build/master/install/plib/lib/libplibnet.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpsl.a;debug;/home/pac1/build/master/install/plib/lib/libplibpsl.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpuaux.a;debug;/home/pac1/build/master/install/plib/lib/libplibpuaux.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpw.a;debug;/home/pac1/build/master/install/plib/lib/libplibpw.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsg.a;debug;/home/pac1/build/master/install/plib/lib/libplibsg.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsl.a;debug;/home/pac1/build/master/install/plib/lib/libplibsl.a;optimized;/home/pac1/build/master/install/plib/lib/libplibsm.a;debug;/home/pac1/build/master/install/plib/lib/libplibsm.a;optimized;/home/pac1/build/master/install/plib/lib/libplibssg.a;debug;/home/pac1/build/master/install/plib/lib/libplibssg.a;optimized;/home/pac1/build/master/install/plib/lib/libplibssgaux.a;debug;/home/pac1/build/master/install/plib/lib/libplibssgaux.a;optimized;/home/pac1/build/master/install/plib/lib/libplibul.a;debug;/home/pac1/build/master/install/plib/lib/libplibul.a;optimized;/home/pac1/build/master/install/plib/lib/libplibpu.a;debug;/home/pac1/build/master/install/plib/lib/libplibpu.a;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a;optimized;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a;debug;/home/pac1/build/master/install/simgear/lib/i386-linux-gnu/libSimGearCore.a;/usr/lib/i386-linux-gnu/libGLU.so;/usr/lib/i386-linux-gnu/libGL.so;/usr/lib/i386-linux-gnu/libSM.so;/usr/lib/i386-linux-gnu/libICE.so;/usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so;/usr/lib/i386-linux-gnu/libGLEW.so;/usr/lib/i386-linux-gnu/libglut.so;/usr/lib/i386-linux-gnu/libXmu.so;/usr/lib/i386-linux-gnu/libXi.so ) -- *** GetMap excluded from build. Use -DADD_GETMAP=ON to enable -- Configuring done -- Generating done -- Build files have been written to: /home/pac1/build/Atlas/build-atlas build-atlas2.sh: Doing 'make ' Scanning dependencies of target Atlas [ 2%] Building CXX object CMakeFiles/Atlas.dir/src/AirportsOverlay.cxx.o In file included from /home/pac1/build/Atlas/Atlas-10/src/AirportsOverlay.cxx:45:0: /home/pac1/build/Atlas/Atlas-10/src/AtlasWindow.hxx:35:24: fatal error: plib/puAux.h: No such file or directory compilation terminated. make[2]: *** [CMakeFiles/Atlas.dir/src/AirportsOverlay.cxx.o] Error 1 make[1]: *** [CMakeFiles/Atlas.dir/all] Error 2 make: *** [all] Error 2 build-atlas2.sh: Appears 'make ' FAILED! pac1@spinnaker:~/build/Atlas/build-atlas$ ./build-atlas2.sh SIMGEAR_DIR=/home/pac1/build/master/install/simgear/ PLIBDIR=/home/pac1/build/master/install/plib^C pac1@spinnaker:~/build/Atlas/build-atlas$ locate puAux.h /home/pac1/build/master/install/plib/include/plib/puAux.h /home/pac1/build/master/plib/src/puAux/puAux.h |
From: Geoff M. <ub...@ge...> - 2012-11-15 11:22:47
|
Hi Pat, Ok, it looks good ;=)) Just two (simple), but different things to try. Just one or the other... 1) Add to Atlas-10/CMakeModules/FindSimGear.cmake Amend lines 39 and 48 from - PATH_SUFFIXES ${CMAKE_INSTALL_LIBDIR} lib libs64 \ libs libs/Win32 libs/Win64 to PATH_SUFFIXES ${CMAKE_INSTALL_LIBDIR} lib libs64 \ libs libs/Win32 libs/Win64 lib/i386-linux-gnu Of course in the file these should be a continuous lines, not 'broken' like in this email... You will note this tells cmake to 'also' look in /home/pac1/build/master/ \ install/simgear/lib/i386-linux-gnu Then run this again - > ./build-atlas $ ./build-atlas.sh \ > CMAKE VERBOSE \ > SGDIR=/home/pac1/build/master/install/simgear \ > PLIBDIR=/home/pac1/build/master/install/plib \ > > tmplog.txt 2>&1 And all should be well... 2) Copy the two SG libraries from i386-linux-gnu That is put a copy of libSimGearCore.a and libSimGearScene.a into - /home/pac1/build/master/install/simgear/lib And run the above again, and all should be well... Re: shared versus static Not sure what your concern is about this, but OSG normally defaults to using shared libraries, and SG and PLIB default to using static. That is it! Yes, with effort it is possible to change this default, but WHY get into this? Let's build with the DEFAULT settings FIRST ;=)) But none of this explains why SG static libraries got installed in lib/i386-linux-gnu in the first place. And when the script was building flightgear HOW was cmake able to 'find' the link to SG! You will note FindSimGear.cmake in Atlas-10 is almost an EXACT copy of flightgear/CMakeModules/FindSimGear.cmake Anyway, those BIG puzzles aside, either 1) amend FindSimGear.cmake, or 2) copy the SG libraries should get you to the NEXT steps in building Atlas and Map ;=)) Good luck! Regards, Geoff. |
From: Pat <pat...@gm...> - 2012-11-15 00:22:47
|
>Plan of investigation: >Check how osg cmake handles the need for simgear OSG requires neither simgear or plib so how does Simgear's and flightgear cmake handle osg and plib? 1. find_package(OpenSceneGraph 3.0.0 REQUIRED osgText osgSim osgDB osgParticle osgGA osgUtil) 2. CmakeLists.txt for Simgear does not refer to plib but flightgear does: find_package(PLIB REQUIRED puaux pu js fnt) >Check on osg cmake's options for output. (not related to issues with >building atlas.) # Dynamic vs Static Linking OPTION(DYNAMIC_OPENSCENEGRAPH "Set to ON to build OpenSceneGraph for dynamic linking. Use OFF for static." ON) IF (DYNAMIC_OPENSCENEGRAPH) SET(OPENSCENEGRAPH_USER_DEFINED_DYNAMIC_OR_STATIC "SHARED") ELSE () SET(OPENSCENEGRAPH_USER_DEFINED_DYNAMIC_OR_STATIC "STATIC") ENDIF() The script does not override this. Something to try. -Pat |
From: Pat <pat...@gm...> - 2012-11-15 00:02:42
|
On Wed, 14 Nov 2012 11:28:12 +0100 Geoff McLane <ub...@ge...> wrote: > ./build-atlas $ ./build-atlas.sh \ > CMAKE VERBOSE \ > SGDIR=/home/pac1/build/master/install/simgear \ > PLIBDIR=/home/pac1/build/master/install/plib \ > > tmplog.txt 2>&1 Results attached. Note that OSG, PLIB and flightgear do not do the i386-linux-gnu bit. for example: build/master/install/OpenScenGraph/lib contains bin, include and lib lib contains the osg .so files. So why arent the osg libs static? Plib/lib contains .a files Two Questions to look into Why can't cmake find the simgear libs Why does OSG build .so instead of .a Plan of attack: Check how osg cmake handles the need for simgear Check on osg cmake's options for output. -Pat |