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

Reply via email to