> > On 19.12.2007, at 05:22, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of: unsubscribe t2
