Is there any reason why the image builder comes with x86_64 binaries compiled against an ancient libstdc++? What's wrong with offering normal 32-bit binaries that work on both 32-bit and 64-bit machines, instead of binaries that only work on  64-bit ones (with the right libs available)?...

It won't work on any of my machines, and on my box at work I can't get a 64-bit libstdc++5 installed. Pretty annoying... :-/

If this is because of problems on 64-bit machines, why not include both 64- and 32-bit binaries?

You can always build the correct IB for your host-system by yourself. The IB and SDK generated out of the build system.

Short answer is that it's a conspiracy, we could post 32bit binaries, but then we'd have to actually build 32bit binaries. The developers are using 64bit machines.

In all honesty I'm not even sure why we're posting the SDK binaries; the sources are setup such that they'll attempt to automatically download and compile anything needed, including the (cross) compiler.

I know I can build it myself, but the prebuilt IB seemed like such a nice time-saver. :-(

Although the prebuilt images actually do work pretty well too. But I'm trying to figure out how to get / back on a RAM filesystem that can be saved to flash manually ("flash save"), and I suppose the way to do that is build my own image. And on a model with just 4 MB flash it'd be nice to get rid of stuff like PPP.

Oh well, even like this OpenWRT is still quite a timesaver. Thanks for all the work. :-)

To have more people access to a customizable firmware, is good for the testing.
I have Ubuntu linux running in "virtual PC 2007" from Microsoft, which lacks 64 bits emulation on 32 bits hardware.....
Would it not be nice to have a platform free firmware build system ?
I think this is possible with Python. This is available on windows and Linux (unix) platform.
I don't understand the building process of an image, but what I see is the following:
1 make a catalog of all available packages
2 extract the files to a temporary place
3 copy user specific file over it
4 make a squashfs image (or effs2??)
Step 1,2 and 3 are working on my linux pc. This could also be done by Python.
Step 4 gives an error because "mksquashfs.lzma" is 64bits. Can anyone point me to the source so I can make it into Python ?
Or some explanation of the process ?

I'd just like to add another vote for at least a 32-bit ImageBuilder, and ideally SDK too. They are so much quicker to use, especially:

* in an underpowered environment like a laptop
* under emulation, e.g. VMware (AFAIK, it's not possible to emulate a 64-bit machine inside a 32-bit host, otherwise I'd do that)

I also find SDK + ImageBuilder to be more idiot-proof... and you'll also get binary images which are bit-for-bit identical from one site to another, which is good from a consistency and repeatability point of view.

I'm currently running a 'make' of SDK and ImageBuilder on my (1.1GHz Pentium M) laptop.  I expect it's going to take rather a long time

However I'm lucky in that I run Linux natively. If I were a Windows user and having to run a full toolchain build under Linux under VMware under Windows I'd probably cry, especially if all I wanted to do was to use ImageBuilder to add a couple of packages or files to a .trx image!

Cheers, Brian.

Start at https://svn.openwrt.org/openwrt/trunk/tools/squashfs/

The Makefile gives the package URL (relative to @SF - sourceforge), and patches/100-lzma.patch adds mksquashfs-lzma

FWIW, I think that the idea of an ImageBuilder with no binary components (e.g. using one of Perl, Python, Ruby) is attractive. But in order to be useful it would have to work with "out of the box" installs of the chosen scripting language, i.e. not add dependencies on external libraries, or you could force the user into CPAN-style dependency hell.

That could mean having to rewrite a lot of C code into the scripting language (such as the squashfs builder and LZMA compressor), which could also means it runs a lot more slowly than a compiled solution.

I am a Windows User and a Linux Noob.  Four days ago, I was a Linux Virgin.

After flashing OpenWrt, then getting VMWare and Ubuntu running, the *very* first thing I downloaded was the 32-bit SDK, which I found here:

  http://downloads.openwrt.org/snapshots/atheros-2.6/

Then I worked out how to make my first "Hello World" that would run on the router.

If I'd had to use the more complex full buildsystem, or compile my own 32-bit SDK *as my first step*, it would have been a lot harder and intimidating.

So for me at least, there was definitely some value to having a precompiled 32-bit SDK binary available.

it's quite possible to emulate a 64bit machine with an actual emulator like qemu (vmware doesn't emulate at that level), but if your using it for anything more then running simple programs, it will be slow

What's wrong with compiling the binaries by yourself? If you don't know how to do it, you don't know Linux, and you don't need OpenWrt.

Speaking for myself: I do know how to compile the binaries myself, and I do know Linux. But when a new release of OpenWrt comes out, I don't want to spend 2 hours compiling before I can build an image with my own choice of packages in it. There will be hundreds of people doing the same thing. By you argument, why release the x86_64 binaries either? In fact, why release any binary distribution of Linux, when people can always build the whole lot from source themselves?

Speaking from what I've read on the forums: there's a pretty large proportion of OpenWrt users who are not Linux experts, but who are simply looking for a more flexible firmware to run on their access point. Many of these run Windows on their PCs. For some of them, OpenWrt is their first introduction to Linux; but they can still make OpenWrt do useful things with pre-compiled binaries.

Thankfully, OpenWrt (WhiteRussian) never took the view that "if you're not a Linux expert, you shouldn't be running our code". Kamikaze did, while it was a development tree. But now it has stabilised, hopefully it will now attract just a wide a user base as WhiteRussian did.

Ok but the developers have amd64 machines so it's hard for them to provide 32 bit binaries so the choice is between providing 64 bit or only source.
The first will advantage some people, while the second no, so they went for the second
Compiling from sources is the standard way, 64 bit binaries are just an "extra".

Bye

Well, as you say it's the developer's choice, and maybe it will improve over time. I notice also that only a small subset of mipsel binary packages is currently available; for example there's libpcap but no tcpdump. I hope that will improve too. Admittedly, Kamikaze does support a much wider range of targets, which makes it harder to release binaries of everything.

However, in terms of build platform, it's relatively easy to build 32 bit binaries on a 64 bit system. The converse is not true.

If that's true - and I'm not sure that it is - then that would be a big shift in position from WhiteRussian. I haven't seen it officially flagged as such by a core developer.

Certainly, building from source was the only way when Kamikaze was 'unstable', but now it's released and "regular" users are expected to migrate from WhiteRussian to Kamikaze, things maybe should be different.