Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

HEADS UP: /usr/bin/objformat fallout

Skip to first unread message

Kris Kennaway

Feb 3, 2007, 9:18:43 PM2/3/07

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


Recently the /usr/bin/objformat binary was finally removed from
FreeBSD 7.0. This binary only existed to report the default system
binary format ("elf" or "aout") and was introduced during the
a.out/ELF transition back in the 3.x days. Ever since FreeBSD 3.x it
defaulted to "elf", and FreeBSD 4.x and above removed all support for
running an a.out-based system.

The plan was always to remove this transition aid once the ELF
conversion was complete. For various reasons this was overlooked
until recently, and unfortunately in the meantime it has migrated into
numerous upstream applications with incorrect usage.

There are a large number of third party ported software which
interprets the lack of an /usr/bin/objformat binary to mean "we are
running on a pre-FreeBSD 3.x a.out system", and fails to build or
install correctly on modern FreeBSD systems.


Most of these problems are localized in the internal (outdated) copy
of libtool which many ports use. Fortunately, modern versions of
libtool have apparently fixed their incorrect use of objformat, and
the quick fix for many ports is to USE_AUTOTOOLS=libtool:15 to force
the use of the libtool port instead of their broken old internal copy.


Some ports have more extensive problems that cannot be fixed with this
strategy (or it creates other problems like creating lib.a files for
plugin libraries which makes no sense). They are still easy to fix
though, it's just a matter of locating the objformat check(s) and
making sure that they work correctly without objformat present
(i.e. fall back to elf instead of aout).


Q. I'm not running FreeBSD 7, how will this affect me?

A. It won't.

Q. What is portmgr doing about it??!

A. Since I bear some degree of responsibility for this problem coming
to light [1] I've been working on testing and committing fixes to
those ports which can be fixed using the libtool workaround. By now
almost all ports are fixed, except for some ports which are waiting on
maintainers to act, and some parts of gnome which are taking longer to
work through because there are many layers of libraries involved,
requiring repeated iterations of testing.

Q. Oh my god I cannot handle a few broken ports on my system!

A. First, that's not a question. Second, relax :) If you don't want
to deal with this situation on FreeBSD 7.0, then either just don't
delete your copy of /usr/bin/objformat or put it back (and then
consider dropping back to running 6.x, because there are worse
problems on the horizon, e.g. the gcc 4.x import). Unless you are
maintainer of an affected port, in which case: suck it up, soldier!

Q. But can't you make some kind of wonderful hack that
will fix this problem invisibly?

A. Yes, but we don't want to do that. This problem has been allowed
to persist and propagate for too long, and unless we involve
individual port maintainers and get them to push the fixes back
upstream, it's only going to keep propagating out in the wild as the
various Linux-centric projects out there copy from one another about
how to "properly" add FreeBSD support.

Q. What can I do to help?

A. If you get an email from me about a problem with your port, follow
the instructions and make the relevant fixes. If you find a problem
with a port I have already committed a fix to, let me know.

Other than that there's not much more you can do for now - I'm still
running repeated builds pushing out the USE_AUTOTOOLS deployment, and
having others also trying to work on those affected ports at the same
time will hinder me more than it will help. In a few days I will send
email about the remaining few unmaintained ports that need to be

I will also be contacting the maintainers of ports for which I added
the libtool15 dependency, so they can contact the upstream authors
about deploying a corresponding fix.



Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.6 (FreeBSD)



0 new messages