How difficult to port programs to ARM debian?

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.
Is that right?
== TIA.
Reply to
Unknown
Loading thread data ...
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.
Reply to
J G Miller
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 
 Click to see the full signature
Reply to
Martin Gregorie
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.
cheers
Reply to
Burkhard Ott
Yes.
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.
--
Joe
Reply to
Joe
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).
--
John Hasler
Reply to
John Hasler
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.
--
John Hasler
Reply to
John Hasler
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.
Reply to
J G Miller
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...
--
?? 100% natural
Reply to
Jasen Betts
yeah, NT ran on DEC Alpha, but isn't Win-RT (internally) closer to Win-CE than it is to win-8, and WinCE has been on ARM fo quite a while...
You can get mono for RPI - that'll run a lot of recent "windows software".
--
?? 100% natural
Reply to
Jasen Betts
formatting link
?
formatting link
?
Reply to
Rainer H. Rauschenberg
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.
Reply to
Unknown
Use Aptitude to query available packages.
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 
 Click to see the full signature
Reply to
Martin Gregorie
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 
 Click to see the full signature
Reply to
Robert Riches
Apologies for following-up to myself, but I remembered that reprepro is the name of the package that builds a repository and puts DEBs into it.
HTH
--
Robert Riches 
spamtrap42@jacob21819.net 
 Click to see the full signature
Reply to
Robert Riches
Or apt-cache, or synaptic, if you prefer.
Indeed, none of these tools require permanent connectivity.
--
http://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell
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:----
formatting link
dep: [46]libc6 (>= 2.4) [armel, armhf, powerpc, s390]
formatting link
[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.
Reply to
Unknown
formatting link
dep: [46]libc6 (>= 2.4) [armel, armhf, powerpc, s390]
formatting link
[64]armel 4,120.2 kB 8,952.0 kB ===== ls -l /usr/local/sbin/dvtm == -rwxr-xr-x 1 root root 31644 2012-06-29 13:44 /usr/local/sbin/dvtm hexdump -c /usr/local/sbin/dvtm == 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.
Reply to
Unknown
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?
Or they could create a Botnet for fun and profit.
Reply to
J G Miller
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.
Reply to
Raymond Wiker

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.