Joined: 03 Aug 2014 Posts: 41 Location: Kyiv, Ukraine
Posted: Mon Mar 30, 2015 14:57 Post subject: [ARMv7/MIPSEL]Optware-ng[gcc-5.2.0][uClibc-ng-1.0.6]
Introduction
This is an Optware fork project. Description and install instructions available on the project home page.
Numerous packages have been fixed, upgraded and added. Even some GUI X11 packages, such as thunar, transmission-gtk, deluge-gtk, rox-filer etc.:
(full size) (full size) (full size) (full size)
Compatibility
ARMv7:
Feed's binaries are designed to use libraries from /opt/... only, so as long as your architecture is ARM and the kernel supports EABI binary interface (unless you're running something insanely ancient, it does), it should work. What can cause problems though, is if LD_LIBRARY_PATH environment variable contains a path where a different uClibc build is installed: in this case you can have odd segfault issues. If an executable crashes with a segfault, try to unset LD_LIBRARY_PATH first.
MIPSEL:
Should work on any MIPSEL mips32r2 target, and all more or less recent ones are mips32r2. The LD_LIBRARY_PATH notice from the ARM section should be noted here too.
Despite all this, I don't test the feeds on DD-WRT routers, so any kind of feedback is appreciated.
Hosting has been kindly provided by zyxmon. Many thanks to him!
Launching X11 applications
To launch X11 applications, you first need to install 'xauth' package, the application you desire (e.g., 'thunar') and feed's dropbear that is patched to use '/opt/bin/xauth' when X11 forwarding is enabled:
then launch feed's dropbear (by default it runs on port 2222):
Code:
/opt/etc/init.d/S51dropbear
Then connect via ssh protocol to feed's dropbear (by default, port 2222) with X11 forwarding enabled. If you're using PuTTY, look here, if you're on unix with openssh client, just use the '-X' flag, e.g.:
And you should hopefully get something similar to the first screenshot
You may also need to use lxappearance (/opt/bin/ipkg-static install lxappearance) to set icon theme (e.g., with thunar). It works fine with PuTTY, yet there may be some odd issues with GTK+ themes if you're using linux openssh client (see here)
I applaud your work, and any work that enhances DD-WRT. I am curious though as to how your work differs from the Entware ARM effort. Several folks have success with it on DD-WRT routers.
Joined: 03 Aug 2014 Posts: 41 Location: Kyiv, Ukraine
Posted: Mon Mar 30, 2015 19:32 Post subject:
VTecheira wrote:
I applaud your work, and any work that enhances DD-WRT. I am curious though as to how your work differs from the Entware ARM effort. Several folks have success with it on DD-WRT routers.
First of all, thank you for your kind words
From the user's side, the're two main differences:
1) libc
2) available packages
I'll start with the latter. Obviously, since my feed forks from the original Optware, and Entware builds upon OpenWRT build system (and most Entware packages are OpenWRT packages, if I'm not mistaken), we have different packages available. Not to mention that I've fixed and upgraded numerous outdated and broken Optware packages, and also added some of my own. And, of course, I also ported GTK+ 3 and 2, and already have such GTK+ apps as transmission-gtk, deluge-gtk, thunar, rox-filer, ged, and some others, working, and plan to add more. As far as I know, Entware doesn't have any GUI X11 applications.
The former is probably even more important. Entware-arm uses glibc, while I use uClibc. glibc is better in terms of features, it is the libc that is used by nearly all Linux distros, however (look here) it is rather resource-hungry and isn't always a perfect fit for embedded systems. uClibc, on the other hand, targets to be an embedded library. The downside of uClibc is that programs often need additional patching to build and/or work properly with it. For instance, uClibc is missing proper locale, spawn support, etc.. By the way, original Entware mipsel project uses uClibc as well.
Thanks very much for doing this, it is excellent. One of the issues I had with Entware-ARM is there are lots of missing packages.
You seem to include the missing packages, which is great.
For example, I need miniupnpd which is not included with Entware and refuses to compile despite my best efforts.
You already include miniupnpd and I am also able to re-compile it with my preferred options without too much trouble.
A few notes. I could not get your bootstrap to work from post 1. The following line fails:
Code:
tar -xOvzf $ipk_name ./data.tar.gz | tar -C / -xzvf -
tar: invalid magic
tar: short read
I was able to fix it by splitting the lines:
Code:
tar -xvzf $ipk_name ./data.tar.gz
tar -C / -xzvf ./data.tar.gz
I also created a symbolic link for "opkg" because otherwise if you just use "ipkg" it calls the built-in version of ipkg and fails (at least for Kong builds). Obviously you could use the full path to fix that but I find "opkg" easier to remember and type.
.... One of the issues I had with Entware-ARM is there are lots of missing packages......
For example, I need miniupnpd which is not included with Entware and refuses to compile despite my best efforts.
Not all openwrt packages are compiled, only the main ones. It is not difficult to compile miniupnpd. If you still want to try entware version - contact my <my-nick>@gmail.com
I do not make miniupnpd available for public testing because (1) I am not sure it is functional, (2) a lot of junk packages were built, that are in dependences and are not needed.
As for uclibc - I do not think it will be difficult to rebuild entware.arm with uclibc. I do not have time to do it. Entware.arm is based on Qnapware (repository for NASes, that uses glibc). That is why glibc is used. _________________ My forum.
Joined: 03 Aug 2014 Posts: 41 Location: Kyiv, Ukraine
Posted: Sun Apr 05, 2015 11:54 Post subject:
MikeMcr wrote:
Thanks very much for doing this, it is excellent. One of the issues I had with Entware-ARM is there are lots of missing packages.
You seem to include the missing packages, which is great.
For example, I need miniupnpd which is not included with Entware and refuses to compile despite my best efforts.
You already include miniupnpd and I am also able to re-compile it with my preferred options without too much trouble.
I'm glad my work helped you, and thanks for the feedback! I remember I had some issues with building older Optware version of miniupnpd, so I resorted to upgrading it. Had to create my own config and make file in a similar way it was done for the older version. I haven't tested it, since I don't use it, so if there're some options that I should change, let me know
MikeMcr wrote:
A few notes. I could not get your bootstrap to work from post 1. The following line fails:
Code:
tar -xOvzf $ipk_name ./data.tar.gz | tar -C / -xzvf -
tar: invalid magic
tar: short read
I was able to fix it by splitting the lines:
Code:
tar -xvzf $ipk_name ./data.tar.gz
tar -C / -xzvf ./data.tar.gz
Looks like a dd-wrt tar bug: unpacking to stdout and/or reading from stdin is apparaently not working Thanks, your fix to the instructions applied!
MikeMcr wrote:
I also created a symbolic link for "opkg" because otherwise if you just use "ipkg" it calls the built-in version of ipkg and fails (at least for Kong builds). Obviously you could use the full path to fix that but I find "opkg" easier to remember and type.
Code:
ln -s /opt/bin/ipkg /opt/bin/opkg
You can just use 'ipkg-static' instead of doing this, since '/opt/bin/ipkg' is just a symbolic link to '/opt/bin/ipkg-static'
Not all openwrt packages are compiled, only the main ones. It is not difficult to compile miniupnpd. If you still want to try entware version - contact my <my-nick>@gmail.com
I really appreciate your efforts as well, thank you. For a long time DD-WRT didn't have any optware type options for ARM devices and then 2 come along almost at the same time! Having a choice benefits everyone
If I find time to try entware again I'll certainly be in touch, thank you. For now, I have a working solution and am happy.
I'm glad my work helped you, and thanks for the feedback! I remember I had some issues with building older Optware version of miniupnpd, so I resorted to upgrading it. Had to create my own config and make file in a similar way it was done for the older version. I haven't tested it, since I don't use it, so if there're some options that I should change, let me know
I think my compile options are just personal preferences. I already had my own conf file and other supporting scripts from when we could use the OpenWRT repositories (pre musl DD-WRT).
Not sure if I need PCP support but it was enabled for OpenWRT I think. The leasefile support enables miniupnpd to be stopped and started without losing all the leases (I use the conf file option to remove them after x hours of inactivity). The manufacturer info allows me to set device specific information in the conf file so I can see things like router name and model from client devices.
While I remember, I noticed some missing dependencies for some packages which prevented them from running. After manually installing the missing packages, they worked OK.
.... and then 2 come along almost at the same time!....
I am sorry for the small offtopic. I want to come back to the differences between optware and entware.
Endtware has some advantages and disadvantages. I've started to reread the discussion in 2011 - what is better to modify optware or to start a new project based on openwrt feeds (entware name was proposed later).
I can now give the main advantage of the Entware approach - it is based on a live updating openwrt project.
Entware repository is updated on a regular basis -
https://github.com/Entware/entware/wiki/Changelog
It is a pity that developers do not integrate their efforts in a single project. _________________ My forum.
It is a pity that developers do not integrate their efforts in a single project.
That is true and I'm not really familiar with how github works but if a project only has one overall maintainer won't you end up with endless forks if the maintainer loses interest? I think that is what alllexx said happened with Optware - he was "locked out" of the project and could not update it any more because the maintainer has disappeared?
...but if a project only has one overall maintainer won't you end up with endless forks if the maintainer loses interest? I think that is what alllexx said happened with Optware - he was "locked out" of the project and could not update it any more because the maintainer has disappeared?
Sure. In fact optware became really outdated and needed huge efforts for modification.
The main Entware project has 2 owners and 3 more members. https://github.com/orgs/Entware/people
Entware.arm and Qnapware are maintained by me only. _________________ My forum.
I want to come back to the differences between optware and entware.
Endtware has some advantages and disadvantages. I've started to reread the discussion in 2011 - what is better to modify optware or to start a new project based on openwrt feeds (entware name was proposed later).
I can now give the main advantage of the Entware approach - it is based on a live updating openwrt project.
Entware repository is updated on a regular basis -
https://github.com/Entware/entware/wiki/Changelog
The main 'driving force' behind Optware was Brian Zhou. After he retired as the project maintainer, nobody stepped in to fill the void. This happened when I wasn't developing Optware (sold my old WD NAS), so when I found out my developer's certificate expired, Optware was already nearly 'unmanned'.
zyxmon wrote:
It is a pity that developers do not integrate their efforts in a single project.
I appreciate Entware initiative, yet I'm much more fluent with Optware since the days I was actively developing it. OpenWRT, on the other hand, is rather alien to me.
zyxmon wrote:
In fact optware became really outdated and needed huge efforts for modification.
You're right, I had to upgrade and fix numerous packages to get them to build with gcc 4.9.2. But I think Optware's still a great build system
.... But I think Optware's still a great build system
My first public contribution was 5 years ago for optware - https://www.midnight-commander.org/ticket/2282
Optware is a great build system. But openwrt is greater. It is more flexible. It can be used in many environments because build tools are compiled on one of the first steps.
Here is a list of tools that are built. They need not be installed on host system. Their version are fixed. This is quite different from optware
https://dev.openwrt.org/browser/trunk/tools _________________ My forum.
Joined: 03 Aug 2014 Posts: 41 Location: Kyiv, Ukraine
Posted: Wed Apr 08, 2015 14:58 Post subject:
zyxmon wrote:
... Optware is a great build system. But openwrt is greater. It is more flexible. It can be used in many environments because build tools are compiled on one of the first steps.
Here is a list of tools that are built. They need not be installed on host system. Their version are fixed. This is quite different from optware
https://dev.openwrt.org/browser/trunk/tools
I don't think it's a matter of 'more or less great': they both have their pros and cons. And Optware is perfectly flexible, since you don't have to necessarily follow the template (template.mk) and can make any customizations you deem necessary. There're also a lot of examples for most of the cases you might ever need if you know where to look (some experience, or someone experienced to ask, is needed here, since there's no ample documentation, sadly). So, it's a matter of personal preference, and I prefer Optware. I'm not entirely unfamiliar with OpenWRT, btw: https://github.com/FranciscoBorges/openwrt-printing-packages/pull/14
As for build tools, from my experience, the ones that really need more or less fixed versions are:
-automake/aclocal: some old packages require features that were removed starting from certain version; while other newer ones, on contrary, need features introduced in certain version
Some older packages won't reconfigure with automake-1.15 used by OpenWRT, btw, and, unfortunately, there're enough old projects that are discontinued by their owners, so you either have to drop such packages, patch the sourcecode (which is often nontrivial) or use older automake; I chose the last option
-texinfo: had to manually downgrade it to version 4.x, since quite a lot of documentation just won't build with version 5.x
Everything else isn't that version-sensetive. Of course, I might have been lucky not to encounter situations in which it is. Anyway, if you're using Linux, it should be fine.
Joined: 03 Aug 2014 Posts: 41 Location: Kyiv, Ukraine
Posted: Wed Apr 08, 2015 15:15 Post subject:
The feed has been reported to work fine with dd-wrt (thanx MikeMcr). The question is whether end users would benefit from a similar feed for mipsel? There're some widely used alternatives: Entware and OTRW2 (of which I know). However, I have some packages that are missing from these alternatives, like:
-deluge
-mkvtoolnix
-X11 applications
-etc...
and some are newer versions.
It isn't very difficult to build such a feed, but the question is whether there's enough interest in this to justify my effort?