Roy's Blog

A Hacker's musings on Code | Tech | Life

revdep-rebuild pre7 re-write failed to work on FreeBSD for finding bins built with a specific library. I needed this to work as I'm rebuilding against libthr instead of libpthread and as the two libraries are mixed without a libmap.conf it's segfault city - heh.

As FuzzyRay wasn't around to aide in debugging at the time I plunged into it's source yesterday. My eyes bled from spending time looking through it for the bug :(

Basically revdep-rebuild, like many other Gentoo utilities, uses bash. Well, it uses bash constructs but nothing bash specific that cannot be done trivially in pure sh. It also abuses find, grep, awk and sed. Me being the awkward sort, I took offence to this and did a ground up re-write in pure sh. You can find it here. The crew in #-portage are looking over it and it may or may not be used. But they all think it's cleaner, so I'd say the chances are good.

But how is this about vendor lock-in? Simple really. It's another demonstration that most of the time you don't need to force bash. Why should every script on my system force bash? Gentoo is about choice, and I choose not to have bash when possible :) As a login shell it's the best, but as a scripting shell it's too big and bloaty. Basically I'm going to make it a little goal - when I find a bash script I'll de-bashify it and pester upstream to accept it. This makes the script run on more platforms, so unless you're in bed with the bash maintainer there's no driving reason not to.

Discuss this Post

FreeBSD-6 ships with 3 threading libraries (oldest to newest)

  • libc_r
  • libphread (really libkse)
  • libthr

They should all be ABI compatible with each other and as such are easily interchangeable using libmap.conf. However, that's not always the case....

In our efforts to fix threaded python on sparc64 and a few other threading weirdness on x86 we shipped a default libmap.conf that defaulted to using libthr for everything. Many moons passed and everything was good, until LavaJoe discovered a little problem with this. Basically applications are built against libpthread but run using libthr. libpthread has some symbols that shouldn't be used, but are still embedded so even if libmap.conf says use libthr, libpthread is really used. So you could have 2 threading libraries loaded which is the source of the issue.

So our present solution is not to build or install libc_r OR libkse. Instead we set the default threading library to libthr and provide symlinks for libc_r and libpthread. This seems to works very well, but with 1 caveat - applications which embedded private symbols to libkse or libc_r no longer link correctly. So far this is just glib, which has proven to be a most troublesome library over time and is so once more! The solution is to re-emerge the library you're failing to link to and then it should work.

If anyone is concerned by this you need not be - FreeBSD-7 will ship like this by default.

Discuss this Post

Mr Popular


Looks like I was voted into Gentoo Council for a second term 8) . I must be doing something right if that many people voted me in - heh. Thanks for voting!

Discuss this Post

That's a good question and I'm glad you asked as although I've not been blogging I have in-fact been busy hacking away. :P Here's a quick summary of what I've been working on

In-case any Gentoo/FreeBSD users are reading this, the recent bumps to -sources, -libexec and -lib are for the dl_iterate_phdr backport. Right now, it does nothing. But when I finish the gcc-4 patchset I' m working on, gcc will use it to determine if it really needs to link to just like it does for our glibc users. This is important, as currently it's linked against every binary and library built, which isn't really that great. :O

Hopefully when this is all done, --as-needed linker should work for all you ricers out there as it currently doesn't on Gentoo/FreeBSD. }:)

Discuss this Post


Nerd Test says I'm an Uber-Dorky High Nerd. What are you?

Discuss this Post