Autotools Mythbuster: automake pains

And we start the new year with more Autotools Mythbusting — although in this case it’s not with the help of upstream, who actually seemed to make it more difficult. What’s going on? Well, there has been two releases already, 1.13 and 1.13.1, and the changes are quite “interesting” — or to use a different word, worrisome.

First of all, there are two releases because the first one (1.13) was removing two macros (AM_CONFIG_HEADER and AM_PROG_CC_STDC) that were not deprecated in the previous release. After a complain from Paolo Bonzini related to a patch to sed to get rid of the old macros, Stefano decided to re-introduce the macros as deprecated in 1.13.1. What does this tell me? Well, two things mainly: the first is that this release has been rushed out without enough testing (the beta for it was released on December 19th!). The second that there is still no proper process in the deprecation of features with clear deadlines of when they are to disappear.

This impression is further strengthened in respect with some of the deprecation that appear in this new release, and some of the removals that did not happen at all.

This release was supposed to mark the first one not supporting the old-style name of configure.in for the autoconf input script — if you have any project still using that name you should update now. For some reason – none of which has been discussed on the automake mailing list, unsurprisingly – it was decided to postpone this to the next release. It still is a perfectly good idea to rename the files now, but you can probably get pissed easily if you felt pressurized into getting ready for the new release, and then the requirement is dropped without further notice.

Another removal that was supposed to happen with this release was the three-parameters AM_INIT_AUTOMAKE call, which substitutes the parameters of AC_INIT, instead of providing the automake options. The use of this macro is, though, still common for packages that calculate their version number dynamically, such as from the GIT repository itself, as it’s not possible to have a variable version passed to AC_INIT. Now, instead of just marking the feature as deprecated but keeping it around, the situation is that the syntax is no longer documented but it’s still usable. Which means I have to document it myself, as I find it extremely stupid to have a feature that is not documented anywhere, but is found in the wild. It’s exactly for bad decisions like this that I started Autotools Mythbuster.

This is not much different from what has happened with the AM_PROG_MKDIR macro, which was supposed to be deprecated/removed in 1.12, with the variables being kept around for a little longer — first it ended up being completely messed up in 1.12 to the point that the first two releases of that series dropped the variables which were supposed to stay around and the removal of the macro (but not o fthe variables) is now scheduled for 1.14 because, among others, GNU gettext is still using it — the issue has been reported, and I also think it has been fixed in GIT already, but there is no new release, nor a date for it to get fixed in a release.

All of this is already documented in Autotools Mythbuster even though there is more work to do.

Then there are things that changed, or were introduced in this release. First of all, silent rules are no longer optional — this basically means that the silent-rules option to the automake init is now a no-op, and the generated makefiles all have the silent rules harness included (but not enabled by default as usual). For me this meant a rewrite of the related section as now you have one more variant of automake to support. Then there finally is support in aclocal to get the macro directory selected in configure.ac — unfortunately this for me meant I had to rewrite another section of my guide to account for it, and now both the old and the new method are documented in there.

There are more notes in the NEWS file, and more things that are scheduled to appear in the next release, an I’ll try to cover them in my Autotools Mythbuster over the next week or so — I’ll expect this time I need to get into the details of Makefile.am like i have tried to avoid up to now. It’s quite a bit of work but it might be what makes the difference for so many autotools users out there that I really can’t avoid the task at this point. In the mean time, I welcome all support, be it through patches, suggestions, Flattr, Amazon, or whatever else — the easiest way is to show the guide around: not only it’ll reduce the headaches for me and the other distribution packagers to have people actually knowing how to work on autotools, but also the more people know about it, the more contributions are likely to come in. Writing Autotools Mythbuster is far from easy, and sometimes it’s not enjoyable at all, but I guess it’s for the best.

