|
--- In "charliem_1216" <> wrote: > No, this is wrong. Note that the failure is when compiling a script > on the *host*, using the *host* gcc. It means only that your > Ubuntu-supplied gcc/glibc/headers were tripped up by the bug, and that > the (probably older) host gcc/glibc/headers used at TS was not. > > Even in reading the text of Sam's patch you linked to, it implies that > it failed only on some host systems, notably OS X, at the time > (May-07). As other distros updated gcc/glibc/headers, I'm sure the > bug hit them too in time, like Ubuntu. OK, I can accept that. Technologic didn't mention that their package only worked with certain distros, just that it required an x86 linux, which I provided. When I reported the error, I was only told that *I* did something wrong and, eventually, that they were no longer going to support me unless I convinced the president of their company to do so. The least that could have done was to tell me what linux platform they are using, then I could get that and use it, too. Especially if, as it seems, the patch I found explained that there could be a distro problem. I never expected anything to compile locally in a cross-compile build as it sounds like a logical contradiction, but on second thought, I guess the thing might actually need to build local tools to produce the kernel. > > When I reporting the bug, the fix and asked my contact at Technologic > > about this, he told me that I probably needed to run make menuconfig to > > change a setting (but he didn't say which one that might be) so that the > > broken file is not included. If that is true, then it concerns me even > > more than the bug, because I wanted to start with exactly the same > > settings as Technol o gic so that the kernel we built as just like theirs > > except for the things we specifically wanted to change. > > > > Perhaps these things don't bother the linux gurus among Technologic's > > customers, but they concern me. > > I think there is no conspiracy here ... Probably TS was trying to > offer some help, without saying "I don't know why it fails for you, it > works for me". Again, I wasn't thinking 'conspiracy' as much help pointing in the wrong direction, which is often worse than no help at all. The problem was with my choice of an x86 linux distro, nothing else, which the support guy probably would have noticed if he is as proficient with linux as you sound, and bothered to look. > PS - There are much better ways of increasing the timer resolution > than by increasing HZ. I believe high resolution timers are available > for the orion5 platform, but you w ould need a 2.6.28 kernel I think. I keep hearing about orion stuff, but I'm not finding much as far as documentation on the embeddedarm web site. Is it hidden somewhere on their ftp server? Are there special libraries or other packages that need to be installed? I'm more than willing to put a newer kernel on the thing, as long as I can be sure that we still have access to the necessary TS-7800 board functions (which I cannot list off the top of my head). And I don't want most services (like apache, mysql, mail, all that junk), mostly just ssh and maybe ftp. __._,_.___
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required) Change settings via email: =Email Delivery: Digest | m("yahoogroups.com?subject","ts-7000-fullfeatured");=Change Delivery Format: Fully Featured">Switch to Fully Featured Visit Your Group | Yahoo! Groups Terms of Use | =Unsubscribe __,_._,___ |