Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 855736 - FTBFS on non-x86 arches
Summary: FTBFS on non-x86 arches
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: megaglest
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paulo Andrade
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2012-09-10 06:57 UTC by Dan Horák
Modified: 2013-03-31 18:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-31 18:55:37 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Dan Horák 2012-09-10 06:57:47 UTC 
megaglest doesn't build on non-x86 arches, it fails with 

...
/usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/megaglest-3.6.0.3/build/CMakeFiles 75
[  1%] Building CXX object source/shared_lib/sources/streflop/CMakeFiles/streflop.dir/libm/flt-32/s_cbrtf.cpp.o
cd /builddir/build/BUILD/megaglest-3.6.0.3/build/source/shared_lib/sources/streflop && /usr/bin/c++   -DSTREFLOP_SOFT -DCURL_STATICLIB -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -march=armv7-a -mfpu=vfpv3-d16  -mfloat-abi=hard  -O3 -O2 -g -g -O3  -DSVNVERSION="\"\"" -DCUSTOM_DATA_INSTALL_PATH="\"/usr/share/megaglest/\"" -I/builddir/build/BUILD/megaglest-3.6.0.3/source/shared_lib/sources/streflop/../../include/streflop/libm/flt-32 -I/builddir/build/BUILD/megaglest-3.6.0.3/source/shared_lib/sources/streflop/../../include/streflop/libm/headers    -Wreturn-type -fno-strict-aliasing -frounding-math  -fsignaling-nans -rdynamic -DUSE_STREFLOP -DSTREFLOP_RANDOM_GEN_SIZE=32 -DLIBM_COMPILING_FLT32 -o CMakeFiles/streflop.dir/libm/flt-32/s_cbrtf.cpp.o -c /builddir/build/BUILD/megaglest-3.6.0.3/source/shared_lib/sources/streflop/libm/flt-32/s_cbrtf.cpp
In file included from /builddir/build/BUILD/megaglest-3.6.0.3/source/shared_lib/sources/streflop/../../include/streflop/libm/headers/../streflop_libm_bridge.h:28:0,
                 from /builddir/build/BUILD/megaglest-3.6.0.3/source/shared_lib/sources/streflop/../../include/streflop/libm/headers/SMath.h:6,
                 from /builddir/build/BUILD/megaglest-3.6.0.3/source/shared_lib/sources/streflop/libm/flt-32/s_cbrtf.cpp:23:
