[openbeos] Re: gcc 3.x ABI
- From: Thierry DELHAISE <delhaise.t@xxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 20 Sep 2002 20:08:14 +0200
On Thursday 19 September 2002 01:15, you wrote:
> I am not at all opposed to using 2.95.6 if someone wants to port it.
I'm doing a port of the 2.95.3 (latest officlal version where we can find
support from gcc.gnu.org)(OT :. I need a compiler/assembler/linker chain
stable enough to handle 16 bits and 32 bits code and an objcopy that don't
fill garbage inside elf ;-)) No, other versions says the gcc "gurus" about
2.9x tree ;-) All other version are not supported at al .
It concern binutils too, but this is not in the area of gcc. It depends of
binutils from RedHat and this is mostly where I've problem (Human Problem
;-). I'm leading this stuff if you authorize me to talk for OpenBeOS project
! I will send you all mails sent to the list. I'will email you directly some
contact I had the past two days : just to make an opinion ;-)
> I think that the newest (final? Did they stop supporting 2.95?) version of
> GCC2 is probably a good thing. I do want to hold the line on 3.0, at least
> until R1 is done.
Yes ! They don't accept anymore commit in the 2.95.3 even patches. So, we will
have to extract the latest 2.95.3 from cvs (because it's not the same
originals as the sources we have inside the different port made by
contributors.
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 ;-)
For C++ code, I think we can use (because we are still in development) version
3 too. I will try to (just) SUGGEST you how (it's just a suggestion because I
may be wrong, in some area of BeOS, so this is just my tought ) :
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 !
Another thing, is the ABI number used by Be. It's not official, and it's not a
sub familly on from unix ABI code like Linux or FreeBSD !
ABI is just a code as a major and a minor number. Major identify familly and
minor sub-familly
Be choosed to use a primary familly different of Unix (I think it's 4 for the
major number, don't remember exactly and sub-familly to handle is specific
stuff! Good Idea !!.
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.
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
version where with one argument we change the ABI version inside the compiled
file (ld, as mostly )
As you like ;-)
Thierry (BeFree)
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()
;-).
I've officially contact the two projects to have access to there experience
and help me port those softwares on BeOS/OBOS ! THX to those two teams which
will give us support !
For perl seems it is Lary Wall who handle and manage all ports. Respects !
My THX for gcc and binutils team will wait some times but are not so far ;-)
Other related posts:
