Subject: Re: i386 elf and libc
To: None <current-users@netbsd.org>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
List: current-users
Date: 12/10/1999 23:32:18
>>>>> "Bill" == Bill Studenmund <wrstuden@nas.nasa.gov> writes:

    Bill> On Fri, 10 Dec 1999, Michael Richardson wrote:

    >> I'm busy rebuilding all my pkgsrc stuff because I can't link new things
    >> against it (I just finished X11), just as if someone had bumped the major
    >> versions. 

    Bill> No, it's different in that while you are recompiling to change the output
    Bill> format, you AREN'T changing most of the code. Except for things which load
    Bill> libraries dynamically (like plug-ins, etc), you're code is still linking
    Bill> against the exact same functions. stat is still linking against the same
    Bill> syscall (which as you know isn't stat()). _That's_ why we don't bump the
    Bill> version number.

  Who cares? The files aren't compatible, yet we keep the same name. 

  If we changed the name in some way, I wouldn't need /emul/aout. I hope will
go with Matthew's patch. 

    Bill> Also you can force your build system to build i386 today using a.out, and
    Bill> I think some folks probably are still doing that. If we got into bumping
    Bill> the version number when we go to elf, then either the library source
    Bill> becomes quite convoluted (version # becomes output forma tdependent), or
    Bill> people loos that ability to stay with AOUT.

  I think that if there are any problems at all upgrading to 1.5elf, then we
will lose users. A shame, since with v6 and IPsec, this will be a major
killer release. 

    Bill> The upgrade path you describe is the one Linux took, and there are enough
    Bill> horror stories to make it an unpalletable choice. Like I heard of one
    Bill> person who got a binary which was simultaneously linked against libc 6
    Bill> (the Elf one) and libc 5 (the a.out one). This wonderful trick happened
    Bill> because some of the subsidiary libraries in turn depended on libc 5.

  Oh, so perhaps this is a reason not to build libbfd with both a.out and ELF 
support, or not to enable it by default. I'd like to be able to link
statically against a.out lib.a files though.
  
    >> I think that we should consider bumping all major versions of libraries
    >> for a port which switches from a.out to elf. Does ELF make major versioning
    >> of shared libraries easier? Will we ever get rid of the renames?

    Bill> You realize that that would force all ports to re-compile libraries just
    Bill> because one port moved to ELF? So alpha, mips, powerpc, i386, etc. all
    Bill> have to change for one port? Say not all of the m68k ports change at once.
    Bill> We'd then end up rolling version numbers for no compelling reason.

  I have 68k, i386 and sparc. I never found an occasion to compare major
numbers between ports.

    Bill> The renames will go away when we do bump the major number. If ever,

  If ever. The arguments for not making me recompile everything is quite
compeling. 

    Bill> I think a lot of us agree with you that the current upgrade path is
    Bill> problematic, and we need to do something else. But bumping version numbers
    Bill> like this isn't it.

  Okay. I'm convinced. I knew that I needed a new set of .mk files to build
the v6 libc, so this is why I'm doing this. I'm afraid to upgrade a lot of
machines that I maintain to -current because of ELF issues. Maybe once I get
one beefy machine finished (it finished rebuilding X) it won't be so painful, 
since I'll can rebuild my pkgsrc stuff.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [