Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Jan 1998 18:18:25 +0100 (MET)
From:      Søren Schmidt <sos@FreeBSD.dk>
To:        roberto@keltia.freenix.fr (Ollivier Robert)
Cc:        hackers@FreeBSD.ORG
Subject:   Re: FreeBSD ELF status?
Message-ID:  <199801011718.SAA24583@sos.freebsd.dk>
In-Reply-To: <19980101164804.30732@keltia.freenix.fr> from Ollivier Robert at "Jan 1, 98 04:48:04 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Ollivier Robert who wrote:
> According to John Polstra:
> > Everybody who was working on it got very busy with paywork, so there
> > hasn't been much progress lately.  We still have hopes of having it
> > ready for 3.0-RELEASE, but time will tell whether that will work out
> > or not.  The primary obstacle remaining is The Migration Problem.
> 
> After giving some thoughts on the subject, here is what I got:
> 
> - we must put into the source various tools such as binutils & gcc
>   (preferably egcs or pgcc IMO) before. That is a very big increase of the
>   tree size.

We don't need a new compiler, the gcc in the tree allready has all it needs
to make ELF bins. Binutils is needed for the assembler, linker and misc
utils.

> - after that, we must decide if we want to converted system to be able to
>   generate a.out binaries or not. 

Hmm, the way I have had it working here, is that you set an environment
var to tell the compilersystem & utils what bin type you want, ELF being
the default.

>   That's the main issue I guess. The former is much more difficult to
>   handle because that would mean keeping two versions of too many things in
>   the tree and it is probably a nightmare.

No not really, its only binutils that gets pulled in (and only parts of it
is really needed. Since the GNU shi^H^Htuff is kept in its own part of
the tree no real probelms arise from that.

>   The latter greatly simplify (:-)) the process because I see the
>   bootstrapping as an added phase before making the world.

Hold your horses :), its not completely that easy, but a special target
could do the transition one and for all.

>   We'd need to generate a compat-a.out.tgz tree with the "old" tools
>   (ld.so, all libs and so on) to let people runing old binaries (CURRENT is
>   less of an issue here). /usr/lib/aout ? /usr/lib/i386-unknown-freebsd ?

/usr/lib/aout for the libs, or jump the major# to signify a new format...
/usr/libexec/aout for the old aout utils still needed, if any at all...

> - next phase is getting rid of the old tools' sources from the tree (my
>   modem has started sweating at the CTM delta size :-).

Well, its not much we can get rid off (strip, nm, ranlib and stuff), the
compiler is the same (No I dont think we should switch to a new compiler
just now, and especially not when doing this kind of "workout"), we still
need the old rtld, to run older bins etc, and some might want then around
just in case...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt               (sos@FreeBSD.org)               FreeBSD Core Team
                Even more code to hack -- will it ever end
..



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801011718.SAA24583>