Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Some program that were compile for the DNS-323 are segfaulting or are not even executable on the DNS-313. This is maybe caused by the fact that the DNS-323 is a ARMv5TEJ environment (ARM926EJ-S) and the DNS-313 is a ARMv4T environment (ARM920T). I want to recompile the fun_plug packages on my NAS in the hope this will solve these problems. I have seen some post of people starting from scratch to compile the codes, but also I have see that these topic seem to vanish in thin air. My plan is not to start from scratch, but use the present fun_plug packages to make a environment so I can compile the packages on the NAS.
The layout of the plan is as follows.
- Extent the sda4 partition to 4GB (done by gparted in 12 hours.)
- Putting the headers of the sl3516 designed kernel in the right place.
- Retrieve the fonz fun_plug build scripts with svn
- Compile uClibc on the NAS
- Reinstall uClibc on the NAS
- Continue this way with the rest of the packages, until everything is recompiled.
I only need some help in the sequence that the packages need to be compiled and reinstalled.
So will this approach work or am I missing something?
And could someone provide me with a list that gives the sequence for compilation?
Remark: Why did they gave us the impression that the DATA_BASE partition is the last partition by making it the sda4 partition. It is the third partition of four: sda1(swap),sda3(SYSTEM),sda4(DATA_BASE),sda2(D-Link_DNS-313). The last partition is the biggest partition, so to extent the sda4 partition to 4GB gparted had to move 460GB to generate the aditional space. If sda4 would have been the last partition gparted would have been finish in minutes.
Offline
The one that i know of are not from the fonz fun_plug packages, but as I have enough space I can install all the packages and check them, now.
nzbget 0.6 from the nzbget site compile for DNS-323.(not executable)
bt_torrent in the DNS-313 firmware compile against uClibc.(not executable)
ipkg for installing optware packages.(not executable)
ethtool compile on the dns-313 with ffp.(segfault after output is presented)
Offline
the problem with these packages is most likely not that different processor, but the different firmware libraries. all of my packages are carefully made to use only ffp libraries and no firmware libs. many contributed packages, however, rely on firmware libraries (so does all of optware) and wont work on other devices. so all you need to recompile is packages that have dependencies outside of /ffp.
you can check a program with readelf and ldd. e.g.
# readelf -d /ffp/bin/bash | grep RPATH 0x0000000f (RPATH) Library rpath: [/ffp/lib]
If there's no RPATH entry or it's not /ffp/lib, it's "wrong".
Similarly, ldd will show all paths in /ffp/lib, and none in /lib or /usr/lib or somewhere else.
# ldd /ffp/bin/bash
libreadline.so.5.2 => /ffp/lib/libreadline.so.5.2 (0x4000e000)
libhistory.so.5.2 => /ffp/lib/libhistory.so.5.2 (0x40047000)
libncurses.so.5 => /ffp/lib/libncurses.so.5 (0x40055000)
libdl.so.0 => /ffp/lib/libdl.so.0 (0x4009e000)
libc.so.0 => /ffp/lib/libc.so.0 (0x400a9000)
ld-uClibc.so.0 => /ffp/lib/ld-uClibc.so.0 (0x40000000)Offline
Could one add the RPATH entry to the elf info of an executable?
What is method you use to force a program to only use the 'ffp' libraries. So my compile programs will work correctly with ffp.
Offline
I'm not aware of any program that adds an RPATH to a binary.
To add the RPATH I'm passing "-rpath /ffp/lib" to the linker (actually, I'm passing -Wl,-rpath,/ffp/lib to gcc, usually by setting LDFLAGS). Most of that is done automatically in the scripts in my subversion repository.
Offline
Hi,
I put command # ldd /ffp/bin/bash and I have:
ldd: can't open cache '/ffp/etc/ld.so.cache'
libreadline.so.5.2 => /ffp/lib/libreadline.so.5.2 (0x4000e000)
libhistory.so.5.2 => /ffp/lib/libhistory.so.5.2 (0x40047000)
libncurses.so.5 => /ffp/lib/libncurses.so.5 (0x40055000)
libdl.so.0 => /ffp/lib/libdl.so.0 (0x4009e000)
libc.so.0 => /ffp/lib/libc.so.0 (0x400a9000)
ld-uClibc.so.0 => /ffp/lib/ld-uClibc.so.0 (0x40000000)
What does it mind?
Offline
So your are saying that there is not need for the ffp packages to be recompiled on a DNS-313, as the programs don't take advantage of the additional extension which are in the ARMv5TEJ Architecture. I was think that maybe the modification of the kernel would have had effect on the execution of the programs like how to allocate memory, but I am not an expert on that.
I'll keep you posted if I find a ffp package that is not working on the DNS-313.
Offline
Ok, now I know... ldconfig generates entries in /ffp/etc/ld.so.cache
Offline