Finally, a word about the status of automake in Gentoo — I’m leaving to Mike to bump the package in tree, once he’s done that, I’ll prepare to run a tinderbox with it — hopefully just getting the reverse dependencies for automake would be enough, thanks to autotools.eclass. For when the tinderbox is running, I hope I’ll have all the possible failures covered in the guide, as it’ll make the job of my Gentoo peers much easier.

Trouble in GNU: an opportunity for improving?

I have posted a note about the way FSF (America) started acting like a dictator with the GNU project and the software maintained under its umbrella, which lead to the splitting of GnuTLS — which is something that Nikos is not currently commenting on, simply because he’s now negotiating what’s going to happen with it.

Well, the next step has been Paolo stepping down as GNU maintainer, after releasing a new version of sed. This actually made me think a bit more. What’s going on with sed, grep and the like? Well, most likely they’ll get a new maintainer and they’ll keep going that way. But should we see this as an opportunity? You probably remember that some time ago I suggested we could be less GNU — or at least, less reliant on GNU.

So while I’m definitely not going to fork sed myself – I have enough trouble with unpaper especially considering that while in America I didn’t have a scanner, which is a necessity to develop it – but there definitely is room for improvement with it. First of all, it would be a good choice to start with, to get rid of the damn gnulib and eventually implementing what is an extension of glibc itself as an external library (something like libgsupc). Even if this didn’t work on anything but FreeBSD and Linux, it would still be an improvement, and I’m pretty sure it would be feasible without needing that hairy mess of code that, in the source code for sed takes five times as much as the sed sources themselves — 200KiB are the sources for the program, 1.1MiB is the gnulib copies.

Having a new, much less political project to oversee the development of core system utilities would also most likely consolidate some projects that are currently being developed outside of GNU altogether, or simply don’t fit with their scope because they are Linux-specific, which would probably make for a better final user experience. Plus things like keeping man pages actually up to date instead of relying on the info manuals, would almost certainly help!

So can any of you think of other ways to improve the GNU utilities by breaking out of GNU’s boundaries (which is what Nikos and Paolo seem to be striving for), maybe it is possible to get something that is better for everybody and Free at the same time. Myself I know I need to spend some time to fix the dependency upon readline that is present in GnuTLS just for the utilities..

GNU is actually a totalitarian regime

You probably remember that I’m not one to fall in line with the Free Software Foundation — a different story goes for the FSFe which I support and I look forward for the moment when I can come back as a supporter; for the moment I’m afraid that I have to contribute only as a developer.

Well, it seems like more people are joining in the club. After Werner complained about the handling of GNU copyright assignments – not much after my covering of Gentoo’s assignments which should probably make those suggesting a GNUish approach to said copyright assignment think a lot – Nikos of GnuTLS decided to split off the GNU project.

Why did Nikos decide this? Well, it seems like the problem is that both Werner and Nikos are tired of the secrecy in the GNU project and even more of the inability to discuss, even in a private setting, some topics because they are deemed taboo by the FSF, in the person of Richard Stallman.

So, Nikos decided to move the lists, source code and website on its own hosting, and then declared GnuTLS no longer part of the GNU project. Do you think that this would have put the FSF in a “what are we doing wrong?” mood? Hah, naïve are you! Indeed the response from the FSF (in the person of Richard Stallman, see a pattern?) was to tell Nikos (who wrote, contributed to GNU, and maintained the project) that he can’t take his own project and take it out of GNU, and that if he wants he can resign from the maintainer’s post.

Well, now it seems like we might end up with a “libreTLS” package, as Nikos is open to renaming the project… it’s going to be quite a bit of a problem I’d say, if anything because I want to track Nikos’s development more than GNU’s, and thus I would hope for the “reverse fork” from the GNU project to just die off. Considering I also had to sign the assignment paperwork (and in the time that said paperwork was being handled, I lost time/motivation for the contributions I had in mind, lovely isn’t it?).

Well, what this makes very clear to me is that I still don’t like the way the GNU project, and the FSF are managed, and that my respect for Stallman’s behaviour is, once again, zero.

Autotools Mythbuster: being a foreigner is not a bad thing

This was a leftover post on my drafts’ list.. I just decided to post it as it is, even though there are a few things that are slightly out of date. Please bear with me.

Have you ever noticed that many projects ship in their tarball or, even worse, in their source repositories, files that are either empty or simply placeholder saying “look at this other file”? Most of the time these files are NEWS, ChangeLog, COPYING and INSTALL. In some corner cases, I even found packages that have files called INSTALL.real.

So what’s going on with this? Well, the problem comes from automake, and its ties to the GNU project it belongs to. The idea behind it is that the default settings of automake have to fit with the GNU projects. And GNU projects have a long list of coding styles, best practices, and policies that might sound silly (and some are) but are consistently followed by official projects.

These policies not only mandate the presence of a stable set of files (including those noted above, and a couple more), but also that the portability warnings are enabled, as the resulting Makefiles are supposed to be usable with non-GNU make implementations. So basically by default automake will mandate the presence of those files, the activation of some warnings’ classes, and that’s the reason why people do create those files even if they are not going to be used (either they are left zero sized or, worse, they get a single line referring to another file — I say worse because for zero sized files we can stop from installing them with simple checks, but for single-line references we require human intervention).

So how do you fix this? Well, it’s actually easy, you just have to pass the foreign option to the AM_INIT_AUTOMAKE macro — this way you’re telling automake that your project does not have to follow the GNU rules, which means that the files no longer have to be there and that if you want portability warnings you have to enable them explicitly. Which is very likely what you want.

Do note that the fact that the files are no longer mandatory does not mean that you can no longer use them. You’re actually suggested to keep most of them in your project, and actually install it properly. But trust me, you want to be a foreigner, in GNU land.

For details on AM_INIT_AUTOMAKE and the various automake flavours, you can see my guide which I also have to expand a little bit over the weekend.

GNU software (or, gnulib considered harmful and other stories)

The tinderbox right now seems to be having fun trying to play catch-up with changes in GNU software: GCC, Automake, glibc and of course GnuTLS. Okay it’s true that compatibility problems are not a prerogative of GNU, but there are some interesting problems with this whole game, especially for what concerns inter-dependencies.

So, there is a new C library in town, which, if we ignore the whole x32 dilemma, has support for ISO C11 as its major new feature. And what is the major change in this release? The gets() function has finally been removed. This is good, as it was a very nasty thing to use, and nobody in his sane mind would use it…

tbamd64 ~ # scanelf -qs -gets -R /bin /opt /sbin /lib /usr
gets  /opt/flexlm/bin/lmutil

Okay nevermind those who actually use it, the rest of the software shouldn’t be involved, should it? You wish. What happens is that since gnulib no longer only carries replacements for GNU extensions but also includes code that is not present on glibc itself, and extra warnings about use of deprecated features, it now comes with its own re-declaration of gets() to feature a prominent warning if it’s used. And of course, that makes it fail badly with the new gnulib.

Obviously, this has been fixed in gnulib already, since it was planned for gets() to be removed, but it takes quite a bit of time for a fix in gnulib to trickle down to the packages using it, which is one of my previous main complaints about it. Which means that Gentoo will have to patch the same code over and over again in almost all GNU software, since almost all of it uses gnulib.

Luckily for me only two packages have hit (with this problem, at least) that I’m in the herd of: GnuTLS and libtasn1 which is a dep of it. The former is fixed in version 3 which is also masked but I’m testing as well, while the latter is fixed in the current ~arch (I really don’t care about 2.16 in stable yet!), so there is nothing to patch there. The fact that GCC 4.6 itself fails to build with this version of glibc is obviously a different problem altogether, and so is the fact that we need Boost 1.50 for a number of packages to work with the new glibc/gcc combination, as 1.49 is broken with the new C library and 1.48 is broken with the new compiler.

