__sync_fetch_and_add_4 function missing

[bkauler-2]

Heh, heh, another difficult problem!

The problem is that many applications that compile inside T2 will not
compile outside. That is, I have a full development environemt setup
in Puppy Linux, with all the required tools that were compiled in T2.

Most packages compile, but there are major exceptions, for example I
cannot compile any XFCE or gtkmm-based applications.

What I get are error messages about '__sync_fetch_and_add_4' being an
unresolved symbol.

I have done a lot of googling, and this bug is in the 'gcc' package.
It seems that gcc/libstdc++ is treating the compile as for the
386 CPU, even though I have specified a 'i486' with the '--build'
configure option (also T2 was compiled for a 486).

One fix I cam across on the Internet is to export CFLAGS="-march=i486"
and I tried this before running configure in the Gparted package
(Gparted requires gtkmm libs). But, compiling still stops with that
same error.

At this stage I don't know what to do. The thing is though, you don't
have the problem inside the T2 build system. Does anyone know why not?
Is anything special done to avoid this problem?

Regards,
Barry Kauler



-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
lists@... with a subject of: unsubscribe t2

[René Rebe]

On 19.12.2007, at 05:22, bkauler@... wrote:

Heh, heh, another difficult problem!

The problem is that many applications that compile inside T2 will not

compile outside. That is, I have a full development environemt setup

in Puppy Linux, with all the required tools that were compiled in T2.

Most packages compile, but there are major exceptions, for example I

cannot compile any XFCE or gtkmm-based applications.

What I get are error messages about '__sync_fetch_and_add_4' being an

unresolved symbol.

I have done a lot of googling, and this bug is in the 'gcc' package.

It seems that gcc/libstdc++ is treating the compile as for the

386 CPU, even though I have specified a 'i486' with the '--build'

configure option (also T2 was compiled for a 486).

One fix I cam across on the Internet is to export CFLAGS="-march=i486"

and I tried this before running configure in the Gparted package

(Gparted requires gtkmm libs). But, compiling still stops with that

same error.

At this stage I don't know what to do. The thing is though, you don't

have the problem inside the T2 build system. Does anyone know why not?

Is anything special done to avoid this problem?

I never encountered this problem, although I did 486 builds

even this year.

Gfor the sandbox builds and the generic mechanisms such

as program argument transformations used by T2 every

compiler invocation gets the specified optimizations, such as

-mcpu=i486 et al. injected automatically. No matter what might

be encoded in some Makefile, scons or shell script. This might

be why it just builds with T2 and something is missing or wrong

in manual builds.

All the best and happy christmas,

-- 

  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin

  Geschäftsführer: Susanne Klaus, René Rebe

  Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B

  USt-IdNr.: DE251602478

  http://exactcode.de | http://t2-project.org | http://rene.rebe.name

-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
lists@... with a subject of: unsubscribe t2

[bkauler-2]

>
> On 19.12.2007, at 05:22, bkauler@... wrote:
>
>>
>> Heh, heh, another difficult problem!
>>
>> The problem is that many applications that compile inside T2 will not
>> compile outside. That is, I have a full development environemt setup
>> in Puppy Linux, with all the required tools that were compiled in T2.
>>
>> Most packages compile, but there are major exceptions, for example I
>> cannot compile any XFCE or gtkmm-based applications.
>>
>> What I get are error messages about '__sync_fetch_and_add_4' being an
>> unresolved symbol.
>>
>> I have done a lot of googling, and this bug is in the 'gcc' package.
>> It seems that gcc/libstdc++ is treating the compile as for the
>> 386 CPU, even though I have specified a 'i486' with the '--build'
>> configure option (also T2 was compiled for a 486).
>>
>> One fix I cam across on the Internet is to export CFLAGS="-march=i486"
>> and I tried this before running configure in the Gparted package
>> (Gparted requires gtkmm libs). But, compiling still stops with that
>> same error.
>>
>> At this stage I don't know what to do. The thing is though, you don't
>> have the problem inside the T2 build system. Does anyone know why not?
>> Is anything special done to avoid this problem?
>
> I never encountered this problem, although I did 486 builds
> even this year.
>
> Gfor the sandbox builds and the generic mechanisms such
> as program argument transformations used by T2 every
> compiler invocation gets the specified optimizations, such as
> -mcpu=i486 et al. injected automatically. No matter what might
> be encoded in some Makefile, scons or shell script. This might
> be why it just builds with T2 and something is missing or wrong
> in manual builds.
>
> All the best and happy christmas,
>
> --
>    René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
>    Geschäftsführer: Susanne Klaus, René Rebe
>    Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B
>    USt-IdNr.: DE251602478
>    http://exactcode.de | http://t2-project.org | http://rene.rebe.name
>

Ok, we have a fix. Not a solution though.

One of our Puppy developers, kirk, recompiled gcc, and that fixed it.
He did it in Puppy, not in T2, and just did a simple './configure' and
'make' on the pristine gcc-4.2.2 source.
Then he successfully compiled 'rutilt', that had previously stopped
with that dreaded '__sync_fetch_and_add_4' missing function.

So, I repeated the experiment, but I followed T2 a bit more closely.
That is, I compiled manually in Puppy, which has all the build tools
that were compiled in T2, and did the following:

I got some of the patch files out of T2 and applied those:
# patch -p1 < ../fixincl.patch
# patch -p1 < ../libstdcpp-with-tag-cc.patch
# patch -p1 < ../no-install-libiberty.patch

I examined the 'gcc.log' file for stage 1 in T2, which contains this:
../configure --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libdir=/usr/lib --datadir=/usr/share --includedir=/usr/include
--infodir=/usr/info --mandir=/usr/man --sysconfdir=/etc
--localstatedir=/var --disable-debug --without-libpam --without-pam
--disable-libpam --disable-pam --build=i686-nocross-linux-gnu
--host=i486-t2-linux-gnu --enable-__cxa_atexit --disable-checking
--disable-bootstrap --disable-libstdcxx-pch --disable-multilib
--enable-languages=c,c++ --disable-libmudflap --cache-file=./config.cache

I modified that slightly, as follows:
# mkdir objdir
# cd objdir
# ../configure --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libdir=/usr/lib --datadir=/usr/share --includedir=/usr/include
--infodir=/usr/info --mandir=/usr/man --sysconfdir=/etc
--localstatedir=/var --disable-debug --without-libpam --without-pam
--disable-libpam --disable-pam --host=i486-t2-linux-gnu
--enable-__cxa_atexit --disable-checking --disable-bootstrap
--disable-libstdcxx-pch --disable-multilib --enable-languages=c,c++
--disable-libmudflap
# make
# make install

I then compiled 'gparted', another package that previously had failed
due to missing '__sync_fetch_and_add_4', and this time it compiled ok.

So, why is this happening? Surely not because of the '--build' in T2
being different from the '--host'? I'm puzzled.

I've got new shared libraries installed now, for example
'libstdc++.so.6.0.9' and I notice they are a lot bigger than those
that were compiled in T2. I have run a few apps (that were compiled
in T2) and they all still work.

Although I have a fix, this is not a desirable situation. It should
not be necessary to have to recompile gcc afterward to get it to work
properly outside the T2 build environment.

Regards,
Barry Kauler



-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
lists@... with a subject of: unsubscribe t2