64 replies to this topic

[Hitnrun]

Sounds like the binds didn't fully work.. this is why I'm trying to figure out a better way of doing it.
Best way is to check "mount" that everything goes on properly, and if "dmesg | less" says anything about things not binding correctly.

As for sshd not working while having the extend installed, that could be because some of the binds did take, and the sshd config files were being read from the extend, rather than the NAND. It should've been fine when you rebooted though, that's an odd one.
Try setting up sshd again, as it may just be the config files got mangled. I haven't used sshd on the Pandora, so I can't really help much more than that, I'm afraid.. sorry.

I'm not particularly happy with the dev extend stuff at the moment, as with the aufs binds, you'll essentially get my configuration files ( or at least, whatever configuration files I had at the time I generated the extend. )
A better idea would be to setup a root overlay and install the dev tools into there, so then it's at least unique to your Pandora, and has any of your configuration files on it.

I am however, really quite knackered with things just now, so not sure when I'll have time to take another look at what I was up to with the cross-compiler idea, I'm afraid.

After a second reboot it started working again, don't know what the problem was.

I too think that a cross-compiler-like approach should be better, so everything can be on the SD card. Can't we just setup a compiler like we do today on linux, but the "cross compiler" be the same platform as the current one?

I think something like the DJwillis toolchain would be great, doing an "opkg-target install" would install on the cross-compiler path on the SD, so as not to interfere with the OS on nand.

To use gcc as a cross-compiler is it necessary to build it like that, or is it possible to "convert" a standard gcc into a cross compiler?

[urjaman]

My Oh My...

Just build a normal native toolchain (binutils,gcc,make and whatever else you need) on the pandora with --prefix=/mnt/utmp/devpnd (or whatever you name that last part). Then add a script to the PND that sets path to include the correct folders and spawn a terminal.
There might be some problems, and I dont know where this gcc would look for includes etc, but I think it should be possible.

This wont shield you against installing stuff on NAND (of course), but for building your personal projects etc it should be fine.

Spoiler

My personal project will someday be to wrap avr-gcc (and folks), avrdude and scite into a pnd for avr programming, but enough of that.

[Stuckie]

My Oh My...

Just build a normal native toolchain (binutils,gcc,make and whatever else you need) on the pandora with --prefix=/mnt/utmp/devpnd (or whatever you name that last part). Then add a script to the PND that sets path to include the correct folders and spawn a terminal.
There might be some problems, and I dont know where this gcc would look for includes etc, but I think it should be possible.

This wont shield you against installing stuff on NAND (of course), but for building your personal projects etc it should be fine.

Spoiler

My personal project will someday be to wrap avr-gcc (and folks), avrdude and scite into a pnd for avr programming, but enough of that.

That's essentially what I was doing, just using crosstool-ng to set everything up as I was lazy

However, the two issues I found where:
1) It still seems to look for libc_nonshared.a outside it's own area.
2) The linker went bananas and wouldn't do it's job properly.. it would link, but you needed to be very explicit about what to link.

Still need to have another look at it, but won't be till next week at the earliest.. feel free to try though, as that's near enough what I was doing anyway.

[Hitnrun]

Does someone knows what differences a cross-compiler gcc has in relation to paths to a "native" one? The root path must be defined on compilation only, and can't be changed afterwards?

Can't I just take angstrom's compiler and install in /mnt/pnd/arm-pandora, maybe rename the executables with this prefix, and use it like I would with a cross-compiler? (I know that probably not, just wanted to know why).

[Stuckie]

I didn't try that.. I keep forgetting opkg has an "install to" option.
Try it and see

But generally, yea, the issue is hard coded paths embedded in the executables - hence the libc_nonshared.a issue.
I might have another go at getting it working tonight, but I'm still rather burnt out from this month's work, I'm afraid, so I wouldn't count on it.