Now to move on to something different: Automake 1.12 was released a couple of months ago and is now in ~arch, causing trouble although not as bad as it could have been. Interestingly enough, one of the things that they did change in this version was removing $(mkdir_p) as I wrote in my guide — but that seems to have been a mistake.

What should have been removed in 1.12 was the default use of AM_PROG_MKDIR_P, while the mkdir_p define should have been kept around until version 1.13. Stefano said he’s going to revert that change in automake 1.12.2, but I guess it’s better if we deal with it right away instead of waiting for 1.13 to hit us….

Of course there is a different problem with the new automake as well: GNU gettext hasn’t been updated to support the new automake versions, so using it causes deprecation warnings with 1.12 (and will fail with 1.13 if it’s not updated). And of course a number of projects are now using -Werror on automake, like it wasn’t enough trouble to use it on the source code itself.

And of course the problem with Gentoo, according to somebody, is the fact that my tinderbox bugs (those dozen a day) are filed with linked build logs instead of attached ones. Not the fact that the same somebody commits new versions of critical packages without actually doing anything to test them.

Choosing an MD5 implementation

_Yes this post might give you a sense of deja vu read but I’m trying to be more informative than ranty, if I can, over two years and a half after the original post…

Yesterday I ranted about gnulib and in particular about the hundred and some copies of the MD5 algorithm that it brings with it. Admittedly, the numbers seem more sensational than they would if you were to count the packages involved, as most of the copies come from GNU octave and another bunch come from GCC and so on so forth.

What definitely surprises me, though, is the way that people rely on said MD5 implementation, like there was no other available. I mean, I can understand GCC not wanting to add any more dependencies that could make it ABI-dependent – just look at the recent, and infamous, gmp bump – but did GNU forget that it has its own hash library ?

There are already enough MD5 implementations out there to fill a long list, so how do you choose which one to use, rather than add a new one onto your set? Well, that’s a tricky question. As far as I can tell, the most prominent factors in choosing an implementation for hash algorithms are non-technical:

Licensing is likely to be the most common issue: relying on OpenSSL’s libcrypto means that you rely on a software the license of which has been deemed enough incompatible with GPL-2 that there is a documented SSL exception that is used by projects using the GNU General Public License together with those libraries. This is the reason why libgcrypt exists, for the most part, but this continues GNU’s series of “let’s reinvent the wheel, and then reinvent it, and again”, GnuTLS (which is supposed to be a replacement to OpenSSL itself) also provides its own implementation. Great.

Availability can be a factor as well: software designed for BSD systems – such as libarchive – will make use of the libcrypto-style interface just fine; the reason is that at least FreeBSD (and I think NetBSD as well) provides those functions in its standard libraries set, making it the obvious available implementation (I wish we had something like that). Adding dependencies on a software is usually a problem, and that’s why gnulib’s used often times (being imported in the project’s sources, it adds no further dependency). So if your average system configuration already contains an acceptable implementation, then that’s what you should go for.

Given that all the interfaces are almost identical one to the other with the exception of the names and structure, and that their actual implementation has to follow the standard to make sense, the lack of many technical reasons in the prominent factors for choosing one library over another is generally understandable. So how should one proceed to choose which one to use? Well, I have some general rule of thumbs that could be useful.

The first is to use something that you already have available or you’re using already in your project: OpenSSL’s libcrypto, GLIB and libav/ffmpeg all provide an implementation of most hash functions. If you already rely on them for some of your needs, simply use their interfaces rather than looking for new ones. If there are bugs in those, or the interface is not good enough, or the performances are not as expected, try to get those fixed instead of cooking your own implementation.

