I'm enthusiastic about the rPi which has Debian wheezy as its default OS. But both programs that I tried to install/port: dvtm, wily; failed.
I don't want to have to look into C and especially not C+, but IIRC they failed because of missing libraries.
Apparently X86 *nix will have a mass of libraries, which program authors, can just hook into, but ARM versions often won't be available. So even with the C sources the program is not installable under ARM. So the popularity curse rules again.
On Wednesday, April 17th, 2013, at 21:12:21h +0000, Baas Chris Glur explained:
It is great to hear that you have still got the greatest enthusiasm and confidence in the mission, but we all know that you have made some very poor decisions recently.
How did you try to install them?
Why not? Are you allergice to C and C++ code?
If you cannot remember what you had for breakfast, what confidence can the reader have that your are correctly remember the reason for the failure?
No, not apparently: it does and that is a fact.
Why not? For user level programs, if the source code is available, then the library can be compiled for the ARM processor.
Your logic is impeccably flawed as usual.
Because the herds of wart hogs and wildebeests have migrated to Facebook and Twitter.
No, it is not right.
Before you can compile a program which requires external libraries, you must install the related header files which are provided in the development package related to the library.
When you ran the configure script for the software program, prior to compilation, it will have indicated which libraries/header files were missing.
But you know all this already because of your superior intelligence and knowledge.
Please do tell all why you need wily,
"A work-alike of the Acme programming environment for Plan 9"
on a rPi? The world is listening in eager anticipation.
First off, did you see if those programs have already been ported?
If so, pull them in with the apt package manager, which will also pull in their dependencies. Otherwise, make a list of the missing libraries and try installing them with apt. Any that aren't available will need to be downloaded, compiled and installed, but that's no more difficult than compiling those programs: in fact the 'make' recipe for most libraries will do all the work - just read the README and do what it says to configure, compile and install the libraries. Then try compiling the programs again. If there are still missing libraries rince, wash and repeat. It can be a little tedious but its not difficult.
Most libraries compile and install without any difficulty. I can't remember one that hasn't on the various Linux systems where I've done this.
Same applies to the RPi: when I installed microEmacs, my favourite text editor, I found that libtermcap wasn't available for RPi's Debian Wheezy, so I downloaded it from the Free Software Foundation as a source tarball. That unpacked, compiled and installed without a problem. At that point I imported /etc/termcap from my Fedora development box and compiled microEmacs again. This time there were no problems and it ran first time.
That depends entirely on what you're trying to port to the RPi and what its dependencies are. In my case libtermcap is very old and is mostly supplanted by libterminfo, so I wasn't really surprised that I had to go and get it.
Other stuff with mainstream dependencies should port without problems, but the more the program you want differs from the stuff that has already been ported by the RPi devs, the greater your dependency problems will be.
There should be some way of asking the devs to add what what you just ported to the RPi Debian Wheezy distro and telling them what its dependencies are. I don't know how that should be done, but if its likely that others would find your port useful, you might want to get it included in the distro. HTH
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
The ARM architecture is RISC while x86 is CISC, so in the bes case you're gonna have to recompile/x-compile your C source or whatever code you wann run there. Same for the libraries.
Anyone who wishes can donate time to recompiling standard Linux sources for unusual architectures. Debian does better than most in this respect,
formatting link
but it's down to 'boots on the ground' as to how fast this proceeds.
There's probably a fair bit of work to do in this case, as ARM machine code is very orthogonal, and not particularly congruent with that of CISC machines such as X86, so quite a bit will need to be re-written to optimise for the architecture. I did some ARM assembler work twenty-something years ago, and it was much more reminiscent of the DG Nova than of the (then) modern processors. It's almost writing in microcode.
If you're [also] a Windows person, you will know that hardly any standard Windows software runs on RT. Windows has been x86 32/64 bit/Itanium for many years (I think NT 4.0 was the last Windows before RT to run on another architecture), so they've got out of the habit of writing for multiple architectures.
Third-party Windows authors have exactly the same problem of re-compiling for a fairly alien architecture. Most aren't even willing to port their software to other Windows versions, and few will be willing to chance their ARMs on something quite different.
Did you try to install the Debian packages from the archive? "apt-get install dvtm wily" should work.
Almost every Debian package is available for ARM (including libraries). It is a supported architecture. The autobuilders take care of it except when packages are restricted to certain achitectures (rare).
Not really. Gcc does an excellent job except for a few corner cases. Almost all packages build on Debian's autobuilders without difficulty. When there are problems it usually turns out to be a bug which simply failed to manifest on other architectures. Remember that Debian supports ten architectures and all packages are expected to build on all of them unless there is a good reason why not. FTBS (Failed To Build from Source) is a serious bug that cannot be fixed by merely deleting the troublesome architecture.
On Wednesday, April 17th, 2013, at 17:27:48h -0500, John Hasler asked:
OOPS, my search earlier only found them in stable, but that search was invalid, and lo and behold for Debian Bronchitis --
Package: dvtm (0.6-1) armel
Tiling window management for the console
Package: wily (0.13.41-7.2) armel
A work-alike of the Acme programming environment for Plan 9
So your suggestion is of course the sensible action to take, and because it is the sensible and easiest course of action to take to resolve the problem will be summarily dismissed as the wrong answer to the problem.
debian is a very large distro they have over 37000 packages for the raspberry pi. Both dvtm and wily are in debiian, you can just install the stock versions...
$ sudo aptitude install dvtm wily
No, if needed you can get sources for the libraries too and compile and install them, often the library is abailable, and even already installed, but to compile against it you need the matching headers which are found in the dev package.
for libc libc-dev, for libncurses libncurses-dev, etc...
How would I easily see that? I've had little experience with debian. Mainly because I don't like aptitude. Mainly because it assumes a permanently on-line connection, which I haven't got. I need to be in control, and not have systems that try to go on-line by themselves.
Yea OK, apt[itude] has faced up to the fact that package-management NEEDS heavy-artillery. My attitude is probably unrealistic, like people who won't use `mc` to make life easier.
OK, I just don't won't to be a pioneer. I'd prefer to walk behind others.
Well, that can be a big job.
Without knowledge of such subtle details one may need much effort.
That's exactly my problem. Once you've used ETHOberon, you don't want to go back to bobbing your head upNdown between kybrdNscreen; when you can fly-head-up.
Thanks, it will become easier as we accumulate contributed knowledge.
If you don't like Aptitude you'd better install another OS, or at least one of the non-Debian derived Linuxes. AFAIK Aptitude does not need a permanently online connection any more than yum, the RedHat package manager, does. I've never seen that behavior on my RPi, but then again I run mine headless and always via the command line.
RedHat's Fedora distro does have a graphical yum front end that scans by default but its trivially easy to stop it doing that and I'd assume the same applies to Aptitude. Like you, I don't like automatic updates, so if my RPi had tried that on I would have disabled it.
You may be using some GUI tool that's scanning for updated packages, which you can disable, or you may have a cron job installed that's doing it and that you can delete.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
It's not very difficult to run aptitude without going to the internet in real time. There are two packages that can make a local mirror or cache:
apt-mirror makes a complete mirror of a repository. Set up a simple webserver to serve your mirror locally and configure aptitude to use 'localhost' as its source. I have set up apt-mirror for speed and to solve the problem of hash-sum mismatches with Ubuntu DEBs.
apt-cache caches packages as you download them. It wouldn't be difficult to write a script that would take the name of one package you want, then do a 'fake' download of that package and all its dependencies. I did that for Tiny Core, and doing the same thing for DEBs wouldn't be difficult.
If you need your target system to be entirely isolated from the internet, set up another system with internet access to download the packages, then transfer the files between systems via sneakernet or whatever. If you want to transfer only the DEBs, there's a package that can build a repository and stuff DEBs into it. Unfortunately, that package's name slips my mind at the moment.
HTH
--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)
OK thanks, that looks promising. BTW I've been counting the 'get yourself a ding-dong' solutions: PLENTY.
The incremental method is effective for task solution: start from a known good position and incrementally move towards your target. gpm & mc are much more important for me than wily & dvtm, but since I had already installed the latter from source to X86, I'd use them to incrementally test installing more-complex-programs to rPi.
But this is starting to look like a canOworms:----
[64]armel 4,120.2 kB 8,952.0 kB [[65]list of files]
---------- I need to sleep on that, before I buy.
The whole idea of moving towards a rPi is to escape the US infinite frontier mentality, where the solution to every problem is 'use a BIGGER hammer'.
Apparently aptitude is designed to handle the complexity of the dependancies. But it assumes an on-line connection, which I lack. The big-bang approach [vs. incremental, where the user has control] only works for a uniform herd of users. ========= Recently I tore my guts out to install the current `festival` TextToSpeech system. And several posters wrote "what's yo problem, I installed it easy" Only after I discovered that they had all installed an earlier version, did I install that too. Now the mail-list has admitted a problem in the new version. I want to avoid any similar situation. While the herd were all following each other 'mortgaging their house for beer', they were very confident. Now they are all squealing. === Inet promotes a herd mentality. Viral-ideas could collapse the boat.
0000000 177 E L F 001 001 001 \0 \0 \0 \0 \0 \0 \0 \0 \0
I haven't got access to rPi right now, but dvtm: a small program; was chosen to test if/how problematic it is to extend/customise rPi. We don't want to fall into a M$ type trap? So dvtm's exec is only 32KB size; but it's dependant libc6 is a
4MB monster; but libc6 is used for 'everything'. So it must be installed ALREADY. So perhaps I should test compile 'hello world' first. But I don't want to know about C/C+ because it's such crap, compared to ETHOberon. Being popular doesn't mean its good. Else M$ would be the best. == Linux has to piggyback on M$ [for the PC BIOS] and ETHOberon can profitably piggyback on Linux for the large application base. == If a mere 32KB program is problematic, then it's not realistic to hope to easily 'extend'/modify rPi's program suite.
On Friday, April 19th, 2013, at 08:29:12h +0000, Chris Glur explained:
You must surely be aware that the song "Ding Dong the Witch is dead" has been played lots of times over the last week or so?
Of course, it is always best to start with something that works and then gradually change things rather than changing everything at once and then having to work through all the possibilities where something has gone wrong.
It is quite straightforward to do this, but you must install the appropriate development packages in order to have the necessary header files.
But are they in tomato sauce with a subtle basil flavoring?
If you do not buy the bush meat when the poacher is in the dorp and selling, you might go hungry for a couple of days.
As opposed to the
"South African veldt, which is said to give a greater feeling of infinity than the ocean even.?
You are out of touch: the current fashion is everything is smaller, even watching movies on 2 inch screens.
No it does not. And if you do not like aptitude (neither do I in fact), then use dselect instead.
Warthogs and wildebeests do not wear uniforms.
Was the local medicine man able to put them back?
As do we all.
Are you implying they should drink South African wine instead?
The full quote is "Don't force it, use a bigger hammer." That's actually good advice, and appears in the workshop manuals for one of the classic british motorbikes. So, probably not correct to blame the Americans for it, and it's actually good advice, anyway.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.