gcc iussue or ... ?
tlambert2 at mindspring.com
Fri Apr 11 14:12:31 PDT 2003
Gianmarco Giovannelli wrote:
> >The first, and least likely, since the same compiler and linker
> >is used on both FreeBSD and Linux, is that the uninitialized BSS
> >handling for some large static/global declarations is being handled
> >differently between the platforms.
> Ok... I think it could not be related to the problem ... the same gcc on
> debian 3.0 and FreeBSD 4.8 (2.95.x) and the same on mingw and FreeBSD 5.0
> (3.2.x) produce differents size code (linux vs 4.8 and mingw vs 5.0).
Someone has already pointed out that one of the .o files is, in
fact, handling uninitialized data differently on FreeBSD and Linux,
so this is the source of your problem. I thought it was the lowest
priority possibility, but I guess I was wrong.
The best fix for it is to do as he suggested, and to allocate
these things with malloc() at startup time, instead of declaring
them static. That will also avoid the problem in the future on
As far as the handling difference, I don't know why it happens,
and you are probably not going to find out, unless you objdump
both the FreeBSD .o file he pointed out and the comparable Linux
.o file, and find out what the differences are. Technically, the
compiler should be generating the same code on both platforms, and,
apart from header manifest constants and the date stamp, the code
that gets generated should be identical.
> >The second, which is more likely, is that there are some large
> >static/global declaractions that get initialized on FreeBSD, but
> >not on Linux. The way to find this is to search for platform
> >"#ifdef"'s in the code.
> There are none of them ... I have tried to search but there aren't or afaik
> I was not able to find them :-)
There are. There is one .o file that, by itself, is over 2M in
size in FreeBSD.
Examining the source for that file should tell you.
It occurs to me that you might be using the "-g" flag in FreeBSD;
maybe you put something in make.conf?
One potential source of this, which is non-obvious, is the static
sonstruction of objects (e.g. define a class, and then globally
declare an instance). I don't know why the handling should be
different than Linux, but it could be.
> freebsd:> ldd lonewolf
> libstdc++.so.3 => /usr/lib/libstdc++.so.3 (0x282be000)
> libm.so.2 => /usr/lib/libm.so.2 (0x28303000)
> libc.so.4 => /usr/lib/libc.so.4 (0x2831e000)
> linux:>ldd lonewolf
> libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
> libm.so.6 => /lib/libm.so.6 (0x4005f000)
> libc.so.6 => /lib/libc.so.6 (0x40081000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> Uhm... I am not able to interpret this data. Are they ok ? FreeBSD is
> missing one lib, the last one...
Ignore this; it's unrelated. This is a Linux-ism for ld.so; they
do this so they can support dlopen(), etc., in static binaries.
> The problem of Makefile is not related IMHO, infact the Makefile.unix is
> the same for Linux and FreeBSD ... the most relevant part of it are:
See also /etc/make.conf, which can override this or add more
> So they should act in the same way ...
> The thing is so strange ...
It's uninitialized data. You would need to look at the object
file that the other person posted about earlier, in detail (as
noted above) in order to identify the root cause.
More information about the freebsd-hackers