If you are not using any other implementation already, then try to look at libgcrypt first; the reason why I suggest this is because it’s a common library (it is required among others by GnuPG), implementing all the main hashing algorithms, it’s LGPL so you have very few license concerns, and it doesn’t implement any other common interface, so you don’t risk symbol collision issues, as you would if you were to use a libcrypto-compatible library, and at the same time bring in anything else that used OpenSSL — I have seen that happening with Drizzle a longish time ago.

If you’re a contributor to one of the projects that use gnulib’s md5 code… please consider porting it to libgcrypt, all distributors will likely thank you for that!

I wouldn’t want to be a mirror admin

I’ve noted in my previous post that I recently built a 12TB storage server; half a terabyte has been already reserved for Gentoo’s distfiles, both as a local mirror to update my boxes without having to re-download everything, and because the tinderboxes require a lot of distfiles by definition (since they build the whole tree).

The original way I used to download all the files was to simply pass the whole list of files to emerge -Of that ran in parallel with the tinderbox process.. unfortunately this has shown to be of limited reliability; in particular due to REQUIRED_USE there are situations where a newly-introduced requirement will cause the fetch not to behave, and thus will slow down tinderboxing of new packages while the new files are fetched. Plus, if the tinderbox masked all the version of a particular package (which it can do when no version of said package builds in its environment), and I passed it to emerge -f, it wouldn’t fetch anything at all — you can’t really run a single emerge -f command, as the command line arguments limit is hit much sooner, so xargs splits it into multiple, serial calls. And as a final straw, whenever the tinderbox has to fallback to an older version of a package, it’ll have to find that distfile as well, which might not be in its cache already.

To solve all these issues and make good use of the new box that stores the data, I was given by Zac the set of infra scripts that are used to manage distfiles; in particular the mirror-dist script, written by Brian a long time ago, is the one that takes care of fetching the packages from the upstream sources and add them to the master mirror. Looking at its output I’m .. honestly scared.

Let’s begin with the whole kernel.org issue: you probably already know that their master server was compromised and all the attached services have been disabled, including the network of mirrors for both kernel- and non-kernel-related software (among others, Linux-PAM is also hosted at kernel.org). Well, this means that all the upstream fetch URIs for those packages are unusable. Due to the nature of the mirror-dist script, it was obviously not going to fetch the packages out of Gentoo mirrors, until I asked Fabio to hack around it (I’m no good with Python), and get the packages from Gentoo mirrors first, so until that point, it was unable to fetch any package released on kernel.org. Lovely.

There is a second condition that is outside of Gentoo’s control that is causing headaches to this, and probably to our mirror admins as well. It hasn’t gotten as much coverage as the whole kernel.org issue, but FSF found themselves not in compliance with the GPL, with respect to binutils, as some intermediate output was provided in the tarballs without the original sources used to generate that. So what did they decide to do? Revoke all the tarballs and replace them with a new release with new version numbers? No. Reissue them with an appended “a” noting it? No. They decided to simply rewrite all of them. Same filename, same URL, but different content. Congratulations for the headache you’re causing us!

But kernel.org projects, and GNU packages, are definitely not the only type of packages that have trouble with fetching; a number of upstream repositories no longer allows packages to be downloaded, and this causes major headaches if you don’t want to rely on the Gentoo mirrors’ network.

It has been proposed many times before to fix the SRC_URI variable for the packages that point to unfetchable sources. I even opened a wishlist bug for it to check (with HTTP’s HEAD method) whether the file is available upstream or not (and the same goes for the homepage). Unfortunately I lack the Python skills to implement this and nobody else seems to be interested in this. I would have suggested this for GSoC, but .. let’s not go there, please.

But if you have the skills, and the time, having repoman check for the availability of the files before committing would be a godsend — it would have, for instance, prevented committing one system and two system-related packages in the past months without their respective patchsets. Well, if we were to also ban direct access to mirror://gentoo/ of course.

Just accept it: truth Hurds

