There is one thing I noticed working on my linking collision script. While most of the software properly creates subdirectories to put plugins in, so that they don’t clash with others and it does not pollute the LDPATH space, there are quite a few packages that don’t do that at all and install their plugins straight into the libdir.

Not only that, some packages install static archive versions of their own plugins, with no good reason since they are never linked in statically, but always dlopen’d.

Please don’t pollute LDPATH, if you can, make sure the plugins are installed in “pkglibdir” (that is /usr/lib/packagename) and make sure that they only install the shared object file, and eventually the libtool archive if the software uses libltdl to load them. The static archive is almost always unneeded and just a waste of time.

Also please remember that if you install core libraries in a path outside of the standard libdir (which is very good if the libraries are not to be linked against!), you should probably make sure that there is a proper runpath in the executables. What runpath does is to tell the linker to look for libraries in a path that is otherwise not accessible through the standard configuration files (/etc/ld.so.conf). A common mistake here is to install an env file that makes LDPATH (or even worse LD_LIBRARY_PATH) to the directory where the core internal libraries are installed.

While this works, it does not make much difference than having it in the standard library path: both the runtime linker and the link editor will use the path from the configuration file anyway, so the library is not going to be hidden like you’d want it to for a private library. On the other hand, if just the executable provides their own runpath, then the two linkers will ignore the libraries altogether.

So please, be careful with what you push in the library path, okay?

#if defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN)
# error Fix asm/byteorder.h to define one endianness
#endif

I’ve already written about some of the differences between my and Patrick’s tinderboxes, one of which is that my tinderbox does not only install one package, but tries to install all of them at once. This is a necessity for me to have enough material to work on with my library collisions script, and still have so many side effects that makes it funny to work with.

The first problem is that sometimes packages don’t get merged together because of file collisions, which most of the time are caused by packages that install commands with name too generic, and some other times because they regenerate files that should not be present in the final image (like iconv’s charset.alias that gets generated on Gentoo/FreeBSD systems with no good reason at all).

The second problem derives from the way the first problem is handled. When two packages install a file with the same name, rather than renaming one of them or both, it’s customary to actually “fix” the problem by adding blockers to each of the two packages so that they cannot get installed together. While it’s certainly better to have it expressed that way rather than having the merge to fail after the compilation and install phases, it’s not really a solution since it still disallows having the two packages on the same system. While this is acceptable for packages like the different GhostScript implementations that apply for the same task, this is not much of a solution when the packages are entirely independent one from the other and have very different tasks.

I also have found one particular package (pnet) which had a very funky solution to the collision between that and boehm-gc, considering that it was installing a private copy of that. Obviously this was not the proper fix by a mile’s look.

If you have two packages that block each other you have a few different ways to deal with that; if they provide the same function, you might as well install them with a prefix and then write an eselect module to choose between one or the other (which is something that ghostscript could very well be doing); if they only install executables with generic name, they might be changed to prefix the command name with the package name. But sometimes these commands are not to be used by the users at all, and are rather internal commands used by the scripts for processing; in those cases, it would be a nice idea to make those get into /usr/libexec/$PN/ so that they are taken out of the users’ path, and won’t collide one with the other.

While dealing with packages that install colliding files is not so easy, there is need for developers to deal with them in a less “works for me” way, and think more of the general picture, as it is, there are enough packages in the tree that blocks each other with no real good reason, and this is upsetting.

So it’s Christmas day, and I’m skimming through the 32+ MB of logs generated by my elven script and I found some nice nuggets:

Symbol getopt_long@@ (32-bit UNIX System V ABI Intel 80386) present 35 times
  /usr/bin/graph
  /usr/bin/ebzipinfo
  /usr/bin/spline
  /usr/bin/double
  /usr/bin/uupick
  /usr/bin/autotrace
  /usr/bin/uustat
  /usr/sbin/ndtpd
  /usr/bin/ode
  /usr/sbin/ndtpcheck
  /usr/bin/ebrefile
  /usr/bin/uucp
  /usr/sbin/ndtpcontrol
  /usr/bin/uulog
  /usr/sbin/uuxqt
  /usr/bin/ebzip
  /usr/bin/faad
  /usr/bin/lha
  /usr/lib/libsox.so.1.0.0
  /usr/sbin/uucico
  /usr/bin/ebinfo
  /usr/sbin/uuconv
  /usr/bin/plot
  /usr/bin/tek2plot
  /usr/lib/libc.so.5
  /usr/bin/uuname
  /usr/bin/uux
  /usr/bin/ebstopcode
  /usr/bin/stklos
  /usr/bin/cu
  /usr/bin/plotfont
  /usr/bin/ebfont
  /usr/bin/ebunzip
  /usr/bin/pic2plot
  /usr/sbin/uuchk
Symbol strncasecmp@@ (32-bit UNIX System V ABI Intel 80386) present 5 times
  /usr/bin/xpilots
  /usr/bin/gargoyle-agility
  /usr/lib/libc.so.5
  /usr/bin/xedit
  /usr/bin/xpilot
Symbol strnlen@@ (32-bit UNIX System V ABI Intel 80386) present 5 times
  /usr/bin/tarsync
  /usr/lib/libCw.so.1.0.0
  /usr/lib/libmba.so.0.9.1
  /usr/lib/python2.5/site-packages/numarray/_chararray.so
  /usr/bin/linksys-tftp
Symbol stricmp@@ (32-bit UNIX System V ABI Intel 80386) present 5 times
  /usr/bin/qemacs
  /usr/lib/libraidutil.so.0.0.0
  /usr/lib/openbabel/2.2.0/inchiformat.so
  /usr/lib/libxerces-c-3.0.so
  /usr/lib/libIL.so.1.0.0

Now if you ignore the references to the old compatibility libc.so.5 you can still find that there are quite a few programs that reinvent the wheel, reimplementing some functions that the C library already provides. Now, this would be fine and dandy if the implementation was subtly different, or was done with some particular purpose in mind, like glib’s functions, but I really can’t find the reason for the situation above to happen.

These are usually smaller functions, but still there is no reason for them to be present since anyway it’s more than likely that most of their use is replaced away by the compiler itself; more interesting is their presence in shared objects, since that would interpose around other calls, although this most likely won’t happen on glibc based systems since they provide versioned symbols which wouldn’t then interpose by default. That’s still a problem for *BSD systems though.

