[open for testing] Tomato ARM optware feed


alllexx

alllexx

Networkin' Nut
Member
Tomato ARM optware feed built with the exact toolchain used by Shibby (as well as by Asus, to my knowledge) to build fw's for ARM routers now open for testing:
http://alllexx.no-ip.biz/optware/shibby-tomato-arm/

I have upgraded and fixed numerous packages, added some. What matters most, is that this feed is 'native' for Shibby's tomato arm fw, and is EABI (unlike mbwe-bluering OABI), so performs much better.

The sources can be found here:
https://github.com/alllexx88/optware/

Please note that it's hosted on my NAS, so don't expect perfect availability and great bandwidth. At least not until someone volunteers to host the feed for me :)

Here's how you bootstrap the feed:
Code: 
feed=http://alllexx.no-ip.biz/optware/shibby-tomato-arm
cd /tmp
ipk_name=$(wget -qO- $feed/Packages | awk '/^Filename: ipkg-opt/ {print $2}')
wget $feed/$ipk_name
tar -xOvzf $ipk_name ./data.tar.gz | tar -C / -xzvf -
echo "src/gz alllexx $feed" > /opt/etc/ipkg.conf
echo "dest /opt/ /" >> /opt/etc/ipkg.conf

There're some known issues and some workarounds, but I have to go now, will write on this later in the second post.

Well, please test and report :)

Regards,
Alex

UPD: the most simple way to solve the libresolv issue mentioned in the second post is to add 'LD_LIBRARY_PATH=/opt/lib:${LD_LIBRARY_PATH}' line to /jffs/etc/profile. E.g., make sure jffs partition is mounted and run:
Code: 
ipkg update
ipkg install uclibc-opt
mkdir -p /jffs/etc
echo 'LD_LIBRARY_PATH=/opt/lib:${LD_LIBRARY_PATH}' >> /jffs/etc/profile
 
Last edited:
The two main issues I wanted to mention were:
- can't load library 'libresolv.so.0'
- possible segmentation fault at boot

I encountered the latter problem when trying to use apache2 (see here). I found out in the end that the culprit here is libdb, and that you have to explicitly link executables with libpthread whenever you link them with the libdb build I use in the feed. So, if you encounter segmentation fault problem, this may be the cause of it. Let me know of the failed package, I'll see if linking with libpthread fixes it.

The former problem happens with packages that are linked with libresolv. libresolv is part of uclibc, and therefore binaries, that are linked with it, expect it to be available in a standard location (like /lib), having it in /opt (as a part of uclibc-opt package) won't suffice. This can be easily fixed by Shibby with just adding libresolv to /lib, but for now there're some workarounds:
Install uclibc-opt package and

1. Run the failed package with LD_LIBRARY_PATH=/opt/lib. If you don't want to do it manually each time there's a little trick to have it done automatically (on the example of php):
Code: 
ipkg update
ipkg install uclibc-opt
cd /opt/bin
mv -f php php.bin
echo '#!/bin/sh' > php
echo 'LD_LIBRARY_PATH=/opt/lib /opt/bin/php.bin "$@"'  >> php
chmod +x php

OR