Okay the title is a very lame pun. But in this post I’d like to argument a bit more my reasons for not liking the Hurd project, at least in the way it is still being developed nowadays, which I announced on Identi.ca yesterday. This might sound quite strange coming from the guy who dedicated time and soul to Gentoo/FreeBSD.

First of all let’s put into context what Hurd is nowadays: it is not something viable, or usable. Twenty (20!) years after its original inception, Hurd is still nothing that you’d think of using on your desktop, or your server — nor should you, I guess. The class of operating system this belongs to is the same as Gentoo/FreeBSD, Debian’s GNU/kFreeBSD , Haiku, Plan9 and so on, a toy project. Or if you want to make it sound less childish, a research project, but I prefer the shorter version.

But while there are so many toy projects operating systems, I’m singling out Hurd, and there two main reasons for my feeling; they can be considered mostly personal, non-technical opinion, but I’ll stand by them.

First of all, most other toy systems have given us steady improvements in different areas; take Plan9 for instance: ten years older than Hurd, but recently Linux gained access to paravirtualized filesystems, based on what? On the Plan9 protocols. Good research going — even though it does seem tremendously silly when you look into it for the first time. And even though I was sceptic the first time I looked into it, GNU/kFreeBSD has probably made glibc a bit more … malleable.

But most importantly is that the whole Hurd project at the moment does not have any real technical reason to exist, it only has one huge symbolic value for the GNU project, beginning with the idea that “Linux is not the Free operating system”.. which I could accept if it wasn’t coming from the project sponsored by FSF. The same FSF that insists that you should not use any proprietary operating system, that you should only and always use Free software and so on so forth.

Is Hurd the example of Free Software people should use? Do they insist on their argument even when it is totally, technically, unsound? I’m afraid some of the people in the FSF do. Luckily, FSF is not just those, and there are numbers of reasonable, hard-working and capable people. Which is why even I have signed copyright assignments to FSF with a bit of rant attached), and why I try to contribute to GnuPG when I can (given I use it).

Once again, though, what’s the problem if a bunch of elitist developers feel like working on a toy system? It really isn’t something new; heck Plan9 is, as far as I can tell, mostly developed for that. With a few difference: most of the people I saw involved with Plan9 are also involved in the suckless projects (and I rarely, if at all, agree with the premises of such projects), and they definitely are not very interested in making more users for any software at all, so their approach is well suited to their goals, not so for the GNU people, but oh well.

The problem I have, with actually any toy project, is with the people who keep insisting to find philosophical reasons to show others why their project is really, very, so much important. It happens (awfully often on Identi.ca) with both Plan9 but, more often lately, with Hurd. And when I do show my disagreement, I usually end up flooded with defences of said projects (“they don’t bother you”, “everybody should keep using what they prefer”, … sure of course — then why can’t I voice my personal opinion?).

This brings me with categorizing most of the people involved in toy project (or actually, any project — with mainstream projects it is a bit more shady to go from one category to the other) in three categories: the silent doers, the vocal doers, and the advocates.

For the silent doers, those who know they are working on a toy project and have no expectancy for people to consider it “important for the greater good”, I have fondness: you go with it and try to get something good out of it — I have done something like that with G/FreeBSD: Gentoo has had libarchive (bsdtar) from way before it went mainstream as a dependency of GNOME and KDE.

I’m a bit more polemic with the vocal doers: sure, you’re entitled to advertise your choice, no way I’m going to argue against it; but I’ll also not refrain from stating my disagreement. That shouldn’t be a problem, no? And I’m sorry, but I’m also not going to generally be convinced by your reasons to keep developing. It’s not a lack of respect, and I’m sorry if you feel this way, but… I don’t really care. If you want to show me something, show me technical reason why your work could be important to me, or to others, but technical.

But please, spare me the advocates. They talk just too much (after a passing reference to Hurd I get three, continued messages, trying to argue for it? I’m going to be a bit disappointed — I reply and I get another three? I’m seriously cranky), and of the wrong arguments. I really don’t care about the philosophy of a subproject. I subscribe to the basic philosophy of Free and Open Source Software, and I maintain that it can be technically superior if the project accepts that proprietary software can (and usually enough does) have better technical aspects. Survival of the fittest, for me, is happening only in technical terms.

Clear enough now?

Autotools Mythbuster: A practical case of TMT (Too Many Tests)

I have written already about the fact that using autoscan is simply a bad idea not too long ago. On the other hand, today I found one very practical case where using (an old version of) autoscan have create a very practical problem. While this post is not going to talk about the pambase problems there is a connection to my previous posts: it is related to the cross-compilation of Linux-PAM.

It is an unfortunately known problem that Linux-PAM ebuild fails cross-compilation — and there are a number of workaround that have never been applied in the ebuilds. The reason are relatively simple: I have insisted for someone else who had the issue at hand to send them upstream. Finally somebody did, and Thorsten fixed the issues with the famous latest release — or so is theory. A quick check shows me that the latest PAM version is also not working as intended.

Looking around the build log it seems like the problem is that the configure script for Linux-PAM, using the original AC_PROG_LEX macro, is unable to identify the correct (f)lex library to link against. Again, the problem is obvious: the cross-building wrappers that we provide in the crossdev package are causing dependencies present in DEPEND but not RDEPEND to be merged just on the root file system. Portage allows us to set the behaviour to merge them instead on the cross-root; but even that is wrong since we need flex to be present both as a (CBUILD) tool, and as a (CHOST) library. I’ve asked Zac to provide a “both” solution, we’ll see how we go from there.

Unfortunately a further problem happens when you try to cross-compile flex: it fails with undefined references to the rpl_malloc symbol. You can look it up and you’ll see that it’s definitely not a problem limited to flex. I know what I’m dealing with when finding these mistakes, but I guess it doesn’t hurt to explain them a bit further.

The rpl_malloc and rpl_realloc are two replacement symbols, #define’d during the configure phase by the AC_FUNC_MALLOC autoconf macro. They are used to replace the standard functions with two custom ones that can be conditioned; the fact that they are left dangling is, as I’ll show in a moment, pretty much a signal of overtesting.

Rather than simply checking for the presence of the malloc() function (can you really expect the function to be missing on any non-embedded system at all?), the AC_FUNC_MALLOC macro (together with its sibling AC_FUNC_REALLOC) checks for the presence of a glibc-compatible malloc() function. That “glibc-compatible” note simply means a function that will not return NULL when passed a length argument of 0 (which is the behaviour found in glibc and a number of other systems). It is a corner-case condition and most of the software I know is not relying at all on this happening, but sometimes it has been useful to test for, otherwise the macro wouldn’t be there.

Of course the sheer fact that nobody implemented the compatibility replacement functions in the flex source tree should make it safe to assume that there is no need for the behaviour to be present.

Looking at the original configure code really tells more of a story:

# Checks for typedefs, structures, and compiler characteristics.

AC_HEADER_STDBOOL
AC_C_CONST
AC_TYPE_SIZE_T

# Checks for library functions.

AC_FUNC_FORK
AC_FUNC_MALLOC
AC_FUNC_REALLOC
AC_CHECK_FUNCS([dup2 isascii memset pow regcomp setlocale strchr strtol])

The two comments are the usual ones that you’d find in a configure.in script created by autoscan; it’s also one of the few cases where you actually find a check for size_t, as most software assumes its presence anyway. More importantly, if you look at the long list of AC_CHECK_FUNCS macro call arguments, and then compare with the actual source code of the project, you can understand that the boilerplate checks are there, but their results are never checked for. That’s true for all the functions in there.

What do we make of it? Well, first of all, it shows that at least part of the autotools-based buildsystem in flex is not really well thought off (and you can add to that some quite idiotic stuff in the Makefile.am to express object file dependencies, which then required a patch that produced half-broken results). But it also shows that in all likeliness, the check for malloc() is there just because, and not because there is need for the malloc(0) behaviour.