This has a much lower priority in my list than identifying all libraries bundled by various packages (even when they cannot be fixed, because they are proprietary or something else), because these are unlikely to turn out being security issues. On the other hand, the idea of doing such pointless duplication of common functions might as well caus security issues to be hidden, for instance if a package was to reimplement mktemp, then it would most likely be a problem.

Anyway for those interested to find out what’s duplicating code in their system, the new hit parade, derived directly from the Bug shows SQLite3 trying to climb up the ladder, together with boehm-gc. Why people can’t understand that there are libraries in the system already?

So after almost an year, I returned working on the library collision detection that comes with ruby-elf. I now have a much more powerful system to work on, but I also have a much bigger set of samples to scan, in my tinderbox.

Beside a few issues that I’ve had to taken care of, I’ve now got a database that contains a huge amount of data to process and useful information to derive. Just to give some statistics, the script harvested 24602 ELF files, counting 2713395 symbols, of which 326399 are duplicate between objects. These statistics have already counted out all the suppressed symbols known up to now, but obviously there are more yet unknown.

To stick with statistics for now, rather than actual results, it’s interesting to know that about 1365671 C++ ABI symbols, I sincerely wonder how many of these should be hidden instead.

On a more interesting note, Samba confirms itself sub-optimal by now having yet a convenience library for its shared functions, and copying over the symbols between the various pieces of the puzzle, included six different Python modules, whose total size would probably be cut in half I guess.

Sticking with the Python side, there is one damn issue that is really upsetting me: about thirty different packages link the Python interpreter statically rather than dynamically, resulting in around 30 different copies of Python itself in the full of Portage. Nasty. The problem is that the ebuild installs the shared and static libraries in two different paths, one of which being private “config” path for Python. The packages picking that up will explicitly request it at link time, causing Python to be linked in statically rather than dynamically:

Symbol PyBaseString_Type@@ (32-bit UNIX System V ABI Intel 80386) present 30 times
  /usr/games/bin/diameter
  /usr/bin/vim
  /usr/bin/gedit
  /usr/lib/root/libPyROOT.so.5.22
  /usr/lib/python2.5/site-packages/opencv/_highgui.so
  /usr/lib/libpython2.5.so.1.0
  /usr/bin/eog
  /usr/games/lib/mcl/plugins/python.so
  /usr/sbin/bextract
  /usr/bin/zapping
  /usr/lib/python2.5/site-packages/opencv/_cv.so
  /usr/bin/gvim
  /usr/bin/gwp
  /usr/bin/cooledit
  /usr/lib/planner/plugins/libpython-plugin.so
  /usr/sbin/bacula-fd
  /usr/sbin/bacula-sd
  /usr/lib/dia/libpython_plugin.so
  /usr/lib/xchat/plugins/python.so
  /usr/lib/xchat-gnome/plugins/python.so
  /usr/sbin/bacula-dir
  /usr/lib/gnumeric/1.8.3/plugins/python-loader/python_loader.so
  /usr/games/bin/adonthell
  /usr/games/bin/kiki
  /usr/lib/libgnt.so.0.0.0
  /usr/bin/epiphany
  /usr/lib/python2.5/site-packages/_lcms.so
  /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/Inline/Python/Python.so
  /usr/lib/apache2/modules/mod_wsgi.so
  /usr/lib/apache2/modules/mod_python.so

As you can see this includes two Apache modules, and quit a few pieces of GNOME. This is quite nasty. My suggestion until this is sorted out is not to enable python USE flag unless you really really really need it. The nastiest bit is that since there has been a Python vulnerability if you didn’t rebuild these packages after the bump, you’ll have them using a vulnerable interpreter, still. Do I really have to spell out how bad that is for stuff like Apache modules?

Short preamble: I’m in a very depressed mood, like I haven’t been in month; this is very bad for my health but usually means I can focus on things much better, so you might actually find out I’m doing more than usual. Of course there is also to count in that I’m working during holidays so it’s not going to be all nice at all, even counting my depression off.

As I’ve written, I don’t trust closed-source software even the slightest even though it does not really mean that free software is much better, process-wise, dealing with bundled libraries (like the bundled libs bug shows), with free software, or at least open-source software, there is the chance to check the sources out to fix the eventual issues.

This means that I won’t be using closed source software where security is a major concern, but since sometimes I have to use closed-source software, like Skype, or Sun’s compiler, it’s obvious that I have to find a compromise so I can still use them and yet feel reasonably safe. This is what is usually called having a mitigation strategy.

One of the most complex and well known mitigation strategies is of course SElinux, which makes a Linux system more like an APC than a computer. But such a system is probably safe to consider overkill for most systems, especially power user desktop systems.

Since this is, as I said, overkill, I’m more prone to look at smaller strategies, one of which I already discussed about: pam_mktemp . This module allows to create per-user private directories that make it much harder to exploit insecure temporary files vulnerabilities. Which is very nice since this seems to be a very common class of vulnerabilities, and my data shows that there is way too much software that still uses insecure functions to create temporary files, closed and open source alike.

Unfortunately, as you can read in my earlier blog post, this is not automatically a way out of the problem. The start-stop-daemon command from OpenRC plays nice with this just in the last release, and even with that, there are problems. The first problem is that the way pam_mktemp works, there is a need for the software calling PAM to open the session to properly set up the environment with its changes (which is what s-s-d lacked in previous versions). This causes for instance the gnome-keyring daemon to start with the wrong temporary directory when started by the PAM session chain. Even though pam_mktemp is invoked before the daemon, by the time it’s started the TMPDIR variable is not set in the environment. The reason for this is that the variable should not be changed if the session chain aborts the login.

The second problem is that not all software supports TMPDIR properly; Emacs has been fixed recently and now the emacs daemon starts up properly, but other software ignores TMPDIR altogether. VirtualBox (of which I still have things to say beside this) does not respect it for instance, which means that the module wouldn’t have spared you from the recent vulnerability that involved the software.

The third problem is that sometimes software expects TMPDIR to be world-readable, which is a bad assumption; Samba does this, and since s-s-d is now fixed, it now fails to work on my system. I still haven’t found out whether the PAM session chain was called at that point, and it’s just duplicating the problem with s-s-d with a different symptom, or if it fails to call it entirely. In either case, it’s a thing that has to be fixed to make sure that mitigation strategies like this one get in the default spirit of users.

But again this is just one part of the problem, and one part of mitigation. Other problems relate to the way we run some of the services, a lot of which still run as root rather than under a unprivileged user; while the git-daemon issue is now solved and the default install does not run as root any longer, there are more daemons that have the same problems.

Just as an example, I noticed that the iSCSI daemon ietd still runs under root, and I’ve added that to the list of software I have to check to see if I can improve it. Similarly, the init script for mpd does not use s-s-d to switch user but leaves it to mpd itself, spawning it by default with unneeded root privileges, and additionally not allowing pam_mktemp to create a new temporary directory for the mpd user (I have to spend some time on that since I’d also like to provide an alternative init script with multiplexing, which would then allow to run multiple mpds for different users, and in my case to just have the single mpd running as my own user rather than a different user entirely).

At any rate, I’m going to continue my best to make sure that secure defaults are in place in Gentoo, and that further mitigation strategies can be made available so that the users forced to use proprietary closed-source software don’t need to just accept whatever comes their way. Please join my efforts, if you can, by checking which software ignores TMPDIR and asking nicely upstream to fix the issue.

... you can make your own, or try at least.

I maintain in portage a little ebuild for uif2iso; as you probably already know, the foo2iso tools are used t convert various type of proprietary disk images from Windows proprietary software into ISO9660 images that can be used under Linux. Quite obviously, making unit testing out of such a tool is pointless, but regression testing at tool level might actually work. Unfortunately for obvious reasons upstream does not ship testing data.

Not exactly happy with this, I started considering what solution I had, and thus my decision: if upstream does not ship with any testsuite, I’ll make one myself. The good thing with ebuilds is that you can write what you want for the test in src_test. I finally decided to build an UIF image using MagicISO on my Windows XP vbox, download it together with the MD5 digest of the files I’d put in it conditionally to the test USE flag, and during the test phase convert it to ISO, extract the files, and check that the MD5 digest is correct.

Easier said than done.

To start with I had some problem deciding what to put on the image; of course I could use some random data, but I thought that at that point I could at least make it funny for people to download the test data, if they wanted to look at it. My choice fell on just finding some Creative Commons-licensed music and use a track from that. After some looking around, my choice went to the first track of Break Rise Blowing by Countdown on Jamendo.

Yes I don’t like Flash either but this was worth it, sorry.

Now, the first track is not too big so it’s not a significant overhead to download the test data, but there is another point here: MagicISO has three types of algorithms used: default, best compression and best speed; most likely they are three compression levels in lzma or something along those lines, but just to be safe I’d just put all three of those to the test. The resulting file with the three UIF images and the MD5 checksums was less than 9MB, so an acceptable size.

At that point, I started writing the small testsuite, and the problem started: uif2iso always returns 1 at exit, which means you can’t use || die or it would always die. Okay good enough, just check that the file was created. Then you have to take the files out, nothing is that easy when you got libarchive that can extract ISO files like they were tarballs; just add that as a dependency with the test USE flag enabled, a bit of overhead but at least I can easily extract the data to test.

It seems instead that the ISO file produced by uif2iso is going to be a test for libarchive instead, since the latest release fails to extract it. I mailed Tim and I hope he can fix it up for the next release (Tim is fantastic with this, when 2.5.902a was released, I ended up finding a crasher on a Portage-generated binpkg, I just had to mail it to him, and in the next release it was fixed!). The ISO file itself seems fine, since loop-mounting it works just fine. The problem is that I know no other tool that can extract ISO images quickly and without having to command it file by file (iso-read from libcdio can do that, it’s just too boring); if somebody has suggestions I’m open to them.

This is the fun that comes out of writing your own test cases I guess, but on the other hand I think it’s probably a good idea to keep the problematic archives around, if they have no problems with licenses (Gentoo binpkgs might, since they are built from sources and you’d have to distribute the sources with the binaries, which is why I wanted some Creative Commons licensed content for the images), since that allows you to test stuff that broke before to ensure it never breaks again. Which is probably the best part of unit, integration and system testing: you take a bug that was introduced in the past, fix it and write a test so that, if it is ever reintroduced it would be caught by the tests rather than by the users again.

Has anybody said FATE ?

In my post regarding remote debugging (which I promised to finish with a second part, I just didn’t have time to test a couple of things), I’ve suggested the idea I’d like to have some kind of package splitting in Portage, to create multiple binary packages out of a single source package and ebuild, similarly to what distributions based on RPM or deb do (let’s call them RedHat and Debian, for historical reasons).

Now, I want to make sure nobody misunderstand me: I don’t intend to propose this as a way of removing the fine-grained control USE flags give us; I sincerely love that; and I also love not having to worry about installing -dev and -devel packages on my machines to be able to build software, even outside of the package manager’s control. I really find these two are strengths of Gentoo, rather than weakness, so I have no intention to fiddle with them. On the other hand, I think there are enough uses that would allow for an even finer control on binpkg level.

I’ve already given a scenario in my post about remote server debugging, but let’s try to show something different, something I’ve actually been thinking about myself. Yes I know this is a very vested interest for me, but I also think this is what makes Free Software great most of the time; we’re not solutions looking for problem, but usually solutions to problem one had at least at one point in time. Just like my writing support for NFS export on the HFS+ filesystem in Linux.

So let me try to introduce the scenario I’ve been thinking about. As it happens, I tend to a series of boxes in many offices for friends and friends of friends in my spare time, on the side. It’s not too bad, it does not pay my bills, but it does pay for some side things, which is good. Now since these offices usually use Windows, even though I obviously install Firefox as the second step after doing the system updates, it’s not unlikely that every other time I go there I have to clean up the systems. I think there are computers I’ve wiped up and reinstalled a few times already. I’ve now been thinking about setting up some firewalls based on Snort or similar. Since I am who I am, these would end up being Gentoo-based (as a side note, I’m tempted to set it up here so I can finally stop having trouble with Vista-based laptops that mess up my network). Oh and please, I know it might sound very stupid considering there are solutions good for this already, but considering how much I’m paid and the amount of money they are ready to spend (read: near to none), I would find it nicer to be paid to work on some Gentoo-related stuff than be paid to just look up and learn how to use already made equipment. Of course if you have suggestion, they are welcome anyway.

So anyway, in this situation I’d have to set up boxes that would usually feel very embedded-like: a common basis, the minimum maintenance possible, upgrades when needed. Donnie’s idea of using remote package fetching and instant deletion is not that good for this because it still requires a huge pipe to shove the data around; not only I don’t have so much upload bandwidth to employ for binpkging a whole system with debug information, it would also be a hit that most of my users wouldn’t like to have, on their bandwidth (if they want to use BitTorrent or look up p0rn from the office is not my problem).

With this in mind, I’d sincerely find it much nicer to be able to split packages, Portage-side, into multiple binary packages that can be fetched, synced, or whatever else, independently, as needed. As I proposed, a binpkg for the debug information files, but also a binpkg for documentation (including man and info pages), one for development data (headers, pkg-config), and maybe one for the prepared sources, that I want to talk about in a moment. With an environment variable it shouldn’t be much of a problem to choose which ones of these split binary packages to install in the system without explicit request; with a default including all of them but the debug informations and the sources. This would also replace the INSTALL_MASK approach as well as noinfo, noman, nodoc FEATURES. It wouldn’t be like a logical split of a package in multiple entries in the system, but rather a way to choose which parts to install, complementary to USE flags.

As for packaging the sources as I said above, there are two interesting points to be made for that, or maybe three. The first problem is that when you have to distribute a system based on Gentoo, you cannot just provide the binaries; since many packages are released under the GNU GPL version 2, even if you didn’t change the sources at all you should be distributing them alongside the binaries; and we modify a lot of sources. For license compliance we should also provide the full set of sources from which the code is derived. This is especially tricky for embedded systems. By packaging up the sources used for the builds, embedded distributors would be able to just provide all the -src subpackages as the full sources for the system.

The second point is that you can use the source packages for debugging too. Since there is, as far as I know,no way to fully embed the source code of software in the debug section of the files generated from that, the only way for GDB to display the source code lines during debugging is having the source files used for build available during the debugging session. This can easily be done by packaging up the sources and installing them in, say, /usr/src/portage/ when they are needed, from a subpackage.

A final point would be that by packaging sources in sub-packages, and distributing them, we could be reducing the overhead for users to unpack (maybe with uncommon package formats) and prepare sources (maybe with lots of patches and autotools rebuilding). Let’s say that every 6 hours a server produces md5-based source subpackages for all the ebuilds of the tree, or a subset of them. Users would then use those sources primarily, but still having the ebuilds to provide all the data and workflow so that the original untouched source would be enough to compile the package. Of course this would then require us to express dependencies on a per-phase basis, since then autotools wouldn’t be required at buildtime at all.

Okay I guess I’m really dreaming lately, but I think that throwing around some ideas is still better than not doing so, they can always be picked up and worked on; sometimes it worked.

I’ve already written something about automation for Gentoo bug search, but I think sometimes it’s not easy to understand that just using a huge tinderbox, even distributed, is not going to help much to make sure that software works. The problem is that sometimes, even if software builds fine, it’s just going to break at runtime, and even though tests help, when they are handled properly, they are far from complete solutions.