2. Use a 'mount -o bind' trick to have libresolv available in /lib:
Code: 
ipkg update
ipkg install uclibc-opt
mkdir -p /tmp/lib
cp -rf /lib/* /tmp/lib/
cp -f /opt/lib/libresolv* /tmp/lib/
mount -o bind /tmp/lib /lib
To have it done automatically after reboot:
a) Add these lines to router's web admin -> Administration -> Scripts -> Init
Code: 
mkdir -p /tmp/lib
cp -rf /lib/* /tmp/lib/
mount -o bind /tmp/lib /lib
b) Now we need to run `mkdir -p /tmp/lib; cp -f /opt/lib/libresolv* /tmp/lib/` when /opt is mounted. If you have an external drive automounted as /opt (e.g., by having a line like "echo 'LABEL=optware /opt ext3 defaults 0 0' >> /etc/fstab" in Administration -> Scripts -> Init), then do the following:
Code: 
echo '#!/bin/sh' > /opt/libresolv.autorun
echo 'mkdir -p /tmp/lib' >>  /opt/libresolv.autorun
echo 'cp -f /opt/lib/libresolv* /tmp/lib/' >>  /opt/libresolv.autorun
chmod +x /opt/libresolv.autorun

If Shibby will be so kind as to add libresolv to his firmware, there will be no need for these workarounds :)
 
Last edited:
gawd0wns said:
Hello alllexx,

Can you confirm if the debian linux install (https://www.asuswrt.eu/how-to-install-debian-wheezy-arm/) works with this build of optware?

I can confirm it works with the optware version bundled with shibby's firmware: http://www.linksysinfo.org/index.php?threads/installing-debian-on-tomato-arm.70828/

Thanks,
Click to expand...

Hi,

As far as I can gather from the how-to, the only things you need from optware are nano and findutils. These packages work fine without any issues. However, if you plan to use Debian only, there isn't any significant difference between using the OABI mbwe-bluering feed or the "proper" EABI shibby-tomato-arm feed, imho
 
alllexx said:
I encountered the latter problem when trying to use apache2 (see here).
Click to expand...
Apache start script /opt/etc/init.d/S80apache includes/opt/sbin/httpd -k restart command, but there is no /opt/sbin/httpd. Is it right?

alllexx said:
If Shibby will be so kind as to add libresolv to his firmware, there will be no need for these workarounds :)
Click to expand...
You may patch uClibc to make new toolchain, which will be independent from firmware.
 
ryzhov_al said:
Apache start script /opt/etc/init.d/S80apache includes/opt/sbin/httpd -k restart command, but there is no /opt/sbin/httpd. Is it right?

You may patch uClibc to make new toolchain, which will be independent from firmware.
Click to expand...

httpd moved to {prefix}/bin/, starting from 2.4.x, I believe. I'll fix the init script a bit later, for now just edit it locally.
As for patching uclibc, thanks for the tip, I'll look into it
 
ryzhov_al said:
Apache start script /opt/etc/init.d/S80apache includes/opt/sbin/httpd -k restart command, but there is no /opt/sbin/httpd. Is it right?

You may patch uClibc to make new toolchain, which will be independent from firmware.
Click to expand...

alllexx said:
httpd moved to {prefix}/bin/, starting from 2.4.x, I believe. I'll fix the init script a bit later, for now just edit it locally.
Click to expand...

I take it back, httpd is indeed in /opt/sbin, and appears to work fine. Very odd you don't have it, try to re-install apache.

ryzhov_al said:
You may patch uClibc to make new toolchain, which will be independent from firmware.
Click to expand...

I patched uClibc, re-compiled entire feed, but it didn't help:
Code: 
root@unknown:/tmp/home/root# php -v
php: can't load library 'libresolv.so.0'
root@unknown:/tmp/home/root# ldd /opt/bin/php
root@unknown:/opt/arm-brcm-linux-uclibcgnueabi/lib# ldd /opt/bin/php
    libdl.so.0 => /opt/lib/libdl.so.0 (0x4012b000)
    libpthread.so.0 => /opt/lib/libpthread.so.0 (0x400d2000)
    libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x400ae000)
    libcrypt.so.0 => /opt/lib/libcrypt.so.0 (0x400ec000)
    libstdc++.so.6 => /opt/lib/libstdc++.so.6 (0x4014a000)
    libm.so.0 => /opt/lib/libm.so.0 (0x401f7000)
    libsasl2.so.2 => /opt/lib/libsasl2.so.2 (0x40210000)
    libxml2.so.2 => /opt/lib/libxml2.so.2 (0x4022f000)
    libz.so.1 => /opt/lib/libz.so.1 (0x40356000)
    libiconv.so.2 => /opt/lib/libiconv.so.2 (0x40373000)
    libc.so.0 => /opt/lib/libc.so.0 (0x40459000)
    libc.so.0 => /lib/libc.so.0 (0x404ce000)
    libm.so.0 => /lib/libm.so.0 (0x40542000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4055b000)
    libdl.so.0 => /lib/libdl.so.0 (0x4056d000)
    libresolv.so.0 => not found
    ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40039000)
root@unknown:/tmp/home/root# ls /opt/lib/libres*
/opt/lib/libresolv-0.9.32.1.so  /opt/lib/libresolv.so.0

EDIT: how odd, after installing bash package and re-logining, php works fine:
Code: 
[root@unknown root]$ /opt/bin/php -v
PHP 5.6.5 (cli) (built: Feb 25 2015 15:59:36)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
[root@unknown root]$ ldd /opt/bin/php
    libdl.so.0 => /opt/lib/libdl.so.0 (0x40134000)
    libpthread.so.0 => /opt/lib/libpthread.so.0 (0x400d0000)
    libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x4000e000)
    libcrypt.so.0 => /opt/lib/libcrypt.so.0 (0x4003b000)
    libstdc++.so.6 => /opt/lib/libstdc++.so.6 (0x4013f000)
    libm.so.0 => /opt/lib/libm.so.0 (0x401ec000)
    libsasl2.so.2 => /opt/lib/libsasl2.so.2 (0x400f6000)
    libxml2.so.2 => /opt/lib/libxml2.so.2 (0x40205000)
    libz.so.1 => /opt/lib/libz.so.1 (0x40115000)
    libiconv.so.2 => /opt/lib/libiconv.so.2 (0x4032c000)
    libc.so.0 => /opt/lib/libc.so.0 (0x40412000)
    libresolv.so.0 => /opt/lib/libresolv.so.0 (0x400c1000)
    ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x400aa000)

If I delete bash, the problem re-occurs, so it looks like there's smth wrong with fw's shell

EDIT2: ah, I get it, optware's bash simply sets LD_LIBRARY_PATH=/opt/lib:${LD_LIBRARY_PATH} in /opt/etc/profile, that's why php works fine with it
 
Last edited:
Please note that before re-compiling the entire feed I also upgraded gettext, and so in case you bootstraped the feed before this re-compilation, you need to re-install all packages that depend on gettext, or just re-install all packages with:
Code: 
ipkg update
ipkg -force-reinstall install `ipkg list_installed|cut -d ' ' -f 1`

Also, I'm quite sure that there're some other packages, apart from those I identified already, that need to be explicitly linked with libpthread, but I can't test all the feed myself, so any feedback is very-very welcomed! I'd very grateful if you could drop a line or two on any issues you encountered, or just say that this or that works fine.

Thanks in advance,
Alex

P.S. if there're any packages that you'd like to see in this feed, let me know: I might try to add them, especially if I deem them interesting/useful or if adding them is simple
 
There is a very simple workaround for the libresolv issue. First, format and mount jffs partition (in case you haven't done this earlier) and run:
Code: 
mkdir -p /jffs/etc
echo 'LD_LIBRARY_PATH=/opt/lib:${LD_LIBRARY_PATH}' >> /jffs/etc/profile

That's it. Now you won't have any libresolv issues as long as you have 'uclibc-opt' package installed and jffs partition mounted :)
 
Last edited:
You must log in or register to reply here.

Back
Top