OpenWrt Forum Archive

Topic: PHP package for testing

The content of this topic has been archived on 30 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Built PHP for OpenWRT.  It's available at my repository (the only package there, mind you) at:

BE WARNED: it's big (about 1.2 MB), i haven't tried to slim it down, if that's even possible.  i'm mostly trying to get to a point where i can work on a php interface on my router.

i've also zipped up my rules and the patch to the 4.3.7 php source for those who wish to roll their own. it's at

if you slim it down or get it to work with busybox, i'd love to hear.

php installs and works, in the sense that you can run it from the command line and see that it will output correctly.  no dice when i put a script such as this in /www/cgi-bin/

<? phpinfo() ?>

although that will run fine from the command line. 

something about busybox not exporting SCRIPT_FILENAME or something?  anyway, i'll try compiling a different httpd server...

So, we figured out there's a bug somewhere...

Patch doesn't work, apparently.

There's a patch for mini_httpd here: … actionargs[]=15&actionargs[]=11

You just have to get the SCRIPT_FILENAME into the environment.

The patch worked for me... Thanks!

Looks like I am too late but I was able to get it to work without recompiling by using two scripts:





chmod +x /www/cgi-bin/script*.php

Then load http://yourwrt/cgi-bin/script1.php in your browser.

Of course you don't want to have to have a wrapper script for everything so the patch is certainly the way to go. Guess it's time to start compiling. smile

so here's a question.  it seems like we're going to need to include a separate browser to get this working.  what are people's thoughts on which one to use.

some possibilites come to mind, some of which need patching to export the appropriate php variables.

mini-httpd - needs a patch
boa -- also needs a patch


Well, mini_httpd is about 72k, but that's dynamically linked to openssl. I've also played with Thy which should work without a patch since it lets you inject variables. That server is 683k (not optimized) and appears to have SSL support built in.

I'll play with CGI and check sizes for thy this eve or something.

i compiled thttpd 2.25b and --guess what -- it had the same problem.  i feel like this is either a bug in php or me doing something horribly wrong.

anyway, thttpd is about 100k, but i think it can be knocked down.  i'm going to compile the php-thttpd sapi tonight but i have to backtrack a few versions of thttpd to get that to work. 

totally ridiculous that i can't get this php cgi thing working.   it seems like if anything the solution should be a patch to php not to every random cgi-compliant webserver that it doesn't work.  in other words -- unless i'm doing something dumb (certainly a possibility) -- i think the problem is php's, not busybox's or boa's or mini-httpd's or thttpd's.

yeah, ive seen that.  the problem with the busybox patch is that unless it gets incorporated in the build it will required a user to redownload all 700+ kb of busybox.

i think the problem is php. see this bug report

but the patch linked to there didn't solve the problem for me.  neither did the php.ini solution referenced in the comments.

I am not exactly sure what httpd I am running. It's only 50900 bytes, has /www/cgi-bin support. It's the one I made the php wrapper script for earlier in the thread and it's running this:

I think it's an older copy of micro-asp but not sure. Maybe someone here recognizes it?

# /usr/bin/httpd -h
Usage: /usr/bin/httpd -d doc_root -P pidfile [-p port]
        -p port : which port to listen ?
        -d doc_root : doc root for html asp pages (default /www )

I'm wondering if I couldn't just hack micro-asp? I actually compiled the latest version last night but it doesn't seem to behave at all like the httpd I am currently running. I have a bad memory!

got it working using thttpd and the php thttpd sapi.  it's one package (since php rolls into thttpd).  it's big (because php + thttpd).  it's available at my repository.

no need to install php to get it to work, just my thttpd-php package.

no postinst scripts yet so just run it with the -d invocation, as in:

thttpd -d /www

Sam, you *are* the man. smile  Here's my front PHP page moved to your server:

I am curious that the "preg_match()" function is not available in this thttp/php binary? See the error at the bottom of my page where I use preg_match. What the page normally looks like:

The source:

Not that it's a big deal, it's already WAY more than I ever dreamed possible. smile

glad you like it.  i didn't really do much other than compile, though.

i got some hints on the minimal patching to php from this site

plus patching the configure script to not give test build errors.  oh and the preg_match missing probably comes from compiling with -disable-all option which i think kills the --with-regex=TYPE option

after some chat on irc, i think the real question is will php be a viable solution or it destined to be too big? on mbm's suggestion, i'm gonna have a look at php3 and see what sort of size that is.

any other suggestions for the an interface script are welcome.  i guess asp has been bounced around as an idea -- that's what linksys uses, right?  probably i shouldn't let my fsf aesthetic forbid that possibility.

after some chat on irc, i think the real question is will php be a viable solution or it destined to be too big? on mbm's suggestion, i'm gonna have a look at php3 and see what sort of size that is.

Well, it doesn't take up *any* space on my system, just the amount of memory it uses up when it's loaded. I have two different web servers running on two different ports at the same time right now and still have close to 6MB free memory. I have 2GB of disk space for web pages (NFS). smile  That's all on the puny little 54G. I forgot how much can actually be done with such limited resources.