Problems like the one described in the post above for hfsplusutils are just impossible to gather at build time without running the tests on sample data (which reminds me of the uif2iso problem but this can get even more subtle: while it’s true that most --as-needed failure happen at buildtime, there are quite a few that will not hit until runtime; one such cases happened to me with libcompizconfig, compizconfig-python and fusion-icon: this last one software wouldn’t start because Python failed to load the second, because the first one wasn’t linking to libX11.

Now of course this could have been found if either libcompizconfig or compizconfig-python had a testsuite, but since I already said that running a tinderbox run with testsuite is probably not something that I would like to do on a daily basis.

Especially for old software, there are problems like endianness issues, 64-bit arches and PIC code that are almost impossible to figure out at buildtime, and that need to be checked during software use. But it’s not just that. For binary packages, especially those of proprietary software, there usually isn’t a testsuite, for this reason, their executables are rarely checked at runtime for consistency. This becomes a problem because sometimes you have software that links against old versions of libraries. This is the same reason why adding VirtualBox 2.1.0 binary package in the tree is going to take a while for Alessio: it uses the old ABI of libcap, which will require resurrecting, and maintaining, an old verison of libcap just for that. (I have a few more issues to talk about regarding the new VirtualBox release but I’ll get to that in another moment).

And yet, the reasons why neither my nor Patrick’s tinderbox can be a replacement for a more throughout approach to packages testing are not finished here. But before proceeding to more, I have to make a distinction between the different approaches me and Patrick took. Patrick’s tinderbox removes all the superfluous packages from the system when installing a new one, which is very good to test for missing dependencies; my method instead iterates over each of the packages in the tree and installs them one by one in the system, filling up the space, which can easily ignore missing dependencies but provides more interesting results regarding iteration of particular ebuilds.

So while my method glosses over broken runtime and buildtime dependencies, like pkg-config not depended upon and similar, Patrick’s method is not going to hit problems like dev-scheme/chicken breaking most of the Mono packages (that would pick up /usr/bin/csc as the C# compiler rather than mcsc), or collisions between unrelated packages.

This means that either one of the two tinderboxes is just not enough to find all the issues, and even the two of them together won’t be enough. Even adding AutoTua to that, it’s just not going to cut it. As Jeremy said on a blog post of mine, we need humans (developers and users) to report issues. I start to feel we also have a need for some real numbers of how many users use packages. Yes I know that’s going to be a popularity contest, and it’s likely that there will be people that would just go on to submit fake results, but even for tree cleaning, it’s important to know whether packages don’t have bugs failed against them because they are good, or just because nobody has used them in so much time.

Oh and so that you know, I currently have little less than 1500 bugs open that I reported (and over 3000 bugs that I reported since I started contributing to Gentoo), and all of them are reported by hand, there are still issues that force me not to use scripts like pybugz. I’ll see to write about them, maybe Zac can see to find a solution to those, like he has been doing quite a while lately for me. Thanks Zac!

There are many different but common misconceptions about debugging that are spread among those users who, having never learnt a programming language, cannot understand properly the difference between debug code and debug information. Some of these misconception causes misunderstanding with Gentoo’s way of handling the two things as separate and distinct feature of a software.

First of all, let’s start with what the -g, -ggdb and -g3 options are supposed to do. These three flags are used to add debug information, in form of either stabs or DWARF data, depending on the architecture, to the compiled files, may they be object files, shared objects or final executables. This data is used by debuggers like gdb to provide a meaningful backtrace, and is added to some special sections of the file. The difference between a file that is built with these options and a file that is built without those can be removed by using the strip command, since they don’t go touching the actual executable code or data entries. The only software that is susceptible to break with -g3 is the dynamic loader, and even that I’m not sure why.

The various level of debugging information are used to provide various level of backtracing, starting from giving the name of the functions called, and arriving to have the line numbers, the source lines, and macro expansion (which is especially useful when debugging stuff like scanelf, that is composed of a huge amount of macro-based meta-functions. Even when the full debug information is enabled in files, it’s not hindering performance, if not during the first scan and read of the ELF files, since the loader does not load the debug information by default, they are not in sections that are allocated in memory at runtime at all. (This is something you can easily understand once you know the difference between allocated and non-allocated ELF segments).

Debug code, instead, means adding special instruction in the executable code for debugging purposes; the most simple example is the assert() macro used to make sure that unexpected code paths are not taken; although this is often misused as a way to enact limitations in functions, the original idea behind assertions was to make the program die in a way easy to debug when a condition supposed to be always true was instead false. These checks wouldn’t be needed during standard usage, or should be handled gracefully if they indeed happen, so the assertions would just need to be taken out of the built code at that point, which is exactly what -DNDEBUG does. (On an autotools-related note, the AC_HEADER_ASSERT autoconf macro not only checks for the correct header, but also provides an easy to use --disable-assert option for the configure script to disable assertions altogether). Unfortunately nowadays assertions are often used to check the behaviour of code at runtime, even though an error would then cause the abort of the software, which makes it more difficult to just disable them altogether for final users.

But debug code can be much more complex, and might slow down operation a lot; it might be logging data extensively, it might fill the terminal with pointless information, it might check every and each step during processing. This type of code must certainly not be enabled for users’ runtime or their work would be greatly hindered.

Now that the distinctions are made, you can see why splitdebug/strip FEATURES are distinct from the debug USE flag. If you want to just get a backtrace for a crash you got during execution, you need debug information, you don’t need debug code; if possible, debug code might actually stop the software from crashing; as could reducing the optimisation flags. For users, it’s more than likely than the debug USE flag wouldn’t be useful at all; for developers who know what to do, this fine-grained control is most likely the best option they have.

So please next time you think about mixing the debug USE flag and the splitdebug/strip FEATURES in the same idea, try to think of what exactly you want to achieve. And no, disabling -O2 is not always a good idea to have a meaningful backtrace, especially since as I said, -O0 might make stuff not build, so you shouldn’t be ready to just enable that unconditionally to get a backtrace for a bug report.

If you follow my blog since I started writing, you might remember my post about imported libraries from last January and the follow up related to OpenOffice you might know I did start some major work toward identifying imported libraries using my collision detection script and that I postponed till I had enough horsepower to run the script again.

And this is another reason why I’m working on installing as many packages as possible on my testing chroot. Now, of course the primary reason was to test for --as-needed support, but I’ve also been busy checking build with glibc 2.8, and GCC 4.3, and recently glibc 2.9 . And in addition to this, the build is also providing me with some data about imported libraries.

With this simple piece of script, I’m doing a very rough cut analysis of the software that gets installed, to check for the most commonly imported libraries: zlib, expat, bz2lib, libpng, jpeg, and FFmpeg:

    rm -f "${T}"/flameeyes-scanelf-bundled.log
    for symbol in adler32 BZ2_decompress jpeg_mem_init XML_Parse avcodec_init png_get_libpng_ver; do
    scanelf -qRs +$symbol "${D}" >> "${T}"/flameeyes-scanelf-bundled.log
    done
    if [[ -s "${T}"/flameeyes-scanelf-bundled.log ]]; then
    ewarn "Flameeyes QA Warning! Possibly bundled libraries"
    cat "${T}"/flameeyes-scanelf-bundled.log
    fi

This checks for some symbols that are usually not present without the rest of the library, and although it gives a few false positives, it does produce interesting results. For instance while I knew FFmpeg is very often imported, and I expected zlib to be copied in every other software, it’s interesting to know that expat as much used as zlib, and every time it’s imported rather than used from the system. This goes for both Free and Open Source Software and for proprietary closed-source software. The difference is that while you can fix the F/OSS software, you cannot fix the proprietary software.

What is the problem with imported libraries? The basic one is that they waste space and memory since they duplicate code already present in the system, but there is also one other issue: they create situations where even old, known, and widely fixed issue remain around for months, even years after they were disclosed. What preserved proprietary software this well to this point is mostly related to the so-called “security through obscurity”http://en.wikipedia.org/wiki/Security_through_obscurity. You usually don’t know that the code is there and you don’t know in which codepath it’s used, which makes it much harder for novices to identify how to exploit those vulnerabilities. Unfortunately, this is far from being a true form of security.

Most people would now wonder, how can they mask the use of particular code? The first option is to build the library inside the software, which hides it to the eyes of the most naïve researchers; by not loading explicitly the library it’s not possible to identify its use through the loading of the library itself. But of course the references to those libraries remain in the code, and indeed most of the times you’ll find the libraries’ symbols as defined inside executables and libraries of proprietary software. Which is exactly what my rough script checks. I could use pfunct from the seven dwarves to get the data out of DWARF debugging information, but proprietary software is obviously built without debug information so it would just waste my time. If they used hidden visibility, finding out the bundled libraries would be much much harder.

Of course, finding which version of a library is bundled in an open source software package is trivial, since you just have to look for the headers to find the one defining the version—although expat often is stripped out of the expat.h header that contains that information. On proprietary software is quite more difficult.

For this reason I produced a set of three utilities that, given a shared object, find out the version of the bundled library. As it is it quite obviously doesn’t work on final executables, but it’s a start at least. Running these tools on a series of proprietary software packages that bundled the libraries caused me some kind of hysteria: lots and lots of software still uses very old zlib versions, as well as libpng versions. The current status is worrisome .

Now, can somebody really trust proprietary software at this point? The only way I can trust Free Software is by making sure I can fix it, but there are so many forks and copies and bundles and morphings that evaluating the security of the software is difficult even there; on proprietary software, where you cannot be really sure at all about the origin of the software, the embedded libraries, and stuff like that, there’s no way I can trust that.

I think I’ll try my best to improve the situation of Free Software even when it comes to security; as the IE bug demonstrated, free software solutions like Firefox can be considered working secure alternatives even by media, we should try to play that card much more often.

flame@yamato ~ % touch /var/tmp/portage/test
touch: cannot touch `/var/tmp/portage/test': No space left on device
flame@yamato ~ % df -h | grep /var/tmp
                       32G  7.2G   23G  25% /var/tmp
flame@yamato ~ % df -i | grep /var/tmp
                     2097152  419433 1677719   21% /var/tmp

Now, a mount cycle later it worked fine, but it’s still not too nice since it caused all the emerge running to fail, just like XFS did, but without leaving trace on the kernel log, which makes it obnoxious since it’s hard to debug. I hope 2.6.28 is going to be better, certainly the tinderboxing is a nice way to stress-test filesystems.

I start to consider the idea of OpenSolaris, NFS, and InfiniBand…

In the last couple of days I had to focus my attention on just one issue, a work issue which I’m not going to discuss here since it wouldn’t make much sense either way. But this brought me to think about one particular point: remote debugging, and how to make it easier with Gentoo.

Remote debugging is a method commonly used when you have to debug issues on small, embedded systems, where running a full blown debugger is out of question. With GDB, this consists of running on the target system a tiny gdbserver proces, which can be controlled by a master gdb instance via either serial port or TCP connection. The advantages don’t stop at not needing to run the full blown debugger: the target system may also be equipped with stripped programs with no debug information, and keep the debug information entirely on the system where the master gdb instance is being executed.

This is all fine and dandy for embedded systems but it also does not stop to this, you can easily make use of this technique to debug issues on remote servers, where you might not want to upload all the debug symbols for the software causing the trouble, it then becomes a nice Swiss Army knife for system administrators.

There are a few issues you got to work with when you use gdbserver though, some of which I think should be improved in Gentoo itself. First of all, to debug a remote system that is running a different architecture than yours, you need a cross-debugger; luckily crossdev can build that for you, then you need the actual cross-built gdbserver. Unfortunately, even though the server is small and self-sufficient, it is currently only being built by sys-devel/gdb which is not so nice for embedded systems; we’d need a minimal or server-only USE flag for that package or even better a dev-util/gdbserver standalone package so that it could be cross-built and installed without building the full blown debugger which is not useful at all.

Then there is the problem of debug information. In Gentoo we already provide some useful support for that through the splitdebug feature, which takes all the debug information from an ELF file, executable or library, and splits it out in a .debug file that only contains the information useful during debugging. This split does not really help much on a desktop system, since the debug information wouldn’t be loaded anyway, my reasoning to have it separated is to make sure I can drop them all at once if I’m very short on space, without breaking my system. On the other hand, it is very useful to have it around for embedded systems for instance, although it currently is a bit clumsy to use.

Right now one common way to achieve proper archiving of debug information and stripping them in production is using the buildpkg feature together with splitdebug, and set up an INSTALL_MASK variable for /usr/lib/debug when doing the build of the root. The alternative is to simply remove that directory before preparing the tarball of the rootfs or stuff like that. This works decently, since the binary packages will have the full debug information, and you’d just need to reinstall the package you need debug information for without the INSTALL_MASK. Unfortunately this will end up replacing the files from the rest of the package, which is not so nice because it might change the timestamps on the filesystem, as well as wasting time, and eventually flash too.

This also does not play entirely nice with remote server administration. The server where this blog is hosted is a Gentoo vserver guest, it was installed starting from a standard amd64 stage, then I built a local chroot starting from the same stage, setting it up exactly as I wanted it to be; finally, I synced over the Portage configuration files, the tree and the binary packages built of all it, and installed them. The remote copy of the packages archive is bigger than the actual used packages, since it contains also the packages that are just build dependencies, but the overhead of this I can ignore without too much problems. On the other hand, if I were to package in all the debug information, and just avoid installing it with INSTALL_MASK, the overhead wouldn’t be this ignorable.

My ideal solution for this would involve making Portage more aware of the splitdebug feature, and actually split it out on package level too, similarly to what RPM does with the -dbg package. By creating a -debug or -dbg binpkg to the side of each package that would otherwise have /usr/lib/debug in it, and giving the user an option on whether to install the sub-package, it would be possible to know whether to merge on the root filesystem the debug information or ot, without using INSTALL_MASK. Additionally, having a common suffix for these packages would allow me to just ignore them when syncing them to the remote server, removing the overhead.

Dreaming a bit more, it could be possible to design multiple sub-package automatic generation, to resemble a bit what binary distributions like Debian and RedHat have been doing all these years, to split documentation in its -doc package, the headers and static libraries in -dev and so on. Then it would just require to give the user ability to choose which subpackages to install by default, and a per-package override. A normal desktop Gentoo system would probably want to have everything installed by default, but if you’re deploying Gentoo-based systems, you probably would just have a chroot on a build machine that does the work, and then the system would just get the subset needed (with or without documentation). Maybe it’s not going to be easy to implement, and I’m sure it’s going to be controversial, but I think it might be worth looking into it. Implementing it in a non-disruptive way (with respect to the average user and developer workflow) is probably going to make it feasible.

Tomorrow, hopefully, I’ll be writing some more distribution-agnostic instructions on how to remotely debug applications using GDB.

I’ve written about my idea of writing my own testsuite for uif2iso and using CC-BY-NC-SA music from Jamendo to do the trick, unfortunately it seems like I cannot do that:

If your project is non commercial, you can use the music without paying for a license as long as your project respects the rules of the Creative Commons (http://www.jamendo.com/en/creativecommons). It means that Gentoo has to be distributed under a Creative Commons License. If not, then you do have to buy a license, even if it is a non-commercial project.

Seems like mere aggregation becomes a problem too. Coincidently there was a poll on the Creative Commons site about the NC clause the other day, and I already expressed there my doubts about the “mere aggregation” case.

As it is, it becomes a problem for me to use the album by Countdown for my testsuite project, which actually makes me a bit sad since I really liked the album and would have liked to give the testsuite a fun character with something I liked. I guess I’ll have to find something else.

So if somebody knows where I can find some CC-BY content, I’d be glad to hear it; my idea was to use an image and an audio file, just to have two different size magnitudes. Metal would probably be more acceptable, but I guess anything at this point works. My reason for looking for those is that they can be easily used for other type of tests, for instance mp3 or OggVorbis files can be used for tag reading/writing programs for testing purposes.

On a different note, thanks a lot to the (anonymous) user who sent me The Hitchhiker’s Guide To The Galaxy radio series, tonight I have something to look forward to when I’m done filing bugs!

Update: since Reddit an DZone picked this up, and people still look at this post and just this post, please also check my followup on RubyGems thanks.

I’m obviously referring to Ruby Gems.

If you follow Debian developers blogs at Planet Debian, you probably already know that some of them are on a crusade against RubyGems. I happen to agree wholeheartedly with that.

While the idea behind gems is pretty cool to standardise installation of libraries among heterogeneous systems, it has one big drawback: it takes the control out of a system’s standardised package manager, like Portage, like apt-get, like yum, and so on. While certainly a non-system package manager might be better than no package manager at all, and thus saves the hordes of Ruby on Rails users from having to install all the dependencies by hand, it should really allow for proper packaging of the libraries through the distribution, rather than taking over entirely.

There are even more arguments against gems when it comes to source distributions like Gentoo; one nice thing that Gentoo allows developers and users alike to implement is checking and changing the code around, like applying custom patches, or checking for particular type of code we might not want to have on our system. This can be folded up in further QA checks or particular checks for known broken boilerplate code (a similar situation happens – or at least happened – on the Gentoo/FreBSD profile, where I added code to check for one particular piece of gnulib that would have caused known runtime errors). RubyGems take those features away.

Because of the way these features are implemented (with phases) and the way RubyGems can only get installed, it is basically impossible to patch them before compiling, check the sources after unpack for known broken or insecure code, and much worse it is impossible to properly implement the test features!

This is particularly nasty since, as I said in my previous post, the test feature already saved me from committing a broken ruby-prof into ~amd64 last week, thanks to the fact that I switched that ebuild from gem to tarball, installing it “by hand” on the ebuild, so that the src_test function could be properly implemented. This is probably the best reason for not using gems I can think of, but certainly not the only one.

You can add to that that gems always install the tests code rather than just using it during test and then leaving it a part, you can add that they all install in their own subtree not meshing well with the rest of the system, you can add that a copy of the gem is kept on the system as “cache”, but not in /var/cache a sone would expect it to be but in /usr/lib (and lib64 for multilib).

If you take for instance rake, that installs through gem on Gentoo, you can find, among other things, that there is a rake.1.gz file that contains rake’s man page. But it does not get installed because it’s part of the gem, rather than being handled through doman.

Now, all that has been written about gems is probably true of many other similar technologies, like Python Eggs or Maven, as far as I know, and it shouldn’t be taken as a critique of Ruby as a whole. Just to say, Ruby is my favourite language. It just needs to be more polished around and to work more closely with vendors (distributors) so that it gets seamless with the rest of the system.

I’m surprised that my previous post about rubygems got so much coverage, since I really didn’t find I added much to the common knowledge about RubyGems shortcomings. It’s not like I’m just piling up together with the Debian guys on the “gems bashing” just for fun. My switch away from gems for the packages I maintain started a few weeks ago already, and I’ve spoken with Hans about this at the time too. Now, let me try to address some of the concerns that people seem to bring up, since I’m not the kind of person who throws a rock and then hide to see the results.

As Alex said, it is actually possible to patch up Ruby Gems; and indeed I knew how to do that myself, but… it takes unpacking and repacking the files, which is generally a waste of CPU time and that is not really something that I would call “feasible” just to fix the code, when we do the same thing without any kind of issues for a huge amount of software already. Also, as he also pointed out, log4r and other gems don’t really use the tar format, instead it seems to contain some YAML-formatted list of base64-encoded files. Not nice, no.

On the other hand, Elias added that the problem is shared by all common toolkit-specific package managers: PHP/PEAR, Ruby/Gem, Python/Egg, Perl/CPAN, TeX/CTAN. This is probably right, although I think I have something to add here since lots of people seem to think that CPAN and RubyGems are on the same page, when they certainly are not, as Debian developers already pointed out. As for what concerns Python Eggs, and PHP PEAR, I have no experience working with them, while I know the Gentoo Python team does not like Eggs for just about the same reason why Ruby team does not like Gems.

As Wouter Verhelst points out:

There’s CPAN.pm, which does much the same thing as RubyGems; but much of CPAN can be easily turned into a Debian (or RPM, or whatnot) package. The few cases where it can’t, you’re usually dealing with a broken CPAN package, anyway.

He’s perfectly right here, CPAN modules can be easily turned into distribution-specific packages, included ebuilds thanks to g-cpan. The reason for this is that instead of inventing its own freaking file format, CPAN uses standard tarballs or ZIP packages, and a specific structure of the files inside of the package. Once you know how the structure for a package is, implementing downstream-specific packaging of such tools is very quick, and still allows for all the versatility that downstream package manager require.

For the little I know about it, I think CTAN does just the same, and indeed Wouter states that too:

There are similar things for Python (egg), and, heck, even TeX (CTAN). The fact that other scripting languages have proper and working packaging systems only outlines that there really isn’t an excuse for the horrors of RubyGems.

I think that Wrobel’s post is indeed a very important reading because it summarise the fact that the argument that Gentoo and Debian have against RubyGems is not that there shouldn’t be a language-specific package manager for Ruby, but rather that we would have certainly liked a better-designed package format that could suit both the system-independent packaging and the downstream packaging at once, allowing for proper integration between modules installed by users and by the distribution.

The fact is that beside gems there is no vast and common standardisation of practises between Ruby packages, which makes the role of distributions much more complicated than it has been historically for Perl, Python, TeX and the like. What do I mean? Well, take extconf.rb and setup.rb files that are often used to build binary C-based extensions for Ruby: they are not generated by tools like autotools or distutils, and instead they are copied and morphed from package to package, causing them to have subtly different syntax and stuff like that. To use a DESTDIR-like parameter (to install in a subtree before packaging) some require you to specify that during install phase only, others will require you to pass it on all the parameters. One would expect that Rake could have brought some more standardisation in packaging, but it’s not the case either.

For once, Rake does not usually have an “install” task, and even less one that taking a DESTDIR parameter to install in an offset. This is something I’ll probably try to find a solution for once Ruby-Elf arrives to a point where a release is needed, because I don’t intend to use RubyGems as my primary form of distribution, quite obviously. But it does not limit to that: even the tasks that are usually common between packages don’t follow the same interface. Some packages will use “rake test” for running the testsuite, others “rake spec” and others “rake rspec” because they don’t use Test::Unit but rather Spec. Some packages will build the HTML documentation with “rake doc” and others with “rake rdoc”.

I think that the underlying problem here is that Ruby has been really the most “magic” of the languages. While this is very nice for the developers, it is not always good; sometimes having too much magic around can make integration or debugging very hard, just like automagic dependencies make it difficult to properly package software, Ruby magic can be a hinderance when doing something that goes a bit away from what the mainstream developers do.

Now, since just criticising software is rarely useful, let me try to explain what is my plan to resolve, or work around, the issue. First of all, I’ll see to work with Hans and Alex, as soon as I have time, to find a way to simulate the presence of a gem when the package was installed by the ebuild using a tarball, so that there is no loss of magic when using the ebuilds themselves. Then I’m going to try preparing a distribution-friendly “install” task for Rake, as I said first and foremost for RubyElf but I’m going to release it as-is so that other projects can use it too, and try to standardise it.

But these are little steps; what I’d like to do, but I lack the time to, is writing a specific about packages installation and design for Ruby so that a project following that specific can not only build gems for “magic” installation on heterogeneous systems, but also prepare tarballs that distribution can turn into proper packages without having to deal with black magic. This would not mandate a particular file format like gems are doing, but rather a particular directory structure or Rake-based interface. Once the same exact steps can be run for any given package following the specification, it’s going to be just enough for the distributions.

Even though I’ve heard Patrick complaining about this many times, I never would have been able to assess how much of the tree goes untested if I didn’t start my little own tinderbox. Now, I’m probably hitting more problems than Patrick because I’m running ~arch (or mostly ~arch) with --as-needed enabled, but it still shows that there is a huge amount of stuff that needs to be fixed, or dropped.

Up to now I’ve been using GCC 4.1, and still hit build failures with it; now I’ve switched to GCC 4.3, even though the tracker shown a bad situation already; and of course there are packages that didn’t have bugs opened just yet, because nobody built them recently.

Still, supporting the new compilers is not my main concern sincerely; there are packages that won’t build with GCC 4.3 just yet, like VirtualBox, as there are packages that still don’t compile with GCC 4.0. What concerns me is that there is stuff that hasn’t been tested at all. For instance, sys-fs/diskdev_cmds which was marked ~amd64 was totally broken, with fsck.hfs causing a Segmentation Fault as soon as it was executed (the version that is now available works, the old one has been taken out of the keyworded tree).

Since even upstream sometimes fail, one should also take into consideration the packages’ tests, possibly ensuring their failures are meaningful, and not just “ah this would never work anyway”. If you check dev-ruby/ruby-prof, the test suite is executed, but a specific test, which is known to fail, is taken out of it first. This is actually pretty important because it saves me from using RESTRICT to disable the whole testsuite, and executing the remaining tests helped me when new code was added to support rdtsc on AMD64, which was broken. The broken code never entered the tree, by the way.

Unfortunately doing a run with FEATURES=test enabled is probably going to waste my time since I expect a good part of the tree to fail with that; with some luck, if Zac implements me a softfail for tests, I’ll be able to do such a run in the next months. I wonder if the run this time will be faster, I’ve moved my chroots partition to use ext4(dev) rather than XFS, and it seems to be seriously faster. I guess once 2.6.28 is released I’ll move the rest of my XFS filesystems to ext4 (not my home directory yet though, which is ext3, nor the multimedia stuff that is going remain HFS+ for now).

My build run also has some extra bashrc tests, beside the ones I already written about, that is the checks for misplaced documentation and man pages. One checks for functions from the most common libraries (libz, libbz2, libexpat, libavcodec, libpng, libjpeg) that gets bundled in, to identify possibly bundled-in copies of those, another checks for the functions that are considered insecure and dangerous by libc itself (those for which the linker will emit a warning). It is interesting to see their output, although a bit scary.

Hopefully, the data that I gather and submit on the bugzilla for these builds will allow us to have a better, more stable, and more secure portage tree as the time goes by. And hopefully ext4 won’t fry my drives.

At the end of November, I’ve read an interesting in-deep look at what PIC code is on Planet Debian; although it wasn’t really perfect in my opinion (as I commented on that post in particular it seems to give the impression that x86 text relocation option is better than AMD64 pc-relative approach, which in my opinion is not the case at all) it is a good explanation for most power users still unsure of what the problem is.

Now, as you can see on that post, the problem with PIC and text relocation is usually related to just shared libraries, since executables get loaded always at the same address in memory and thus require no relocation for their symbols. While this is the case for most common scenarios, there are cases when you want to relocate executables, too. For instance if you enabled randomisation of the load address as a security mitigation strategy. When that is the case, we say that PIE was enabled: Position Independent Executables.

in PIE-enabled systems, the address used to load an executable can vary between executions, which means that the references to jumps and data will not be at a fixed address in memory any longer, just like a shared library. Again you have the option of using text relocations (but since they conflict with other security mitigation strategies, it’s quite silly to do that) or you just build PIC code for the executable too. Now, this does cause a hit in performance since the symbols need to be resolved, once again, but it’s still better for the memory compared to text relocations, too.

It’s for this reason that I try my best to make sure that even code that is not going to be built into shared libraries is optimised so that it does not cause relocations either if possible.

Now, I’m sure that most users don’t need or want a PIE-enabled setup on their desktops; while the issue of how much mitigation strategies are useful on a desktop is a debatable topic that can go on and on for months, I just accept the fact that most users don’t want that, and that they should thus not be forced to use PIE for their software if they don’t want to. Indeed, it can cause extra dirty RSS pages for the processes using those executables, which is not something you wish especially on embedded systems.

On Gentoo, we don’t enable PIE by default, which means one would expect all the binaries installed by Portage to not be built with PIC code, but this does not seem to be the case, at least not always. While I was working on my size(1) replacement last night, I found that there are binaries in /usr/bin of my system with .data.rel.ro sections. The point is that .data.rel.ro only exists when the software is built with PIC, otherwise it makes no sense and the constants are emitted in .rodata, so I was not expecting any .data.rel.ro on /usr/bin.

So I started looking at the issue; while none of the files are Position-Independent Executables, some of them are built with -fPIC compiler flag, by mistake mostly, when added to properly build shared objects. Add to that the other two possible causes: --with-pic passed to the ./configure rather than leaving it to be figured by libtool, and -fPIC being used to compile static archives, so that they could work to link statically shared libraries too.

One of the packages doing this was Avahi, for which I sent a patch to Lennart, but it’s far from being the only one; I’m going to work on a few more patches in the next weeks, hopefully I’ll be able to reduce that. I also will have to work on an extra check for my bashrc system for the tinderbox, and consider adding that to Portage. Unfortunately just checking for .data.rel.ro is not enough: if a binary built with -fPIC does not have constants, but only variables, it will all be merged in .data, with the proper relocation entries. So to decide whether an ELF file is PIC or not one has to check the relocations, too, and even that is not going to be an absolute certainty, I’m afraid.

At any rate, I’m going to do my usual best to find out how to mitigate these problems, at least for the most common packages. As usual I strive to ensure that free software gets the best coverage even for these small little things that are important only once seen in the grand scheme of things. I guess I’ll have to find time to fetch a copy of Linkers and Loaders and read it so I can design some more interesting optimisation tests. Maybe one day I’ll be able to find enough time to start adding some of my common tests to binutils itself.