A quick fix, consisting of removing useless checks, and rebuilding autotools with more modern autotools versions, and you have a perfectly cross-compilable, workaround-free flex ebuilds. Voilà!

So why am I blogging about this at all? Well, I’ll be updating the Guide later on today; in the mean time I wanted to let you know about this trickery because I sincerely have a problem with having to add tons of workaround for cross-building: it’s time to tackle them down, and quite a lot of those are related to this stupid macro usage, so if you find one, please remember this post and get to fix it properly!

Welcome to last century

This is going to be a rant; a particular rant directed toward Free Software Foundation. If you’re one of those self-defined advocates who pretend that Stallman’s smell is worth to be made an eau-de-toilette, then you won’t like my post; I won’t care and I won’t care about your comments. So you’re warned.

I have said before that I have decided to accept Werner’s offer of helping him out with GnuPG by signing the FSF copyright assignment forms — even though their value in Europe is dubious at least. I’m not going to complain about the copyright assignment idea itself; I’m definitely not a lawyer, I barely can deal with the paperwork I deal with on my daily job.

I started having doubts about the whole handling of the copyright assignment to FSF when I was given the first templates by Werner: a text file to mail, including ASCII-reduced name and a home address. I have said many times that in the 21st century, still requiring people around the globe to provide ASCII-reduced names only is at a minimum silly. We’re in a world that is using a number of languages and scripts; and while I agree we should provide a more or less common way to pronounce our names, requiring people to limit their name to ASCII, especially in official contexts. But so it is.

Turns out that the reason why they ask for your home address is not simply to write it down properly in the database, but because they send you snail mail forms to sign and send back. Okay now that starts to feel strange because I have signed quite a few work contracts before, and but for one of them, I both received and sent them as PDF forms. I also signed (a long time ago) a SCA form for the OpenJDK project to Sun; even in that case, emailed scanned documents were just enough.

While strange I expected to follow the usual process: I’d receive two copies of each form, pre-signed by the FSF representative, I’d keep one copy of each and send back the other with my signature on them. Today I received the envelope; there was only one copy of the forms; my name was misspelt (even though I used the ASCII-limited spelling, they dropped the accent!); the forms weren’t pre-signed, just a print out of something that they could most likely have sent me over as PDF, in a much more environmental-friendly way. And one more respectful of the developers who actually ask to have their copyright assigned to the FSF.

Why do I say that? Well, first of all, because the assignment forms make me declare I’m signing off the copyright for “$1 or equivalent goods”… I guess they are referring to the FSF sticker they sent over with the envelope — together with an advertisement for the FSF membership. Okay so this is likely because signing away the rights for nothing is not going to stand up quite well in court, and a sticker is as good as anything when “nothing” is the unusable default. Why should this make me upset?

Well, to begin with, because sending back the signed form is going to cost me more than the nominal $1. But it’s not just that; the paper upon which the forms are printed is a quite high-quality paper. Not just higher than the usual copier paper I use for my own consumption, but also quite higher than what most of the official communications I receive here in Italy. Why using such paper at all?

To be honest, Donnie provided a possible reason: it’s a legal paper so it should be as durable as possible; high-quality paper tends to endure time much better than standard copier paper. On the other hand, if that was the idea, then I guess they should also replace their printer — if they can do that, given that most likely any printer that they could buy has a closed-source firmware on it and they can’t use it. That’s because the two printed forms were put one over the other and then mailed; with the result that part of the text of the topmost was transferred to the one under it. They are still both legible, but gives a hard shake to the “preservation” theory.

Really, even if they need the original signature, why they couldn’t give me a PDF, so I could simply send it to them in two copies, and then they’d send me the counter-signed form with the sticker? Wouldn’t that save us one whole snail-mail trip, a lot of time, and also a bit of paper?