XRootD fails to build on i386

[brianhlin]

Hi, when trying to build XRootD 4.7.0 for the OSG, we noticed some failures when building for the i386 architecture. The atomics check fails:

-- Performing Test HAVE_ATOMICS
-- Performing Test HAVE_ATOMICS - Failed

Causing the following build failure:

cd /builddir/build/BUILD/xrootd-4.7.0/build/src && /usr/bin/c++   -DHAVE_CRYPT -DHAVE_ET_COM_ERR_H -DHAVE_FSTATAT -DHAVE_FUSE -DHAVE_GETHBYXR -DHAVE_GETIFADDRS -DHAVE_LIBZ -DHAVE_NAMEINFO -DHAVE_PROTOR -DHAVE_READLINE -DHAVE_SENDFILE -DHAVE_SETRESUID -DHAVE_SHADOWPW -DHAVE_SIGWTI -DHAVE_SSL -DHAVE_TLS1 -DHAVE_TLS11 -DHAVE_TLS12 -DHAVE_XML2 -DHAVE_XRDCRYPTO -DUSE_LIBC_SEMAPHORE=0 -DXRDPLUGIN_SOVERSION=\"4\" -DXrdSsiShMap_EXPORTS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D__linux__=1 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables  -std=c++0x -std=c++0x -Wall -Wextra -Werror -Wno-unused-parameter -O2 -g -DNDEBUG -fPIC -I/builddir/build/BUILD/xrootd-4.7.0/src/.. -I/builddir/build/BUILD/xrootd-4.7.0/src/. -I/builddir/build/BUILD/xrootd-4.7.0/src -I/builddir/build/BUILD/xrootd-4.7.0/build/src -I/usr/local/include    -o CMakeFiles/XrdSsiShMap.dir/XrdSsi/XrdSsiShMam.cc.o -c /builddir/build/BUILD/xrootd-4.7.0/src/XrdSsi/XrdSsiShMam.cc
/builddir/build/BUILD/xrootd-4.7.0/src/XrdSsi/XrdSsiShMam.cc: In member function 'virtual bool XrdSsiShMam::AddItem(void*, void*, const char*, int, bool)':
/builddir/build/BUILD/xrootd-4.7.0/src/XrdSsi/XrdSsiShMam.cc:319: error: 'Atomic_SET_STRICT' was not declared in this scope
/builddir/build/BUILD/xrootd-4.7.0/src/XrdSsi/XrdSsiShMam.cc:321: error: 'Atomic_SET_STRICT' was not declared in this scope
/builddir/build/BUILD/xrootd-4.7.0/src/XrdSsi/XrdSsiShMam.cc: In member function 'virtual bool XrdSsiShMam::DelItem(void*, const char*, int)':
/builddir/build/BUILD/xrootd-4.7.0/src/XrdSsi/XrdSsiShMam.cc:587: error: 'Atomic_SET_STRICT' was not declared in this scope
/builddir/build/BUILD/xrootd-4.7.0/src/XrdSsi/XrdSsiShMam.cc:589: error: 'Atomic_SET_STRICT' was not declared in this scope
/builddir/build/BUILD/xrootd-4.7.0/src/XrdSsi/XrdSsiShMam.cc: In member function 'int XrdSsiShMam::Find(XrdSsiShMam::MemItem*&, XrdSsiShMam::MemItem*&, const char*, int&)':
/builddir/build/BUILD/xrootd-4.7.0/src/XrdSsi/XrdSsiShMam.cc:796: error: 'Atomic_GET_STRICT' was not declared in this scope
make[2]: *** [src/CMakeFiles/XrdSsiShMap.dir/XrdSsi/XrdSsiShMam.cc.o] Error 1
make[2]: Leaving directory `/builddir/build/BUILD/xrootd-4.7.0/build'
make[1]: Leaving directory `/builddir/build/BUILD/xrootd-4.7.0/build'
make[1]: *** [src/CMakeFiles/XrdSsiShMap.dir/all] Error 2
make: *** [all] Error 2

[simonmichal]

Thanks for reporting the problem.

Which platform is it? slc6?

Michal

[brianhlin]

I believe our build machines are CentOS 6. @matyasselmeci?

[simonmichal]

I can see that it would fail if the atomics check fails, and as a result HAVE_ATOMICS is not defined because in the #else the 'Atomic_SET_STRICT' is indeed not defined.

However, it's rather strange that the atomics check fails, I have tested the build with 'mock -r centos-6-i386' and also it has been already built by koji and there where no problems (el6, i686):
https://koji.fedoraproject.org/koji/buildinfo?buildID=962503

[ljanyst]

It fails if you do -march=i386. But these were first produced in 1985 and abandoned completely in 2007. So, come on ;)

[matyasselmeci]

Good catch. Our Koji is set up to target i386 for 32-bit builds. I'm not sure how many things need to be changed to fix the configuration, but I've added this hack to the spec file in the meantime:

%ifarch i386                                                                                                                       
%global optflags %__global_cflags -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables                                        
%endif                                                                                                                             

which seems to work.

[simonmichal]

I suppose we can close this one?

[matyasselmeci]

Yep, I'm fine with that.