lmemsm | Entries tagged with musl

I've been doing some experiments with WSL. I built an older set of the X11 libraries that doesn't require harfbuzz or libxcb as dependencies. I built them using a musl cross-compiler that creates 32 bit binaries for Linux. I built FLTK with it as well. I'm able to run FLTK GUI applications via WSL. So, the X11 libraries built with musl are capable of talking to WSLg.

It's worth noting that WSL2's 64 bit kernel is capable of running 32 bit ELF binaries. So while many Linux distributions are phasing out 32 bit support, WSL provides a useful platform to continue experimenting with it if desired. Another nice point about WSL is that it can avoid the systemd controversy. While it can be made to work with systemd, it can also use a simple init program or start with /bin/sh if necessary.

It wouldn't be hard to build a WSL distribution at this point. It could also be designed to be completely static or include shared libraries as most Linux distros do. So, a custom distribution would be possible and it would not need to be limited to command line only. It also makes a great testing ground for creating a lightweight Linux distribution that could run natively on older hardware.

WSL has really come a long way from only being able to run command line programs to running X11 apps. The incredible thing is you don't need a specific library such as glibc or specially built Wayland or X11 libraries. It works perfectly well with 32 or 64 bit binaries and a custom built set of X11 libraries. It would make a great environment to custom build a personalized distribution in.

I've been working on updating my build scripts to the latest versions of certain libraries. It can be a difficult process because, I often use older C/C++ compilers or less popular C runtime libraries and patch to make path handling more portable and build for several target platforms. I typically do a lot of patching and don't follow upstream sources that closely. I sometimes add my own build system in place of the upstream version or patch to fix build issues, security issues or even to add missing features I need.

Once I have a compiler, core utilities and basic build tools in place, I build libraries and programs in these four categories: archive, communications, graphics, audio. After that, I typically build my graphics/GUI libraries. Then, I build applications that use those GUI libraries and my audio and generic cli programs. On Linux, I build X11 libraries before building GUI libraries.

Lets Compare Notes

If anyone would be interested in following along with me as I update my libraries and programs, feel free to contact me: https://fosstodon.org/@lmemsm It would be fun to compare notes on how to build any of these packages and to share patches. I may also consider dropping some libraries or adding new ones to these categories based on what I need to build the applications I want on my system. I will be building these libraries on Windows using the original MinGW and Linux using musl and gcc. I'm considering a build for BSD system, possibly NetBSD, as well.

Here's the status of what I'm updating and how far I am in the process.

Package List

Category	Program / Library	Current Version	Latest Version
Archive	libz	1.3.2	1.3.2
	bzip2	1.0.8	1.0.8
	unzip	6.0	6.0
	zip	3.0	3.0
	liblzw	0.2	0.2
	zstd	1.5.7	1.5.7
	bsdgzip	20111009	20111009
	libxml2	2.15.3	2.15.3
	libarchive	3.8.7	3.8.7
Communications	libressl	4.3.2	4.3.2
	libssh2	1.11.1	1.11.1
	nghttp2	1.69.0	1.69.0
	curl	8.17.0	8.20.0
	certs	20260602	20260602
	putty	0.84	0.84
Graphics	libpng	1.6.58	1.6.58
	giflib	6.1.3	6.1.3
	jpeg	10	10
	jbig2dec	0.20	0.20
	tiff	4.7.1	4.7.1
	freetype	2.13.3	2.14.3
	openjpeg	2.5.4	2.5.4
	libwebp	1.6.0	1.6.0
Audio	libogg	1.3.6	1.3.6
	libvorbis	1.3.7	1.3.7
	flac	1.3.2	1.5.0
	speex	1.2.1	1.2.1
	opus	1.6.1	1.6.1
	opusfile	0.12	0.12
	wavpack	5.9.0	5.9.0
	libmodplug	0.8.9.0	0.8.9.0
	libid3tag	0.15.1b	0.15.1b
	libmad	0.15.1b	0.15.1b
	mpg123	1.25.12	1.33.5
	twolame	0.4.0	0.4.0
	libsndfile	1.0.28	1.2.2
	libao	1.2.0	1.2.0
	libtheora	1.1.1	1.2.0
	portaudio	190700_20210406	190700_20210406

I recently had an issue doing an upgrade of AIX Toolbox on an AIX machine and it caused the sudo program to fail because it couldn't find dependencies it needed to execute successfully. I started searching to see if there were simpler alternatives that could do a job similar to sudo and would not have so many dependencies. Of the various options out there, I found three that were interesting.

Doas was created for OpenBSD. There are different versions of the program, including a portable fork called OpenDoas. I tried this version, so I can't say much about the others at this point:
https://github.com/slicer69/doas
The program does build on Linux as well as on the BSD systems. It can use BSD functions on BSD systems for authentication but uses PAM on Linux and other systems. The pam_start function needs struct pam_conv to initialize and part of pam_conv points to a function that handles input. Linux, Solaris and some systems provide functions as part of their PAM library. However, not all systems have a library function to pass to pam_start. I wasn't able to find a supplied function on AIX. OpenDoas appears to have a function as part of the OpenDoas program itself. There are also some simple examples of a function that can be used with PAM available online if you're on an operating system that doesn't have one readily available.

Another option I came across was called please. It only offers the option of PAM authentication. It has the same issues for portability with regards to the function needed by pam_conv. You can find the source code for please here:
https://github.com/gblach/please

The last alternative I experimented with is sup. It's on the recommendations page at suckless.org. The interesting thing about this program is that it doesn't require PAM to work on various systems. That's a nice feature if you're building a minimal operating system and don't have the PAM library built and installed. It has an option to use a hash function to make sure that the user is running the program they're supposed to and not a program with the same name that has been substituted for it. The hash function has a less lenient license than the program on its own. I was thinking it would be nice to use a system library with a hash function instead of needing to use the one provided by the program. However, that would increase the number of dependencies the program requires. The sup program also has a feature to run a program with a fork. As I'm not a fan of the fork function and how many resources it uses and its lack of portability, I avoid that option at all costs. I remember the topic of fork coming up on the musl mailing list. The spawn function was mentioned as a more efficient alternative. Another difference between this program and the other two is that it uses hard-coded settings rather than needing external settings files. This requires recompiling to change options, but it makes it harder for someone else to modify the settings from a security standpoint. Source code for sup is available at:
https://github.com/dyne/sup

Upon further investigation, the sup that the suckless.org site recommends is the earlier version found here:
https://oldgit.suckless.org/sup/files.html
It does not include the hash and fork options and offers a more minimal implementation with straight-forward code.

I've seen some complaints that using sudo or operating/logging in as root can be more insecure. Alternatives may be more secure when they have less code and are easier to maintain and debug. That's one reason they may be attractive. However, the alternatives need to be well written or well tested and debugged or they can be more insecure than the standards. There's also the advantage of security through obscurity. If exploits use sudo, they may not be expecting or looking for an alternative like doas on a system. Many people prefer using whatever's standard assuming that it's secure enough or so many other people wouldn't be using it too. Just as having less code can be more secure, requiring less dependencies can also have security advantages. It's another way to limit the amount of code in a program. Using a shared library can also create security issues for a program that may need to be addressed.

As a cross-platform programmer, I always look for programs that will work on a variety of operating systems. The sudo alternatives port to many systems but many of their concepts won't transfer well to Windows or DOS operating systems. While you can have multiple users on some DOS variants, it's more of a single user operating system and restricting who can run things is not typically an issue. On Windows, this can be important. However, Windows has a completely different way of handling permissions and rights from Unix and Linux systems. I did run across some samples of sudo-like alternatives designed for Windows. However, they work very differently.

It was interesting to find out how programs like sudo or the alternatives I've mentioned function. A sudo-like program is owned by root and has a special permission set on the program file. By setting the suid bit on the file permission of the program, a non-root user can run the program as if they are the root user. A technique like this would not work natively on Windows. One can elevate permissions in Windows using the Windows API. However, it doesn't work in all cases. There's a way to use SeDebugPrivilege to elevate permissions in a program but some organizations turn that privilege off for their users.

Basically any of these types of sudo like programs uses a function such as execute or spawn or CreateProcess to run other programs. They allow a user who typically doesn't have permission on a particular operating system to have that permission by starting another program or process through that program. In some form or other, that program needs to have special rights to run other programs whether the user has the rights to or not.

I find it interesting that root automatically has permissions to copy, move or remove files, no matter what directory. On POSIX systems, running as root really solves a lot of permission issues especially when building and trying to install programs. While Puppy Linux embraces the idea of running as root and some small, single user systems work fine this way, many Unix and Linux systems highly discourage running as root. While it's nice to be able to easily install a program you built, it's not helpful if you accidentally install something over another library or program and cause your system to fail in the process. It's also easier to accidentally remove needed files in a critical directory when you have the permissions to remove anything. For instance, a misbehaving install script could easily wipe out files needed for the system to operate properly. I do feel that critical programs with dependencies, if built statically, have several advantages to programs using shared libraries. They won't fail if there are issues with finding or loading a shared library on the system. Also, someone can't hack the system by having that program load the wrong library with a function that doesn't do what's intended. At this time, static building isn't widely embraced on Linux systems and the GNU glibc library cannot be used to build static programs. One would need to use a C library such as musl if static builds are desired. I personally happen to think there are many advantages to using musl over glibc. However, at this point most Linux operating systems still use glibc. Both using alternatives to glibc and running as root are not mainstream practices and both can be controversial in many sectors. There are pros and cons to running as root versus running as another user. That's what makes programs like sudo and similar alternatives so useful. They give the power of root but can limit what you can do with it to make sure you don't accidentally run commands that could disrupt or cripple the operating system.

Personally, I'd like to see a cross-platform sudo alternative that would work with Windows as well as Unix (including AIX) and Linux operating systems. It would be nice to have a small, simple program that would work for most multi-user operating systems available. I prefer the idea of a more compact program with very limited dependencies. A static build or no extra libraries would have avoided my shared library issue on AIX which caused sudo to fail.

I'd be very intrigued to hear about other sudo alternatives that are available. I'd also be interested in hearing about the pros and cons of security with regards to use of some of these programs. What do you regularly use on your system? What alternatives to root or sudo have you found? What works well on multi-user operating systems beyond Linux and Unix? What are your security concerns using sudo or some of these alternatives and how do you work around them? Feel free to share some of your comments on the topic on Mastodon. I'll be updating this article with more information if I find other lightweight, low dependency sudo alternatives that I like.

Was at a PHP meetup where the group was discussing Docker. Members and the presenter knew certain Linux distributions had a smaller footprint for use with Docker. I was surprised to find out they really didn't know why that was. One of the key factors is the C runtime library. Basic C runtime libraries just cover the functions and data structures that are part of the ISO C standard. Many C runtime libraries also add functions and data structures that are part of the POSIX standard as documented by the Open Group. Some C runtime libraries are rather bloated and provide a wide variety of functions (even beyond those documented by the ISO C and POSIX standards). Others provide a bare minimum. Some, especially those targeting embedded systems are designed for efficiency. Others are designed for functionality. Some provide no Unicode support (locale 'C' only). Some like musl, concentrate on UTF-8 support. Some try to support a large variety of characters sets and internationalization features. All these factors can affect code size and efficiency when compiling programs.

Alpine Linux previously used the uclibc runtime library and now uses the musl library. Most major Linux distributions use glibc. It was a big step, but a positive one when Debian (and Ubuntu) made the switch to eglibc. The choice of C runtime library can make a huge difference for the operating system.

For Windows developers, if you're using MinGW, the GNU compiler on Windows, you're using the Microsoft runtime libraries. The original version of MinGW used crtdll.dll but later versions use msvcrt.dll. Windows systems typically have one of these runtime libraries already installed. So while, you can't distribute Microsoft's libraries, you really don't have to. At least one is already on any particular Windows system. It gets even more complicated because different versions of Windows have different versions of msvcrt (such as msvcr70.dll, msvcr80.dll). MinGW uses a subset of the runtime functions based on Visual Studio 6.0. There are ways to access runtime functions from later versions of Visual Studio, but the application becomes less portable to various versions of Windows. Cygwin which also works on Windows, avoids the problem of dealing with multiple Windows runtime libraries and dlls and provides better POSIX compatibility for their runtime library by using a runtime library based on newlib.

There are a wide variety of runtime libraries designed for embedded systems. They're typical more compact and less bloated than a library like glibc and many are easier to port to various platforms. Of the runtime libraries available for embedded systems that are highly portable, I thought the newlib design was interesting. newlib is currently maintained by Red Hat. There are a limited number of syscalls (typically functionality provided by the kernel) that one needs to provide code for to get the library to work. Newlib uses a combination of public domain and BSD style licenses. Cygwin uses a runtime library derived from newlib, but adds several POSIX functions. It also uses a GNU GPL license. That means whenever you distribute programs linked with their runtime library you must also distribute the source code in order to be compliant with the GPL license.

As mentioned, the standard C library on most Linux distributions is glibc which was developed by the Free Software Foundation. The glibc project was slow to take patches and is a rather large library, so some distributions switched to eglibc which is binary compatible with glibc. The binary compatibility makes it easy to switch between the two. Some Linux distributions wanted to avoid bloated C libraries and work well on low resource or older systems. They chose uclibc which was designed for embedded systems. When I worked with a uclibc based distribution, I found myself making several patches to Open Source programs just to get them to compile. Many Linux distributions such as Alpine Linux are now using musl. It's designed for efficiency and standards compliance including full POSIX standards compliance.

musl was designed to work with a Linux kernel. So unlike choices such as newlib, it is not easy to port to other operating systems. The midipix project is endeavoring to create a POSIX compatible layer for Windows, so that musl will work out of the box on that system. Musl uses a MIT license. The midipix project will use a more restrictive license similar to Cygwin. Many basic embedded system libraries tend to use less restrictive licenses like MIT and BSD so that they will be adopted by companies. However, project or company adapts a C library to a particular system and adds a lot of functionality, they typically tend to use GNU GPL or other more restrictive licenses. Many projects dual license in hopes of selling companies a commercial license with less restrictions.

Google developed the Bionic C library for it's Android operating systems. It has a BSD license. It's also designed to work on low resource systems so it tends to offer less functionality than other C libraries such as glibc. It has partial POSIX support.

I've been hitting many limitations with the MinGW runtime libraries when it comes to porting. Alternatives such as Cygwin's or midipix's runtime libraries would overcome the issues. However, the licenses are much more restrictive. I know I definitely wanted more POSIX compatibility on Windows than MinGW offers out of the box. As a cross-platform programmer, it would be nice to take whatever C runtime library I end up with on Windows and reuse it on Linux and other systems. I looked at C runtime libraries for embedded systems which typically port well. Of those, newlib seemed the most interesting, because according to some of the documentation it only requires 17 syscalls to port it to an operating system. Some Windows CE compiler ports use newlib with added functionality for the Windows CE operating system to derive a working C/C++ compiler. When I investigated the newlib code, I did not particularly like the design, especially the way it handled threading by providing standard and threaded versions of functions. The implementation of file I/O looked like it had been modified several times and at this point could use a major refactoring. When I read some of the comments in that section of the code, I felt very uncomfortable using the library. I wanted a simple, clean, basic design that I can add to.

Another option I looked at was PDClib. I love the idea of a public domain library. MinGW original licensed their WIN32 and runtime code (which integrates with Microsoft's code) as public domain.
PDCLib was based on an earlier Public Domain library project originally at Sourceforge. I tried PDClib on Windows (which the developer says he uses it with), but I was unable to get file I/O to work properly. I contacted the developer to see if he needed with the project, but he really didn't seem to need any assistance at the time. PDClib only supports standard C functions. It does not provide any POSIX functionality. So, it would have limited usage as is for running most Open Source programs.

A number of original operating systems use their own C runtime libraries. I figure, if they can reinvent the wheel and create a C runtime library for their particular purposes, so can I.

I've been coding functions that are typically part of the C runtime library in order to provide better porting support for Windows. I wrote a C11 compatible thread library, several BSD and POSIX string functions, some POSIX file functions, etc. That left me with the dilemma of how best to integrate the additions with the runtime library. They really should be part of the library and part of the C standard headers. I currently have them implemented as supplemental libraries that have to be added separately. It's easier to test and integrate on various operating systems that way. Ideally, it would be nice to have everything accessible as one library though.

I'm very familiar in the various methods of connecting to the kernel in Windows. Some projects such as midipix just use ntdll.dll. Other projects connect to other Microsoft dlls such as kernel32.dll. One can use LoadLibrary, GetProcAddress to connect t a dll or if the library is already linked in, one can skip LoadLibrary. A few Open Source projects I've seen actually implement the LoadLibrary functionality from scratch. I'm not as familiar with the techniques to connect to the Linux, BSD and other kernels and would love to find more clear documentation on this subject. If you run across any good materials, please let me know ( http://www.distasis.com/connect.htm ). Linux uses techniques such as vdso, vsyscall, syscall to call kernel functions.

I find it fascinating to consider the design trade-offs of various C runtime libraries. With that in mind, here's a list of some of the C runtime library options:

eglibc:
http://www.eglibc.org/home
uclibc:
https://www.uclibc.org/
musl:
https://www.musl-libc.org/

Linux from Scratch build instructions (including musl)
http://clfs.org/view/clfs-embedded/arm/
midipix
http://midipix.org/
BSD regular expression library
(Musl regular expression support was forked from this library.)
https://github.com/laurikari/tre

PDCLib:
http://pdclib.e43.eu/
Original Public Domain C library:
https://sourceforge.net/projects/pdclib/
https://sourceforge.net/projects/pdos/
Another fork of PDCLib:
https://github.com/DevSolar/pdclib
libTom Public Domain libraries for math and cryptographics functions
(Some of musl's functions were forked from these.)
http://www.libtom.net/
libc11:
https://github.com/dryc/libc11
Eltanin-OS simia:
https://github.com/eltanin-os/simia

Bionic:
https://github.com/android/platform_bionic

Newlib:
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree
libgw32c:
http://gnuwin32.sourceforge.net/packages/libgw32c.htm

Windows CE cross-compiler:
http://cegcc.sourceforge.net/
https://sourceforge.net/p/cegcc/code/HEAD/tree/

ELKS
https://github.com/jbruchon/elks

FUZIX
https://github.com/EtchedPixels/FUZIX

lib43:
https://github.com/lunixbochs/lib43

Embedded Artistry's libc:
https://github.com/embeddedartistry/libc

GNO
https://github.com/GnoConsortium/gno

Sortix C library:
https://gitlab.com/sortix/sortix/blob/master/libc/

MentOS:
https://github.com/mentos-team/MentOS/tree/master/libc/src

olibc:
https://github.com/olibc/olibc

CloudABI's standard C library:
https://github.com/NuxiNL/cloudlibc/

cc65 - C for 6502 systems:
https://github.com/cc65/cc65

kLIBC fork for OS/2:
https://github.com/bitwiseworks/libc

clib2 for Amiga
https://github.com/adtools/clib2

welibc:
https://bitbucket.org/wrelam/welibc/src/master/

There are some great Open Source applications out there for desktops and laptop machines, but it's much harder to find Open Source for mobile devices. Most mobile devices require their users to go through a proprietary app store just to get software onto their devices. This is a setup back for the Open Source movement since more and more people are turning to mobile devices as their primary computing source.

If you have suggestions and/or recommendations for FLOSS alternatives in the mobile space, please share them with me and other Free, Libre and Open Source advocates on the Schoolforge mailing list ( https://schoolforge.net/ ).

I'll share some Open Source options I've found to date for developing mobile and cloud based applications.

Cross-platform Mobile App Development

Here are a couple of very interesting projects that let developers create cross-platform mobile applications:

https://github.com/MoSync
Developers can use C/C++ which can be compiled to run natively on certain platforms or converted to Java bytecode output that can run on phones that only support Java applications. One can also develop HTML/CSS/JavaScript applications for phones that support those formats (similar to Cordova).

https://cordova.apache.org/
This project supports HTML/CSS/JavaScript development of applications that will work on a wide variety of mobile platforms.

C/C++ Mobile Development

If you want to port your own C/C++ programs or interesting Open Source C/C++ applications to mobile devices such as Android, these projects may be useful.

https://wiki.libsdl.org/Android
Information on using libSDL 2.x with Android.

https://github.com/georgp24/microwindows-android-bin
Port of Nano-X/MicroWindows to Android. Nano-X/MicroWindows supports a subset of simple X11 and Windows applications. Many FLTK applications port easily when run with Nano-X.

https://wiki.allegro.cc/index.php?title=Running_Allegro_applications_on_Android
Article on building and running Allegro based applications on Android.

C/C++ CGI Development

As a C/C++ programmer, I was surprised by how few CGI applications were built with these languages. Originally, I read that the reasoning behind this was that one would have to spawn a new process every time one wanted to run a C/C++ CGI program. Interpreted languages could be built into the web server and avoid spawning new processes. However, with the introduction of libraries such as FastCGI, the inefficiencies of running compiled programs as CGI applications is no longer an issue. From everything I've read, C/C++ CGI programs are much faster than other CGI programs if they avoid the process spawning issue. If you want a highly efficient CGI program, it's a good time to revisit using C/C++ with the proper libraries.

Here's some more information on FastCGI.
https://en.wikipedia.org/wiki/FastCGI

If anyone's interested, I have builds of FastCGI and Apache with fcgid support for Windows/MinGW (including patches to get them working on later versions of Windows).

https://github.com/kristapsdz/kcgi
This looks like an alternative to FastCGI.

https://github.com/emweb/wt
Wt is one of the few projects I've seen that tries to provide useful CGI functionality and routines for C/C++ programmers.

https://github.com/boutell/cgic
cgic is an ANSI C library for CGI programming.

https://sourceforge.net/projects/cgi-c/
Memory and speed optimized CGI library written in ANSI C. It does all the normal CGI functions, can be used with FastCGI and can receive file uploads.

https://github.com/codazoda/cgi-lib/
ANSI C library for CGI programming.

http://www.newbreedsoftware.com/cgi-util/
cgi-util is a library for creating CGI programs.

https://www.gnu.org/software/cgicc/doc/index.html
cgicc is a GNU C++ class library for writing CGI applications.

https://eekim.com/software/cgihtml/index.html
CGI and HTML routines written for C.

http://cgilib.sourceforge.net/
cgilib is a C++ LGPL library for developing CGI programs and generating XHTML 1.0.

https://sourceforge.net/projects/cawfeecgi/
Cawfee is a C++ CGI library.

http://www.asksasha.com/download.html
C++ macro preprocessor for development of CGI programs.

http://ocicpplib.sourceforge.net/cgi_utils.shtml
CGI utilities library for OCI C++ (Oracle interface) library.

https://kristaps.bsd.lv/kcgi/
kcgi is an open source CGI and FastCGI library for C/C++ web applications.

https://www.infodrom.org/projects/cgilib/
Lightweight CGI Library provides an easy to use interface to CGI for fast CGI programs written in C or C++.

http://wolkykim.github.io/qdecoder/
qDecoder is a simple and powerful CGI library.

https://sourceforge.net/projects/libscgi/
scgi library in C.

https://github.com/jhyle/sepia
SCGI REST lib in C.

http://www.rlgsc.com/openvms-bootcamp/2011/web-server-scripting-in-c.html
Talk on Web Server Scripting in "C".

C/C++ on the Web

http://kripken.github.io/emscripten-site/
One can also use projects like emscripten to compile C/C++ code into JavaScript that will run on the web. It's an easy way to port your own C/C++ applications or run popular Open Source applications to the web.

https://webassembly.org/
Emscripten is being replaced by a newer standard called webassembly. The musl C runtime library has been ported to work with webassembly. The project is called WASI. So, many SDL based applications become easy to port to the web.

Some C/C++ examples using emscripten and/or webassembly are:
https://github.com/humu2009/tinygl.js?files=1
Tinygl.js which gives an OpenGL subset
https://medium.com/@robaboukhalil/porting-games-to-the-web-with-webassembly-70d598e1a3ec
Porting an SDL based asteroids game to web assembly
https://00f.net/2019/04/07/compiling-to-webassembly-with-llvm-and-clang/
Compiling C to WebAssembly using clang/LLVM and WASI

JavaScript

Another area of web development that surprises me is when I see so many language alternatives to JavaScript. JavaScript is supported (in some fashion) by most browsers. However, other programming languages are not. In order to get other languages to work in a browser, they typically need to be converted back to JavaScript. In a case like emscripten, it can be useful to convert C/C++ to JavaScript for porting purposes. However, many new web projects are choosing other languages besides JavaScript (because developers prefer the language) and then using tools to convert those languages back to JavaScript so they'll work via the Internet. Often the conversions introduce a lot of unnecessary code or provide slower implementations than the original. If I'm porting a project that's already written, it's great to be able to move it over with projects like emscripten. However, if I'm writing something new for the web that requires a programming language, I always use JavaScript. It's more efficient to write something specifically for that language than rely on generated code converted from another language.

It's also nice to be able to write CGI in JavaScript and share the same functions, objects and code between the client (browser) and the server. This is one of the major benefits provided by projects like CommonJS. The CommonJS site used to maintain a very nice list of server side JavaScript implementations. Unfortunately, the CommonJS project appears to no longer be active. It's been replaced by more implementation specific solutions like node.js.

There are alternatives for running server side JavaScript other than node.js if you don't want to be locked into a particular web server.

One option is TeaJS which uses FastCGI and works with a variety of web servers including Apache and Nginx.
https://github.com/ondras/TeaJS

Another option is jsc which is a JavaScript implementation that is a part of Webkit (one of the most commonly used browser libraries).

There are also some interesting TinyJS implementations and forks at various code archives such as github. You'll find more details under my Scripting Languages post ( http://lmemsm.dreamwidth.org/2239.html ).