/builddir/build/BUILD/megaglest-3.6.0.3/source/shared_lib/sources/streflop/../../include/streflop/libm/headers/../../streflop.h:57:30: fatal error: SoftFloatWrapper.h: No such file or directory
compilation terminated.
make[2]: Leaving directory `/builddir/build/BUILD/megaglest-3.6.0.3/build'
make[2]: *** [source/shared_lib/sources/streflop/CMakeFiles/streflop.dir/libm/flt-32/s_cbrtf.cpp.o] Error 1
make[1]: *** [source/shared_lib/sources/streflop/CMakeFiles/streflop.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

seen on ARM and s390(x),
full logs eg. at http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1128678
Comment 1 Paulo Andrade 2012-09-10 13:48:13 UTC 
There is some related discussion at
http://glest.org/glest_board/index.php?topic=7599.0
I will ExclusiveArch it later today; hopefully there will be an arm port soon :-)
Comment 2 Dan Horák 2012-09-10 14:09:39 UTC 
maybe it's only the missing SoftFloatWrapper.h header and no need to port when a standard Linux distro is used
Comment 3 Dan Horák 2012-09-10 14:50:07 UTC 
(In reply to comment #1)
> There is some related discussion at
> http://glest.org/glest_board/index.php?topic=7599.0
> I will ExclusiveArch it later today; hopefully there will be an arm port
> soon :-)

They speak about porting to mobile ARM platforms, while we have a full-featured Linux distro, so this kind of port shouldn't be necessary.
Comment 4 Paulo Andrade 2012-09-10 15:18:42 UTC 
(In reply to comment #2)
> maybe it's only the missing SoftFloatWrapper.h header and no need to port
> when a standard Linux distro is used

I think it should not be so easy, and/or just getting it built would be of
no help if it does not work. Actually, I learned more about megaglest
sources when making the review request; previously I was a user that played
against bots and with friends :-)
Googling I found http://spot.fedorapeople.org/streflop.spec; megaglest has
an older version (0.2) and smaller subset of it removing soft float, when
comparing to
http://nicolas.brodu.numerimoire.net/common/programmation/streflop/streflop-0.3.tar.bz2
contents.
Also as specified in the glest forum, the major problem, besides possible
issues with streflop would be the port to opengles.
Debian related bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654283

I believe upstream uses streflop for consistent floating point calculations
among different architectures and operating systems...

Looking at latest upstream sources, following instructions from
http://glest.wikia.com/wiki/MG/Getting_The_Code it appears to properly handle
it now, and would build on arm. Looking at the changelog from after 3.6.0.3
was released, I see:

------------------------------------------------------------------------
r3090 | mvejvoda | 2012-02-11 13:20:40 -0200 (Sáb, 11 Fev 2012) | 1 line

- fixed soft float support so megaglest might now work with other architectures at least in terms of streflop support
Comment 5 Paulo Andrade 2012-09-10 19:57:10 UTC 
(In reply to comment #3)
> (In reply to comment #1)
> > There is some related discussion at
> > http://glest.org/glest_board/index.php?topic=7599.0
> > I will ExclusiveArch it later today; hopefully there will be an arm port
> > soon :-)
> 
> They speak about porting to mobile ARM platforms, while we have a
> full-featured Linux distro, so this kind of port shouldn't be necessary.

Please try to check if this package builds on arm:

http://fedorapeople.org/~pcpa/855736/megaglest-3.6.0.3-6.fc17.src.rpm

it was generated from svn trunk. The version is incorrect, but should be
good enough for testing purposes and make a proper report to upstream.

It should require more refinement to actually work, but building is a
great step :-)
Comment 6 Dan Horák 2012-09-10 20:14:29 UTC 
it builds successfully on s390x so I think it will also on arm (http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1130499)

btw you can test builds on non-x86 (aka secondary) arches yourself, just do eg.
arm-koji build --scratch f18-candidate megaglest-3.6.0.3-6.fc17.src.rpm
for a test build on F-18 on ARM, replace arm with ppc or s390 for test builds on ppc/ppc64 and s390/s390x
Comment 7 Paulo Andrade 2012-09-10 23:13:28 UTC 
(In reply to comment #6)
> it builds successfully on s390x so I think it will also on arm
> (http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1130499)
> 
> btw you can test builds on non-x86 (aka secondary) arches yourself, just do
> eg.
> arm-koji build --scratch f18-candidate megaglest-3.6.0.3-6.fc17.src.rpm
> for a test build on F-18 on ARM, replace arm with ppc or s390 for test
> builds on ppc/ppc64 and s390/s390x

It appears armv7hl build failed :-( Looking after testing a x86_64
build patching it to force use of software float streflop, and
applying "svn diff -r3089:3090 > megaglest-streflop.patch", and
the failure appears almost the same...

Either way, I believe it is better to just ExclusiveArch it.
Should something be done about the noarch megaglest-data rpm?
Otherwise, I believe it is enough to only change megaglest.
Comment 8 Dan Horák 2012-09-11 06:33:21 UTC 
Ok, then it's fine to add ExclusiveArch. Unless I'm wrong then the ExclusiveArch tag is honored also for noarch package where they are not included in the repositories.
Comment 9 Paulo Andrade 2012-12-09 15:38:00 UTC 
Looks like it builds with megaglest 3.7.1

http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1289123

Can you make make a simple test to check if it also works, or
just compiles now?
Comment 10 Peter Robinson 2013-03-31 18:55:37 UTC 
I've not tested it but it builds at least.
Note You need to log in before you can comment on or make changes to this bug.