Bug 148003

Summary: does not build on x86_64
Product: [Fedora] Fedora Reporter: Thorsten Leemhuis <fedora>
Component: synceAssignee: Andreas Bierfert <andreas.bierfert>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: andreas.bierfert
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 0.9.1-2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-23 20:24:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Thorsten Leemhuis 2005-02-14 17:14:52 UTC
Description of problem:
Synce does not build on x86_64. See build log: 
http://fedoraproject.org/extras/3/build-logs/x86_64/synce.log

Relevant part:
make[4]: Entering directory
`/rpmbuild/extras/cvs/rpms/synce/devel/synce-0.9.0/synce-librapi2-0.9.0/src'
if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..  
-I/rpmbuild/extras/cvs/rpms/synce/devel/synce-0.9.0/synce-libsynce-0.9.0/lib -g
-Wall -Wsign-compare -Wno-long-long -Werror -ansi -O2 -g -pipe -m64  -Isupport
-O2 -g -pipe -m64 -MT database.lo -MD -MP -MF ".deps/database.Tpo" -c -o
database.lo database.c; \
then mv -f ".deps/database.Tpo" ".deps/database.Plo"; else rm -f
".deps/database.Tpo"; exit 1; fi
mkdir .libs
 gcc -DHAVE_CONFIG_H -I. -I. -I..
-I/rpmbuild/extras/cvs/rpms/synce/devel/synce-0.9.0/synce-libsynce-0.9.0/lib -g
-Wall -Wsign-compare -Wno-long-long -Werror -ansi -O2 -g -pipe -m64 -Isupport
-O2 -g -pipe -m64 -MT database.lo -MD -MP -MF .deps/database.Tpo -c database.c 
-fPIC -DPIC -o .libs/database.o
database.c: In function `CeReadRecordProps':
database.c:371: warning: cast from pointer to integer of different size
database.c:378: warning: cast from pointer to integer of different size
database.c: In function `PreparePropValForWriting':
database.c:414: warning: cast to pointer from integer of different size
database.c:443: warning: cast to pointer from integer of different size
make[4]: *** [database.lo] Error 1

Version-Release number of selected component (if applicable):
synce-0.9.0

How reproducible:
Always

Additional info:
The problem lies in 
http://cvs.sourceforge.net/viewcvs.py/synce/librapi2/src/database.c?rev=1.12&view=markup
The problematic part it already marked with the comments:
/* XXX: we can get problems here on 64-bit platforms */
[...]
/* TODO: convert endians on other data types! */

Does anyone whant to fix it? My programming skills are not good enough to do it
myself :-( 

Otherwise is suggest we set "ExcludeArch: x86_64" for now (maybe ppc64 also
while at it?)

Comment 1 Thorsten Leemhuis 2005-03-24 19:47:55 UTC
I commited a "ExcludeArch: x86_64" to cvs for FC-3 and devel; Leaving this bug
open to track issue.

Comment 2 Andreas Bierfert 2005-08-22 07:53:14 UTC
Hm, I commited and build 0.9.1 for fc3/fc4/devel and fc3/fc4 work just fine (at
least for the building part). Could someone with x86_64 access please verify
that the x86_64 version really works.

And if by any chance someone has a clue about this I could push devel as well:
http://buildsys.fedoraproject.org/logs//development/273-synce-0.9.1-3.fc5/i386/build.log

Same spec on fc4/fc3 works fine.

Comment 3 Thorsten Leemhuis 2005-08-23 19:01:13 UTC
> Hm, I commited and build 0.9.1 for fc3/fc4/devel and fc3/fc4 work just fine (at
> least for the building part). Could someone with x86_64 access please verify
> that the x86_64 version really works.

I don't have any proper ce-devices to test (I need those afaics). Sorry. I think
we should just close this bug. Andreas, that okay for you?

> And if by any chance someone has a clue about this I could push devel as well:
>
http://buildsys.fedoraproject.org/logs//development/273-synce-0.9.1-3.fc5/i386/build.log
> 
> Same spec on fc4/fc3 works fine.

No idea. Sorry.

Comment 4 Andreas Bierfert 2005-08-23 20:24:34 UTC
Fine with me... I guess if it does not work x86_64 users will complain ^^