On Thu, 19 Mar 2009 17:36:46 +0100, Geoff wrote in message <1237480606.6461.3.ca...@dell02>:
> Hi Arnt, > > Please reduce the unnecessary 'size' of your emails. Sometimes > it takes many clicks to get to anything you MAY have added. > > Instead of adding _ALL_ that has been said, pick out a little > of the relevant context, if needed, like I do... ;=)) ..I'll try, this time too, I'm afraid I must file a motion to file an overlength reply. ;o) > ============ > > > IT WILL NOT 'SEE' PLIB UNLESS YOU PATCH configure.ac as > > > detailed... > > ..ok, add a patches tree and PATCH-ALL and PATCH-* stanzas > > to your make*g-1.0.6's? ;o) > > Simple answer is NO! ;=)) I am expecting the patch to get > into the git terragear-cs sometime SOON - at least I HOPE > so... otherwise the current configure.ac will ONLY > support simgear, osg, plib installed into a 'standard' > path ;=(( > > So, NO, my scripts handle enough things already > without this type of HOPEFULLY TEMPORARY 'patch' addition... ..my idea is use the patch tree primarily for "local event Live-DVD etc releases" stuff, such as moving the default start-up from rwy...@ksfo in C172 C-FGFS to e.g. rw...@enzv in the sled behind Rudolf, and emergencies such as the TG configure.ac, and to test patches, not as a permanent fix to TG or FG. ..gnu patch also offers to remove or reverse "already applied patches", which is handy when patches get into the git etc trees, and to help debug your own git etc trees. ;o) > And concerning DOUPD, this should ONLY be used AFTER > the initial downloads and builds are done, when you > really MEAN that you want a FULL update of everything. ..this is no different from a fresh blank start with ./make*g and will produce exactly the same T|FG binaries as a "repeat" "./make*g DOUPD"? > That is _AFTER_ a full successful build, and some time has > passed. The scripts will always do the initial > download/checkout/clone WITHOUT it... ..ok. > In fact, they are meant to be run repeatedly WITHOUT any > parameters added. I do not even consider NOPAUSE a 'safe' ..no, but us messing around with it, will make it safer and a safe starting point for a release generator cron job. ;o) > option!!! You SHOULD always at least inspect the ./configure > step results, and abort if something is MISSING... ..yup, first step is make sure your make*g works for both Ubuntu and Debian, then flog some Fedora etc victims thru the same needle eye without trashing what we have working. > And ADDDEBUG will write the ./configure output to the LOG file, > for even more careful inspection... ..ah thanks, I got the idea this was meant to add debug stuff to the binary builds. ;o) > ============= > > > /opt/bygg/fg/simgear/source/simgear/timing/timestamp.cxx:79: > > > undefined reference to `clock_gettime' > > ..still happening with your makefg-1.0.5. > > Not when I run it ;=() ..??? Another dash|bash thing??? You use dash or bash right there as /bin/sh??? (On building FG in that part of makefg?) > I have NO IDEA why you get this error building fgfs. > Mine builds ok. You did not give enough output to know > exactly what was happening, but when linking fgfs, which > includes -lsgtiming, it also includes -lrt, which I think > is the library that contains this function. ..so we need my ./makefg ADDDEBUG logs. In my next FU here. > ~$ ls -l /lib/librt* > -rw-r--r-- 1 root root 35784 2008-09-12 16:15 /lib/librt-2.7.so > but not sure. ..I have: a45:~# ls -l /lib/librt* -rw-r--r-- 1 root root 30624 Feb 28 00:15 /lib/librt-2.9.so lrwxrwxrwx 1 root root 12 Mar 2 01:21 /lib/librt.so.1 -> librt-2.9.so a45:~# > Is there a command to sort of 'dump' a > library to know what it exports? That is dump an ascii export > list, not a 'hex' dump, like xxd? ..if not hexdump, od, ldd, libtool, unstr or pkg-config, search ideas? I'm pretty sure you don't want typelib-dump nor bn_dump, and I fairly sure about rawshark too: a...@a45:~ $ man -k lib |grep dump bn_dump (3ssl) - BIGNUM library internal functions typelib-dump (1) - show ORBit2 type library modules a...@a45:~ $ man -k dump |grep lib bn_dump (3ssl) - BIGNUM library internal functions rawshark (1) - Dump and analyze raw libpcap data typelib-dump (1) - show ORBit2 type library modules a...@a45:~ $ man typelib-dump a...@a45:~ $ ..freeze (1) - dump a process into a self-executing file? Or gmxdump (1) - makes binary files human readable? _Amazing_ pile of er, non-junkĀ on my test box. :o) > But anyway, this does not show anything wrong with my makefg > script that I can see... ..so we'll see what my ./makefg ADDDEBUG logs says. > ============= > > > lines, since I found that sometimes using one > > > LONG line of 'apt-get update a b c...' seemed to > > > MISS some packages in the list!!! Not sure why? > > ..could be related to whining about sudo apt-get install > > without (or before) chking whether those are necessary, > > try $basename --version style chks or dpkg -l |grep what > > ever your scripts needs. > > Again NO, it is NOT! In all my tests, it just seems to > 'miss' some things in a long list of things, and never > 'complains' about repeated invocations. ..tried with bash as your shell, too? I don't see such misses here (ssh and bash sessions in bash in konsole in KDE on Debian Squeeze/Sid). ..sometimes, we will also have conflict bugs, (which I do see in bash ;o)) with say manual page files moving from a tool to its document package, which will throw an apt conflict error, at other times we'll have dependency loop bugs or missed dependencies, which should stop make*g. > I do not always > use NOPAUSE, and often READ the last outputs before > continuing... the reason the 'waits' were put there > in the first place! ..ok, I found NOPAUSE a neat quick test, but let's focus now on getting your makefg script working for _both_ Ubuntu and Debian, first, and only then go chase TG and FG _build_ bugs, and _those_ bug chases should happen in their _own_ git etc trees, not in your make*g scripts. > Yes, something like dpkg -l | grep would also do it, but > that is even MORE scripting. Thus in a way, sudo apt-get > install 'item' _IS_ a simple check that the 'item' exists... ..yeah, but _that_ simple chk requires root rights, for _no_ good reason, and therefore becomes an _unnecessary_ security risk. ..keep in mind, Joe SixPack is a newbie we want as developer. He should be told "Root must install gcc fakeroot" etc and be stopped to do a sudo, _only_ when that is necessary. ..and it isn't, (only maybe on the first run until e.g. our makefg_1.0.11a.all.deb,) we have fakeroot and alien etc in the Debian tool set, and that tool set can do cross compiles for all architectures. > ============= > > ..ln -s /bin/sh /bin/dash is standard Ubuntu practice? > ~$ ls -l /bin/sh > lrwxrwxrwx 1 root root 4 2008-08-16 17:27 /bin/sh -> dash > Do not know if it is 'standard', but it is certainly done > on my system. ..ok. > ============ > >From the list of TG executables, it seems you got these > built. PHEW!!! Of course you are 'free' to install them where > ever you like ;=)) just like you have done, amending > INSTALL_DIR_TG=<whatever/you/want> ..aye, thanks :o), just my stupid luck ;o), I never understood how you use these INSTALL_DIR_TG etc variables to set your own $HOME/bin etc as your TG install target, on my first few tries, I killed quite a few ;o) TG ./configure --prefix=/opt/bygg/tg/install//opt/bygg/tg/install/terragear-cs > Now comes the 'hard' part, and that is building scenery > using these tools... HAVE FUN ;=)) .._after_ we have makefg working and I understand how you use these INSTALL_DIR_TG etc variables. ;o) ..now, first a quick aptitude update etc run, then a guinea pig run to make new ./makefg DOUPD ADDDEBUG NOPAUSE logs. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel

