Kernel Traffic #246 For 26�Dec�2003

I have heard many people reference the fact that the although the Linux Kernel is under the GNU GPL license, that the code is licensed with an exception clause that says binary loadable modules do not have to be under the GPL. Obviously today there are vendors delivering binary modules (not supported by the kernel maintainers of course), so clearly people believe this to be true. However I was curious about the wording of this exception clause so I went looking for it, but I cannot seem to find it. I downloaded the 2.6-test1 kernel source code and looked at the COPYING file, but found nothing relating to this (just the note at the top from Linus saying user programs are not covered by the GPL). I also looked in the README file and nothing was mentioned there either, at least from what I could see from a quick read.

So does this exception clause exist or not? If not, how can the binary modules be valid for use under Linux if the source is not made available under the terms of the GNU GPL?

Lastly I noticed that the few source code modules I looked at to see if the exception clause was mentioned there, did not contain the usual GNU GPL preable section at the top of each file. IMHO all files need to have such a notice attached, or they are not under the GNU GPL (just being in a ZIP/tar achive with a COPYING file does not place a file under the GNU GPL). Given all the current legal stuff going on with SCO, I figured every file would have such a header. In fact some of the files I looked at didn't even contain a basic copyright notice!!

No such exception exists.

There's a clarification that user-space programs that use the standard system call interfaces aren't considered derived works, but even that isn't an "exception" - it's just a statement of a border of what is clearly considered a "derived work". User programs are _clearly_ not derived works of the kernel, and as such whatever the kernel license is just doesn't matter.

And in fact, when it comes to modules, the GPL issue is exactly the same. The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result, anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that leads to any gray areas. There are areas that are not gray at all: user space is clearly not a derived work, while kernel patches clearly _are_ derived works.

But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.

Basically:

• anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work.
• anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it.

Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area.

Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kenrel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking).

So being a module is not a sign of not being a derived work. It's just one sign that _maybe_ it might have other arguments for why it isn't derived.

Side note: historically, the Linux kernel module interfaces were really quite weak, and only exported a few tens of entry-points, and really mostly effectively only allowed character and block device drivers with standard interfaces, and loadable filesystems.

So historically, the fact that you could load a module using nothing but these standard interfaces tended to be a much stronger argument for not being very tightly coupled with the kernel.

That has changed, and the kernel module interfaces we have today are MUCH more extensive than they were back in '95 or so. These days modules are used for pretty much everything, including stuff that is very much "internal kernel" stuff and as a result the kind of historic "implied barrier" part of modules really has weakened, and as a result there is not avery strong argument for being an independent work from just the fact that you're a module.

Similarly, historically there was a much stronger argument for things like AFS and some of the binary drivers (long forgotten now) for having been developed totally independently of Linux: they literally were developed before Linux even existed, by people who had zero knowledge of Linux. That tends to strengthen the argument that they clearly aren't derived.

In contrast, these days it would be hard to argue that a new driver or filesystem was developed without any thought of Linux. I think the NVidia people can probably reasonably honestly say that the code they ported had _no_ Linux origin. But quite frankly, I'd be less inclined to believe that for some other projects out there..

This is exactly so that it is more clear which cases are black-and-white, and where people shouldn't even have to think about it for a single second. It still doesn't make the gray area go away, but it limits it a bit ("if you need this export, you're clearly doing something that requires the GPL").

Note: since the kernel itself is under the GPL, clearly anybody can modify the EXPORT_SYMBOL_GPL() line, and remove the _GPL part. That wouldn't be against the license per se. But it doesn't make a module that needs that symbol any less needful of the GPL - exactly because the thing is just a big cluehint rather than anything else.

a "binary linux kernel module" is a derived work of the kernel, and thus has to come with sources.

But if you use those same sources (and _you_ wrote them) they do not contain any Linux code, they are _clearly_ not derived from Linux, and you can license and use your own code any way you want.

You just can't make a binary module for Linux, and claim that that module isn't derived from the kernel. Because it generally is - the binary module not only included header files, but more importantly it clearly is _not_ a standalone work any more. So even if you made your own prototypes and tried hard to avoid kernel headers, it would _still_ be connected and dependent on the kernel.

And note that I'm very much talking about just the _binary_. Your source code is still very much yours, and you have the right to distribute it separately any which way you want. You wrote it, you own the copyrights to it, and it is an independent work.

But when you distribute it in a way that is CLEARLY tied to the GPL'd kernel (and a binary module is just one such clear tie - a "patch" to build it or otherwise tie it to the kernel is also such a tie, even if you distribute it as source under some other license), you're BY DEFINITION not an independent work any more.

(But exactly because I'm not a black-and-white person, I reserve the right to make a balanced decision on any particular case. I have several times felt that the module author had a perfectly valid argument for why the "default assumption" of being derived wasn't the case. That's why things like the AFS module were accepted - but not liked - in the first place).

This is why SCO's arguments are specious. IBM wrote their code, retained their copyrights to their code AND THEY SEVERED THE CONNECTION TO SCO'S CODE (and, arguably the connections didn't even exist in the first place, since apparently things like JFS were written for OS/2 as well, and the Linux port was based on that one - but that's a separate argument and independent of my point).

See the definition of "derivative" in USC 17.1.101:

A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a "derivative work".

And a binary module is an "elaboration" on the kernel. Sorry, but that is how it IS.

In short: your code is yours. The code you write is automatically copyrighted by YOU, and as such you have the right to license and use it any way you want (well, modulo _other_ laws, of course - in the US your license can't be racist, for example, but that has nothing to do with copyright laws, and would fall under a totally different legal framework).

But when you use that code to create an "elaboration" to the kernel, that makes it a derived work, and you cannot distribute it except as laid out by the GPL. A binary module is one such case, but even just a source patch is _also_ one such case. The lines you added are yours, but when you distribute it as an elaboration, you are bound by the restriction on derivative works.

Or you had better have some other strong argument why it isn't. Which has been my point all along.

personally, I have my own judgment on what "derivative works" are, and I use that judgement to decide if I'd complain or take the matter further.

And so _I_ personally think some binary modules are ok, and you've heard my arguments as to why. That means that _I_ won't sue over such uses, since in my opinion there is no copyright infringement IN THOSE CASES due to me not considering them derivative.

My opinions are fairly public, and the stuff I say in public actually does have legal weight in that it limits what I can do (if I say in public that I think something is ok, I have a much harder time then making the argument that it _isn't_ ok in front of a judge - this is what the "estoppel" thing is all about).

But the thing is, my public opinions don't bind anybody else. So if Alan Cox, or _any_ other kernel copyright holder, disagrees with me (and trust me, people do), they have the right to complain on their own. Their case would be weakened by my stance (simply because a defendant could point to my opinions and the judge might be swayed by that).

And quite frankly, my largest reason for not complaining loudly has often been that I'm lazy, and in several cases of sme people using GPL'd work improperly I have been ready to join a lawsuit that somebody else initiates. So far people have tended to back down.

I'd like to make it clear that I'm actually much softer on this than many other people - I've been making it clear that I think that binary-only modules _are_ ok, but that the burden of proof of ok'ness is squarely on the shoulders of the company that makes them.

So please do get that part clear: I'm pretty well-known for allowing binary-only modules in things like AFS and nVidia, where some people think they shouldn't be allowed.

But the real issue here (and in the subject line in this whole discussion) is about an "exception clause".

There is none. And I'm just saying that there is NO WAY that a binary-only module is "automatically in the clear". They _may_ be, but it's on the basis of something totally different than just "it's a module".

This is why I want to make it so clear that "moduleness" (which is not a word, but should be one) is not the thing that matters. There's still a strong "linkage" to a particular kernel in a binary module, and the act of running the linker is not what determines whether a work is a derived work.

In short, you should not see my arguments as a way of saying "all modules are derived works". I'm clearly not saying that, since I _do_ allow binary only modules and I don't claim they infringe.

So I'm not arguing for a very wide notion of derived works: I'm arguing AGAINST the narrow notion that a module would somehow automatically _not_ be derived.

This is why I've said at least fifty times that a kernel module is to be considered "derived by default". The non-derivedness comes from things that have nothing to do with whether it is a module.

Whats the general feeling about devfs now? I remember Christoph and others making some nasty remarks about it 6months ago or so, but later noted christoph doing some slashing and burning thereof.

Is it 'nice' yet?

My understanding is that udev takes the information exported by sysfs about what devices exist in the system, and creates device nodes in /dev (which can be a ramfs mount or part of a persistent filesystem, udev itself doesn't care). I'm guessing it traverses sysfs to see what the system's got on startup (some variant of "find /sys -name device", perhaps) and then receives hotplug events when new devices are added later. On the whole, this is generally cool, hotplug friendly, and small and simple. _and_ the result looks like a recognizable /dev directory, so end-user applications don't have to be "devfs aware" (which was a bad sign from day 1 if you ask me).

Unfortunately, sysfs doesn't yet export device node information for everything in the system yet. (There aren't any under /sys/cdev, /sys/devices/legacy, or /sys/devices/system, for example). There are pending patches to add more, but they're not considered bug fixes, so Linus won't take them before 2.6.0 and we'll have to wait until after 2.6.0 for development on this subsystem to finish.

Probably somewhere in the 2.6.4 to 2.6.6 timeframe, sysfs will have all the device exports udev needs. (Or at least all the ones anybody's complained about yet.) Until then... dunno. Maybe you can use a /dev directory on a persistent filesystem that you mknod any extra devices you need into yourself?)

This is the first release of a new kernel tree dubbed '-tiny' (someone already took -mm). The aim of this tree is to collect patches that reduce kernel disk and memory footprint as well as tools for working on small systems, an area Linux mainstream has been moving away from since Linus got a real job. Target users are things like embedded systems, small or legacy desktop folks, and handhelds.

To get the ball rolling, I've thrown in about 50 patches that trim various bits of the kernel, almost all configurable, and a fair number may eventually be appropriate for mainline. All the config options are currently thrown under CONFIG_EMBEDDED and many of the minor tweaks are covered under a set of config options called CONFIG_CORE_SMALL, CONFIG_NET_SMALL, and CONFIG_CONSOLE_SMALL.

Nifty things I've included:

• building with -Os
• 4k process stacks (via -wli)
• configurable removal of printk, BUG, and panic() strings
• configurable HZ
• configurable support for vm86, core dumps, kcore, sysfs, aio, etc.
• a very nice kmalloc auditing system via /proc/kmalloc
• auditing of bootmem usage
• a system for counting inline instantiations
• my netpoll/netconsole patches
• my drivers/char/random fixups

Some items on my todo list:

• borrow kgdb from -mm
• merge my netpoll-based kgdb-over-ethernet
• pageable kernel memory for a select subset of the kernel
• reduced functionality vt for small gui systems
• generic lookup/hash management code

How small is -tiny? It's hard to quantify as it's all configurable and some functionality is more important than others, but my current test config has full IPv4 net stack and most other important functionality and will boot comfortably on a 4M x86 box with about 2M free+buffers+cache.

Bug reports, suggestions, and patch submissions are welcome!

The patch, currently against 2.6.0-test11, can be found at:

http://selenic.com/tiny/

OK, I've put the html version up for your reading pleasure: the diff is quite extensive and hard to read.

http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/

I've prototyped an extension to BitKeeper that provides tarballs and patches. The idea is to make it possible for all trees hosted by bkbits.net provide access to the data with a free client (included below in prototype form).

The system is simplistic, it just provides a way to get the most recent sources as a tarball and then any later updates as a patch. There is no provision for generating diffs, editing files, merging, etc. All of that is something that you can write, if you want, using standard tools (think hard linked trees).

Before rolling this out, I want to know if this is going to (finally) put to rest any complaints about BK not being open source, available on all platforms, etc. You need to understand that this is all you get, we're not going to extend this so you can do anything but track the most recent sources accurately. No diffs. No getting anything but the most recent version. No revision history.

If you want anything other than the most recent version your choices are to use BitKeeper itself or, if you want the main branches of the Linux kernel, the BK2CVS exports. This is not a gateway product, it is a way for developers to track the latest and greatest with a free (source based) client. It is not a way to convert BK repos to $SCM.

If the overwhelming response is positive then I'll add this to the bkbits.net server and perhaps eventually to the BK product itself.

Licensed under the NWL - No Whining License.

You may use this, modify this, redistribute this provided you agree:

• not to whine about this product or any other products from BitMover, Inc.
• that there is no warranty of any kind.
• retain this copyright in full.

It is accessed via libusb these days opening /proc/bus/usb/*/*

Emerge (apt-get, etc, as per your distro of choice) something like gphoto2 which should include libusb by dependancy and setup hotplug.

Another edition of net driver updates.

Summary of new changes:

• revert skfddi janitorial patches. no skfddi changes are included in this patchkit anymore. Stephen Hemminger has a much better skfddi patch which obsoleted the already-merged skfddi changes.
• atmel wireless SKB leak fix
• 3c574_cs deadlock fix
• bonding destruction fix
• more work from Al making net_device allocation dynamic and sane (including fast, const-offset private structure allocation for drivers)
• sk98lin update from vendor
• TG3 update from DaveM
• new pc200syn WAN driver from WAN maintainer Krzysztof Halasa
• r8169 fixes from Francois Romieu

Summary of patchkit:

• new e100 driver (rewritten from scratch)
• new nVidia nForce NIC driver
• new pc200syn WAN driver
• tg3 bug fixes
• r8169 major bug fixes
• e1000 minor updates / fixes
• sk98lin vendor updates / fixes
• misc bug fixes
• 8139too NAPI support
• tulip NAPI support
• netconsole / netdump support
• net_device allocation and reference counting work

Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test11-bk11-netdrvr-exp1.patch.bz2

Full changelog:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test11-bk11-netdrvr-exp1.log

BK repo:
bk://gkernel.bkbits.net/net-drivers-2.5-exp

"The beaver is out of detox"
- Anon

This should not be a big surprise to anybody on the list any more, since we've been building up to it for a long time now, and for the last few weeks I haven't accepted any patches except for what amounts to fairly obvious one-liners.

Anyway, 2.6.0 is out there now, and the patch from -test11 is a swelte 11kB in size. It's not the totally empty patch I was hoping for, but judging by the bugs I worked on personally, things are looking pretty good.

To give you an example, one of the nastier bugs that we chased for the last five weeks was a bug that could only be reproduced reliably on a 16- or 32-way system, and only when the system had flaky disks. Putting in known-good disks made the problem disappear. Similarly, compiling the kernel with another compiler made the problem disappear.

It turned out to be a really subtle bug wrt SMP ordering and stack allocation, and lots of thanks to Ram Pai for gathering all the information that eventually led to it being fixed. The fix was a one-liner and a big comment - but my point is that the quality of bugs has been pretty high lately, and we feel that we're in pretty good shape.

Andrew has written up some caveats and pointers to information about 2.4.x vs 2.6.x changes, and I'll let him post that. Some known issues were not considered to be release-critical and a number of them have pending fixes in the -mm queue. Generally they just didn't have the kind of verification yet where I was willing to take them in order to make sure a fair 2.6.0 release.

NOTE! I'll continue to keep track of the 2.6 BK tree until we're closer to the time when we literally split it for 2.7.x, because both Andrew and I are pretty comfortable with our respective toolchains. But Andrew is the stable tree maintainer, so everything should be approved by him at this point. Think of the -mm tree as the staging area, and mine as a release tree. We'll work together, but Andrew is boss.

(BK merging will have to go through some approval format, we'll see how that works out exactly).

It's actually rather short because I started late. See below.

There are also the "must-fix" and "should-fix" lists of items which we have identified as still on the 2.6 todo list. These are at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/must-fix-7.txt and ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/should-fix-7.txt

• The 2.6.0 kernel has undergone several weeks of stabilization and we expect it to run well on server-class machines.

  Desktops and laptops may have more trouble at this time because of the much wider range of hardware and because of as-yet unimplemented fixes for the hardware and BIOS bugs from which these machines tend to suffer.

  During the 2.6.0 stabilization period a significant number of less serious fixes have accumulated in various auxiliary kernel trees and these shall be merged into the 2.6 stream after the 2.6.0 release. Many of these fixes appear in Andrew Morton's "-mm" tree, at

  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/

• Please report any problems to the appropriate mailing list. If you do not know which list to use, send the report to [email protected] and it should reach the right person. Some active subsystem mailing lists are:

  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]
  [email protected]

  Alternatively, kernel bug reports may be entered into the kernel bug tracking system at http://bugme.osdl.org/

• There are significant changes in the module subsystem, the LVM (Device Mapper) and RAID subsystems. Details about these and many other kernel changes are presented in David Jones's kernel upgrade document at

  http://www.linux.org.uk/~davej/docs/post-halloween-2.6.txt

  Users who are testing 2.6 kernels for the first time should consult this document.

• The ATA RAID drivers (eg the HighPoint RAID driver) have not been ported to the new BIO code and are not available under the 2.6 kernel at this time.
• cryptoloop doesn't work on highmem machines. Fixes exist in -mm and are queued for 2.6.1.

• There are known performance problems with the default disk I/O scheduler which show up when the workload is performing small, random reads and writes (ie: database loads). Largely fixed in -mm.

  In general, the "deadline" I/O scheduler is, and shall remain somewhat faster than the default "anticipatory" I/O scheduler with these sorts of workloads. Database admins should consider adding the "elevator=deadline" kernel boot parameter.

• There are performance problems due to misbehaviour in the readahead code which also impact database-style workloads. Fixed in -mm, queued for 2.6.1.
• There are a larger number of as-yet unmerged frame buffer driver fixes.

I believe that the processes we've all been using for the past year have worked well (invitation here for people to disagree). So any changes we make to that process shouldn't be arbitrary.

I expect that until 2.7.0 forks, Linus and I shall continue to work 2.6.x in much the same manner - that's what I'd prefer, anyway.

Obviously, the threshold for merging things into 2.6 becomes higher, and large changes will be rejected pending more review and testing. I shall continue to run an alternate tree for the provision of that testing service.

Generally, we should expect that there will be large changes across the 2.6 lifetime - it is unrealistic to believe otherwise. We just need to find the processes to absorb those changes (and feed them into or from 2.7.x) without breaking stuff. We've done that fairly well across 2.5 I think.

We should sit tight for the next week or so, in case we need to rush out a 2.6.1 for brown-bag bugs. After that I need to shrink the -mm patchset rather a lot.

Release 0.4.0 for libsysfs is now available at:

http://linux-diag.sourceforge.net

A number of changes have been made in this release which will require a few modifications to applications already using the library. (udev-009 already has a bulk of these changes).

Here are the important additions/changes:

• Postponed reading directories and attributes until absolutely necessary.
• Structure elements that are lists or references to structures are not populated by default. APIs have now been provided to populate them.
• All "open" functions that take absolute path as argument now have a "_path" suffix.
• Provided attribute "refresh" functions to read in updated attribute values.
• Changes for klibc compatibility.
• Provided APIs to retrieve device/class_device "parent".
• Added manpages for lsbus and systool (Thanks to Martin Pitt).

Please visit http://linux-diag.sourceforge.net/Sysfsutils.html for more information.

The first x86-64 patchkit for the 2.6.0 linux kernel has been released. I normally don't announce patchkits to linux-kernel, but a lot of people don't seem to know about them. The patchkit has fixes for many serious bugs (including data corruption iossues) on x86-64 that didn't make it in official 2.6.0. Please don't bother reporting any x86-64 problems to me if you didn't apply the patchkit first.

Hopefully now that the trees are more open again most of this can migrate into the official tree, depending on the policy enforced by Linus/Andrew.

This version just has a few minor fixes against the last patchkit release (x86_64-2.6.0test11-3)

ftp://ftp.x86-64.org/pub/linux/v2.6/x86_64-2.6.0-1.bz2
df65fee5a0388a036d324cb9b16bd778 x86_64-2.6.0-1.bz2

ChangeLog since x86_64-2.6.0test11-3:

• Mark some more non 64bit clean drivers !64BIT
• Remove dump_sg in pci-gart.c again
• Fix inefficiency in find_next_bit

Older Changelog is available in

ftp://ftp.x86-64.org/pub/linux/v2.6/RELEASE-NOTES

Some known issues:

• Taskfile IO can hang SuSE hwscan. Better disable it for now.
• Taskfile IO can cause disk corruption too.
• NMI watchdog runs too often (HZ instead once a second) (still true?) [I think that's fixed now, but needs verifying]
• Machine Check calls printk currently, but that can deadlock when the MCE occurs inside any of the console locks.
• sysfs support for arch/ may not be complete.
• 32bit SYSCALL seems to still have problems with some programs (disabled currently)
• Some reports of persistent segfaults after stress tests (also seen once here, need to be reproduced). Could be IOMMU overflow.
• Mysterious timer bug in some cases. Shortly in or after bootup the timer lists gets corrupted in some configuration. Seems to depend on how long the bootup takes.
• JFS seems to corrupt file systems quickly (generic 64bit bug) [maintainer cannot reproduce it]
• WCHAN seems to be broken
• Suspend often doesn't initialize video after wakeup Generic problem, needs a lot of effort to fix properly. The graphic card has to be POSTed properly, which is quite complicated.
• MPT fusion driver breaks when iommu merging is disabled (run with iommu=merge) A workaround for this is enabled by default now. Underlying bug still unfixed. This bug seems to only occur on some specific machines, most MPT fusion users probably don't have to worry about it. Seems to be a driver bug.
• Realtek 8169 driver does not support >4GB (patch exists, should be merged by network driver maintainer)
• Nvidia and VIA boards are forced to IO-APIC off to work around ACPI bugs. This will be a major problem once SMP boards with these chipsets are out.
• Some boards don't set the wall clock correctly
• G400 DRM crashes machine
• VIA SATA doesn't work
• Some people report disk corruptions with IOMMU. Not able to reproduce it. It seems to happen on some block device drivers who have a very deep queue. Mostly these devices don't need an IOMMU (3ware is a prominent exception) because they support 64bit IO. Unfortunately many people still run with CONFIG_IOMMU_DEBUG which will force the IOMMU support for every device. Changing the IOMMU flush to flush on every mapping seems to fix it. Currently there are workarounds active that check for Qlogic and 3ware and do that. Anybody still seeing this please try with iommu=fullflush and report back. Underlying bug still undebugged.
• Scheduler does not work well with NUMA (testcase multithreaded STREAM) It does not distribute threads quickly enough to all CPUs, which leads to memory getting allocated on the wrong nodes.
• Some motherboard/cpu combinations do not reboot automatically
• IPSec netlink setup code is not 32bit emulation clean
• iptables is not 32bit emulation clean
• gettimeofday gets non monontonous when ntpd corrects drift
• valgrind does not run even with linux32 --3gb. Figure out what is different.
• [An a.out emacs also doesn't run. Probable the same difference]