OpenBSD Journal

Testers sought: Patch for ld.so on a.out

Contributed by jose on from the fixing-loader-bugs dept.

Marc Espie has posted a patch to ld.so for a.out systems (which includes i386). This is an attempt to fix a dependency sorting issue. This was specifcally found when building KDE 3.1 and may fix some other complicated software packages which have had difficulty in building and running. It hasn't yet been comitted to the tree but those of you on -current who are not adverse to risk may want to have a look at it. You'll want to keep a copy of you're original ld.so binary (in /usr/libexec) around and, if needed, restore it after booting from a floppy, for example.

Update : A second patch has been issued. This is independent of the first patch but can also be tested with it.

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    Why doesn't i386 use ELF yet?

    Comments

    1. By Anonymous Coward () on

      err, it does__

      doesn't it?

      Comments

      1. By Anonymous Coward () on

        No. It uses a version of a.out that's been hacked up to include PIC (position-independent code) support. One of the few dumb things about OpenBSD, really.

        (Don't get me wrong-- I love OpenBSD, it's my primary OS, and I use it extensively. But the a.out/ELF thing has made it hard as hell to update binutils and gcc, which makes a lot of applications difficult to port.)

        Comments

        1. By Anonymous Coward () on

          stink.

        2. By Brad () brad@comstyle.com on mailto:brad@comstyle.com

          A lot of applications? This couldn't be more bullshit if I've ever heard it. If you want ELF so bad then help fix the few remaining bugs that prevent a full conversion.

          Comments

          1. By AC () on

            Agreed, this affects Mozilla but are there any others really...

            Comments

            1. By Brad () brad@comstyle.com on mailto:brad@comstyle.com

              No it doesnt affect Mozilla, Mozilla on our ELF archs doesn't even work when linked statically. It is a matter of some bugs in our base system most likely. The only program so far AFAIK that REALLY needs new binutils is WINE.

              Comments

              1. By Anonymous Coward () on

                Valgrind would be a lot easier to port to an ELF x86 target as well

                Comments

                1. By Peter Valchev () on

                  So stop bitching and start hacking

          2. By Anonymous Coward () on

            And those bugs are?

        3. By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org

          Not THAT many applications, actually...
          (I should know, I ported a fair section of the difficult ones).

          In many cases, the real issues are something else entirely.

          One good thing about old binutils is that it's reasonably manageable, as compared to the monster binutils has become recently.

          Likewise for gcc: every new version is slower, has more bugs, and fix some bugs. It's too bad they HAVE to move forward and you CAN'T get the parts you want (decent sparc64 support, decent C++ error messages) without the parts you don't want (all those buggy optimizer passes that take twice the time compiling for a 1% speed improvement, at best)

    2. By Anonymous Coward () on

      x86 ELF support is on the list of things to do from what I recall. Attempts have been made, but consensus seems to be that the soonest it will happen is after 3.3.

  2. By Gorbot () on

    I have been having a *very* difficult time building Cyrus IMAP on 3.2 "patch branch". Could this latest patch help? If anyone thinks it would, I will move to "current" and give it a go.

    Comments

    1. By Anonymous Coward () on

      try freebsd

      Comments

      1. By Anonymous Coward () on

        try go away

    2. By pravus () on

      you might also think about trying courier. i've been using cyrus for the past year or so, and while it's a good software package, the setup was horrible. i just switched to courier last night and it seems like it has everything that i need without the painful install. you might think about it if your situation allows.

    3. By jose () on http://monkey.org/~jose/

      this appears to be more of a runtime fixup than a buildtime fix. it's possible your build issues are caused by bugs in the compiler and toolchain, though. but this bug is in the load/runtime part of an executable.

  3. By Anonymous Coward () on

    So, ah, what's the difference between a.out and elf. What's this new thing do?

    Comments

    1. By Jeffrey () on

      It's not a new thing; they are just different object file formats.

      You can read more about it at:
      http://www.iecc.com/linker/linker03.html

  4. By Anonymous Coward () on

    Excuse the OT, is it possible to install the old KDE (v1) with some past port on 3.2?

    I don't need kde2/3 and I felt comf with the older version (and with CDE on Solaris).

    Comments

    1. By Todd Fries () todd@openbsd.org on http://todd.fries.net/resume.html

      Are you out of your mind?

      KDE-2.2 has security bugs, even kde-3.0.5
      has a 3.0.5a release for security.

      If you care not about security, feel free to
      shoot yourself in your own foot. Otherwise,
      consider upgrading.

    2. By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org

      It's a bad idea.
      There have been security fixes in kde recently, hence
      the 3.0.5a bump in -stable.

      Those fixes also exist for kde 2.2.2, but definitely NOT for the kde1 branch.

      As soon as you use konqueror, you lose. There are known security holes in the old version.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]