Memory/Disk stats:

Of course I know it isn't practical for everyone to have NFS shares mounted.

Hi Sam,

here's what I found while digging into Freshmeat a couple of days ago :
· Emu, The Embeddable Utility Language, already mentionned by _marc_ in a previous post ;
· Ember, extendable with modules (for nvram) ;
· SEE, Simple ECMAScript Engine, for a server-side JavaScript, if you really want some sort of asp wink .

I looked at MbedThis (appWeb) too, but it's written in C++ and was a nightmare to build. I managed to make it run (and serve the default OpenWRT page) but didn't go any further. I can provide a binary / package (~500 KB) if you're interested...


php3's on the repository.  it comes in at 600kb on the nose.  not small, but smaller than 4.  it has the same cgi-env problem as php4 so you'll need a patched server or wrapper-script, etc...

[*]Ember, extendable with modules (for nvram) ;

I've looked at ember ; it looks very good ; easy to extend, an embeded interpreter (w3e) has been writen ; syntax is just like C or php ; licence is based on GPL ; this product is writen by Hugues who has created mSQL. There is a linHttpd library for creating a tiny web server ; I suppose that Ember and libHttpd can work together.

here is a screenshot :

mquinton@muon:~/Dev/ember-1.7/src/w3e$ ls -al
total 648
   4 drwxrwsr-x    2 mquinton mquinton     4096 2004-06-16 09:16 ./
   4 drwxrwsr-x    9 mquinton mquinton     4096 2004-06-16 09:15 ../
   4 -rw-rwxr--    1 mquinton mquinton      343 2001-07-13 01:05 Makefile*
   4 -rw-rw-r--    1 mquinton mquinton     1571 2004-06-16 09:16 Makefile.full
   4 -rw-rwxr--    1 mquinton mquinton      198 2001-08-07 07:12 Makefile.tmpl*
   4 -rw-rw-r--    1 mquinton mquinton     3085 2001-07-13 01:05 mod_www.c
   4 -rw-rw-r--    1 mquinton mquinton      205 2001-07-13 01:05 test.msql
604 -rwxrwxr-x    1 mquinton mquinton   610583 2004-06-16 09:16 w3e*
  16 -rw-rw-r--    1 mquinton mquinton    13669 2002-10-03 05:22 w3e.c
mquinton@muon:~/Dev/ember-1.7/src/w3e$ ldd w3e => /lib/ (0x40027000) => /lib/ (0x4003c000) => /lib/ (0x4003f000)
    /lib/ => /lib/ (0x40000000)
mquinton@muon:~/Dev/ember-1.7/src/w3e$ strip w3e
mquinton@muon:~/Dev/ember-1.7/src/w3e$ ls -al w3e
136 -rwxrwxr-x    1 mquinton mquinton   134684 2004-06-16 09:21 w3e*
mquinton@muon:~/Dev/ember-1.7/src/w3e$ size w3e
   text       data        bss        dec        hex    filename
115916      13732     133580     263228      4043c    w3e

and a sample embeded page :
mquinton@muon:~/Dev/ember-1.7/src/w3e$ cat test.msql

<H3>Test Page</H3>
    funct funct1(text $msg)


    $count = 0;
    while($count < 10)


i'm willing to switch faiths.  you have any interesting links? sites that use it? sample code? etc...

i'll google around tonight.

Ember's w3e looks to be 245k stripped on my box, and works fine under mini_httpd's CGI. It's dynamically linked to something, tho.

I'm leaning towards mini_httpd because it has CGI and SSL support using the OpenSSL libraries and is 73k... I played with thy for a bit (which looks really nice) but the SSL support is through gnutls and it's 186k without it. Of course, libcrypto is 1.4M...

I'll play with it some more... looks interesting.

as far as ssl goes, might be worth looking into matrixSSL since OpenSSL is so big.

beating a dead horse...

php3 is up on my repository again, but this time it works with busybox.  on php3 it was just a matter of enabling discard-path.

still 600k, though.  i wonder if it makes sense to try to create a php-lite pulling out functions that won't be needed for a router interface.

you can find buildroot/make/ for building ember and w3e for your openwrt at :

we should create a page on wiki that make a summary of availlable .mk for OpenWrt juste like ipkg.

perhaps we should distinct .mk that build ipkg from others.

we should create a page on wiki that make a summary of availlable .mk for OpenWrt juste like ipkg.

perhaps we should distinct .mk that build ipkg from others.

i agree, and also for any necessary source patches to get it to compile or run.

also, i know this has been talked about before, but i wish there was standardized package labeling.  i don't even really care what it is -- maybe mbm could just declare something as the standard.

Hi all,

perhaps we should distinct .mk that build ipkg from others.

why not move all the packaging work out of the .mk stuff, in its own directory (./packages) with one directory/Makefile for each package.
It would call the main Makefile with one ore more targets to build, then copy intersting files in a destination directory and package it.
The package related files (configs, init-scripts, etc...) in this directory could be provided and updated separate from the rest.

What do you think ?


The discussion might have continued from here.