From: Ivan K. <ch...@ya...> - 2008-04-08 20:03:17
|
On Tuesday 08 April 2008 02:41, Gilles Espinasse wrote: > ----- Original Message ----- > From: "Ivan Kabaivanov" <ch...@ya...> > To: <ipc...@li...> > Sent: Monday, April 07, 2008 10:36 PM > Subject: Re: [IPCop-devel] [2.0] sparc build glibc-2.7 failure > > > On Monday 07 April 2008 15:58, Olaf Westrik wrote: > > > Gilles Espinasse wrote: > > > > Looking for glibc config.log, I find with-cpu=v8 > > ... > > > yes, I have the same error, but I didn't spend as much time as you did > > searching for a solution. > > > > I'm not 100% sure but probably the non-standard C2FLAGS variable was > > added > > to > > > complement the standard CFLAGS (maybe some packages needed extra CFLAGS > > which > > > broke others and this way we could selectively add the extra flags to gcc > > and > > > then we merged CFLAGS with C2FLAGS but didn't fix the name?) Or we > > wanted > > to > > > differentiate our flags? I'm not sure and I'm just guessing. However it > > doesn't actually matter if the variable is called C_IPCOP_FLAGS because > > the > > > the way we pass it to the make functions is CFLAGS="${C2FLAGS}". So the > > lfs/* scripts see CFLAGS, not C2FLAGS. > > Looking on cvs, this was changed by Alan on rev 1.139 with no so much > comment on this. > Should we not revert to standard usage if there is no gain not to use > canonical names? > I only know the time I loose to understand what special meaning this has. I'm with you here. It may be a bit confusing to people why we use C2FLAGS instead of CFLAGS. It's a trivial change in make.sh which will not break anything. A simple sed -i -e "s,C2FLAGS,CFLAGS,g" -e "s,CXX2FLAGS,CXXFLAGS,g" make.sh will suffice. > > As a notice, reading glibc log (I don't remember the arch), there is > actually some ugly -O2 -pipe -O2, or even -O2 -O2 -pipe -O2 > It may not break. I'm not 100% sure, but I suspect this is harmless even if it's ugly. I suppose gcc ignores duplicates, as long as there are no conflicting flags, in which case we would have gotten an error. I think it's unavoidable actually as some packages (maybe most) append to CFLAGS rather than override it completely. We can track down which ones add the duplicate flags and for those packages, clear our CFLAGS. > > > About linux32 breaking proper machine identification, I'm not sure. > > Maybe linux32 does force 32bit cpu personality by claiming to be a v8 > > machine, which the new glibc doesn't like... > > > > Olaf, > > > > we are building a 64bit kernel and 32bit userland on sparc as has been > > the advice of most, if not all, sparc kernel gurus. We are not going to > > support > > > 32bit sparc (pre v9 machines). > > > > I've removed -mcpu=v9 from the sparc CFLAGS to see if perhaps it helps. > > I added it there in the first place because if not specified gcc sets > > mcpu=v7. > > > And v7 code runs anywhere between 25%-50% slower on v9 machines. I'm > > doing a > > > test build without -mcpu=v9 now so let's see if it helped at all. > > I have tested removing linux32 on sparc64 (still break on glibc a bit > later) log_sparc64# grep v8 *.log > nothing > > Error message is > _build_01_toolchain.log:TARGET_CPU_DEFAULT="TARGET_CPU_v9" \ > _build_01_toolchain.log:../sysdeps/sparc/sparc64/memset.S:248: (Requires > v9a|v9b; requested architecture is v9.) > _build_01_toolchain.log:../sysdeps/sparc/sparc64/memset.S:251: (Requires > v9a|v9b; requested architecture is v9.) > > The recommended solution found on > http://sourceware.org/ml/crossgcc/2004-04/msg00094.html > was to use -mcpu=ultrasparc3 instead of v9 > > Gentoo safe cflags page > http://gentoo-wiki.com/Safe_Cflags#Sparc_64 > recommend > CHOST="sparc-unknown-linux-gnu" > CFLAGS="-mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe" > CXXFLAGS="${CFLAGS}" > > I would follow that advice and > test -mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe > I tried that (-mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe) and I got the same mistake. What I will do is try to compile LFS-dev on sparc and see if I can get it working, just to get our build system out of the list of potential suspects. If I can compile it, then I'll try to put it back into our build system. > I am afraid it would be too simple to try building directly 32bit on > sparc64. > The normal way could be to compile everything multi-lib 64bit then compile > 32bit lib. > My understanding is this is what CLFS do. > I think it is too complicated for us and would be happy to have a sparc64 > port working even if 64bit compiled only. > That would be far faster to compile. > > Gilles The thing is, it used to work prior to the glibc-2.7 switch. So it's some new behavior in glibc-2.7 that causes this failure. IvanK |