gcc iussue or ... ?

[Loren James Rittle]

In article <5.2.0.9.2.20030411082040.02604e90 at 194.184.65.4> you write:
> The problem is very simple.  I mantain a unix/linux port of a UO
> emulator which works really fine natively under FreeBSD.

Thank you for this report.  Please consider this question: What
versions of g++/binutils were used on the various platforms?  Please
know this: There is a per-platform and per-binutils version influence
on mapping of program data/BSS to ELF section.  g++ 3.3 with recent
binutils on FreeBSD *will* allocate data as you saw on debian 3.0
(with a compiler version you didn't report).

Created with g++ 3.3 (prerelease) with binutils 2.13.2.1:

; size lonewolf
   text    data     bss     dec     hex filename
1792215   49768 21850592        23692575        169851f lonewolf
; ls -l lonewolf
-rwxr-xr-x  1 rittle  wheel  1992568 Apr 11 20:18 lonewolf*

Apparently, 3.2.X

Created with g++ 3.2.2 built from FreeBSD ports with FreeBSD 4.7
system binuilts 2.12.1:

; size lonewolf
   text    data     bss     dec     hex filename
1358349 17543167        4539088 23440604        165acdc lonewolf
; ls -l lonewolf
-rwxr-xr-x  1 rittle  wheel  21161728 Apr 11 20:35 lonewolf*

Spot checking the RedHat 8.0 system compiler which is labeled as 3.2
(but I happen to know is quite patched) with binutils 2.13+, globals.o
is the tiny size.

It is possible that you might find that any random version of g++ for
Linux allocates data to sections differently than FreeBSD.  I couldn't
tell you the exact release, but others fixed/improved C++'s use of ELF
sections in general (it was not as good as plain C in some areas).
After the general cleanup, I went through and fixed all the remaining
FreeBSD-specific bugs/issues in this area some time ago.  However, I
don't know if that work hit the 3.2 branch of the compiler...

Regards,
Loren