[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 

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: