[openbeos] Re: gcc 3.x ABI
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 20 Sep 2002 21:35:53 CEST (+0200)
Thierry wrote:
> For C developpement we are encourage to shift to 3.0.4 since this is
> from gcc
> team the most stable! TreyB said me yesterday on irc that Travis use
> a 3.04
> to compil NewOS and that he provide on his site a way to cross compil
> under
> Unix. (Hey Travis, could you confirm ?) Switch to 3.2 branch in the
> futur
> have normally no impact on C code ! That's what gcc said ! I can't
> verify for
> now but will be soon ;-)
Of course it hasn't. And that's also why we don't have to care about
this stuff for now :-)
> All part of the BeAPI in userland use the root lib libroot ;-). All,
> application refer in their elf core to libroot, libbe for example.
> One api
> libmedia.so depend on libstdc++.r4.so directly. It seems this is the
> only one
> in /boot/beos/system/lib. In /boot/beos/system/servers only
> media_server is
> concern with libstdc++. So we provide those lib compile with a 2.9x
> version !
> We provide the same library too compiled with a 3.x branch tree ! We
> only
> change the name of the lib (We may thought about an inteligent way to
> name it
> ) or we use the ABI stuff of elf as Be used it.
>
> All our new app (OS one, app preference, terminal, etc could be
> compil with
> the new lib we provide. It's just some modification to add to rld.so
> to
> handle identification in the headers of each elf file. In fact, we
> could
> thought now to some inteligent way to handle those problems : gcc
> could
> change it's ABI in 4.x ;-). So may be, we must be aware of this now
> since we
> are allways in a stage where our choices are not so difficult ! When
> R1 will
> be out, it could be hard to change something !
That's not possible - it's not only the dependency on libstdc++, it's
the whole ABI issue; exceptions (thankfully not used in the BeOS API -
for that matter), RTTI, vtable, name mangling, etc.
If we compile our version of libbe.so with gcc 3.2, we can't run any of
the old programs anymore - which is what we aim for. Of course, we
could take our sources and build the whole OS with gcc 3.2, but then we
have lost binary compatibility.
> I we could officially obtain this familly now form OpenBeOS, we could
> based
> our design on this too : we change nothing about the name of the
> library, we
> provide the same name in different directory, and we just analyze the
> ABI
> major/minor version.
That's the way we wanted to do it later - but we can switch at any
time, it's not that we must change before R1 ships. We only have to
provide the old libraries for compatibility and a way to load them if
needed. Definitely not that nice, but it'll work.
Now, there is a really good reason not to change to gcc 3.2 for R1.
Since we want to extend the API, add new functions, etc. there might be
a point where we want to break binary compatibility, too. If we would
switch to gcc 3 already for R1, we would have to break binary
compatibility again in this case.
> A new time, it's just a discussion. Since I will be able to provide
> you a
> 2.95.3 and a binutils 2.13 in the near futur, I can provide a 3.04
> too or
> whatever versions you will choose ;-) For the binutils I can provide
> a
I really think 2.95.3 is sufficient, we might also want to have a look
at what patches are around for that gcc, too (i.e. at cygnus).
We may want to compile the kernel with gcc 3.2 later, but there is no
reason to hurry.
> PS : For now, my most important problem is to gain a stable perl and
> tcl
> version to run dejagnu, autoconf, which are the tools use by gcc and
> binutils
> to run regretions tests suites. It's just a problem of signal() and
> select()
> ;-).
autoconf has already been ported, you can access it at http://
www.geekgadgets.org or http://www.bebits.com/app/2082 (dunno if these
are the same versions, though).
Please don't "waste" all your energy on something that has already been
made by someone else :-)
Adios...
Axel.
Other related posts:
