[Common-dev] Resend: CR-Client - AMD 64 patches
Rob Lanphier robla at real.com-----Forwarded Message----- From: Robert M. Stockmann <stock at stokkie.net> To: common-dev at helixcommunity.org Subject: [Common-dev] CR-Client Date: Fri, 24 Sep 2004 00:28:49 +0200 Dear Developers, Please find attached a patch for the common-dev subproject to be submitted into the Helix project for peer review, as well as a README.txt with more detailed info. Patch details : =============== Modified by: Robert M. Stockmann Reviewed by: Rob Lanphier Date: Thu Sep 23 23:50:45 CEST 2004 Project: player Synopsis: Fix: add/activate amd64 as platform Files Modified: common/import/gecko-sdk/nspr/include/prcpucfg.h common/include/atomicbase.h Files Added: Image Size and Heap Use impact: Platforms and Profiles Build Verified: amd64 Platforms and Profiles Functionality verified: failure : $ export HX_DEBUGLEVEL=2 $ hxplay HX_ASSERT failed: (GetSize() == ulLength)... File hxbuffer.cpp, Line 309 HX_ASSERT failed: (GetSize() == ulLength)... File hxbuffer.cpp, Line 309 GLib-ERROR **: gmem.c:140: failed to allocate 17149707381026848842 bytes aborting... Aborted Branch: common Copyright assignment: I agree to assign to RealNetworks full copyright ownership of the code represented by the attached patch. I warrant that I am legally entitled to grant the copyright assignment and that my contribution does not violate any law or breach any contract. I understand that RealNetworks may license this code under RPSL, RCSL, and/or any other license at RealNetworks' sole discretion. QA Instructions: Regards, Robert -------------- next part -------------- Hi, After some tweaking and brute-force hacking i managed to build a 64bit clean x86_64/amd64 RPM for Mandrake 10.0 amd64. Here's how i did it, which code changes i needed and which already installed library RPMS needed to be rebuild. Who said again that a clean build doesn't mean anything? Well thats right, because the x86_64 source/binaries contain some errors. HOWTO BUILD a X86_64/AMD64/Opteron HelixPlayer amd64.rpm : ========================================================== 1. I downloaded the following SRPM from the Fedora DEV page : http://redhat.secsup.org/fedora/core/development/x86_64/SRPMS/HelixPlayer-1.0.gold-3.src.rpm 2. Just install/unpack it on disk : # rpm -i HelixPlayer-1.0.gold-3.src.rpm 3. Adjust the HelixPlayer .spec file : # vi /usr/src/RPM/SPECS/HelixPlayer.spec and make the following adjustments : #ExcludeArch: ppc64 x86_64 ppc s390 s390x ia64 <=== allow x86_64/amd64 to build ExcludeArch: ppc64 i586 ppc s390 s390x ia64 <=== exclude i586 to build #%patch3 -p1 -b filechooser <=== Comment out if you don't have Gtk2.2 add : Patch5: helix-amd64-platform.patch.bz2 <== add this as extra patch. %patch5 -p1 -b amd64 <== execute Patch5 during a RPM build 4. Build the binary amd64 RPM : # cd /usr/src/RPM/SPECS # rpm -v -ba HelixPlayer.spec .... Wrote: /usr/src/RPM/SRPMS/HelixPlayer-1.0.gold-3.src.rpm Wrote: /usr/src/RPM/RPMS/amd64/HelixPlayer-1.0.gold-3.amd64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.53193 However when trying to execute/run it i get this : $ hxplay HX_ASSERT failed: (GetSize() == ulLength)... File hxbuffer.cpp, Line 309 Aborted $ $ export HX_DEBUGLEVEL=2 $ hxplay HX_ASSERT failed: (GetSize() == ulLength)... File hxbuffer.cpp, Line 309 HX_ASSERT failed: (GetSize() == ulLength)... File hxbuffer.cpp, Line 309 GLib-ERROR **: gmem.c:140: failed to allocate 17149707381026848842 bytes aborting... Aborted $ NOTES on HOWTO BUILD a AMD64 RPM : ================================== A. Sometimes the following error is occuring during compiling : UNIXCompile(datatype/text/realtext/renderer): making copy leaving directory /usr/src/RPM/BUILD/hxplay-1.0.0.298/./datatype/text/realtext/renderer from directory /usr/src/RPM/BUILD/hxplay-1.0.0.298 entering directory datatype/ogg/fileformat UNIXCompile(datatype/ogg/fileformat): generating makefiles UMAKE: Umakefil -> Makefile in datatype/ogg/fileformat UMAKE: Applying profile /usr/src/RPM/BUILD/hxplay-1.0.0.298/build/umakepf/helix-client-all-defines-free.pf UNIXCompile(datatype/ogg/fileformat): making depend UNIXCompile(datatype/ogg/fileformat): making all ERROR: UNIXCompile(datatype/ogg/fileformat) ERROR: Make failed. --- Build System Error ------------------------------------ Make failed. ----------------------------------------------------------- From /usr/src/RPM/BUILD/hxplay-1.0.0.298/build.out we see this make error : g++ -shared oggfformat.exp -o dbg/oggfformat.so -u RMACreateInstance dbg/obj/oggfformat.o dbg/obj/ogg_page_reader.o dbg/obj/page2packet.o dbg/obj/vorbis_page2pkt.o dbg/obj/theora_page2pkt.o dbg/obj/base_page2pkt.o dbg/obj/strm_group.o dbg/obj/oggutil.o dbg/oggfformat_libs.a -L/usr/lib64 -L/usr/X11R6/lib64 -lstdc++ /usr/bin/ld: dbg/oggfformat_libs.a(libogg.framing.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC dbg/oggfformat_libs.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [dbg/oggfformat.so] Error 1 Time used: 1.18 seconds ERROR: UNIXCompile(datatype/ogg/fileformat) ERROR: Make failed. --- Build System Error ------------------------------------ Make failed. ----------------------------------------------------------- It seems that /usr/lib64/libogg.a (framing.o) is somehow being detected as a 32bit object file. But thats of course not the case. Just make sure, as is correctly suggested above, that everyting is compiled with -fPIC. To do that inside a RPM .SPEC file one can add this line inside libogg.spec : %define optflags -O2 -pipe %{debugcflags} -fPIC -DPIC This was for me also needed for libvorbis.spec. It turns out that X86_64 wants for all its dynamic libraries a global ofset, needed when linking 64bit binaries : # nm /usr/lib64/libvorbis.a | more mdct.o: U free U _GLOBAL_OFFSET_TABLE_ <== needed for linking on amd64 0000000000000000 r .LC1 0000000000000018 r .LC10 0000000000000020 r .LC11 0000000000000010 r .LC12 0000000000000014 r .LC13 0000000000000018 r .LC14 The vanilla installed ogg and vorbis libs on mandrake am64 didn't have a _GLOBAL_OFFSET_TABLE_ inside. Recompiling your SRPM with -fPIC -DPIC thus indeed gets rid of the "relocation R_X86_64_32S can not be used" error. B. Some remarks are to be made about the helix-amd64-platform.patch.bz2 which was created through trial and error. the common/import/gecko-sdk/nspr/include/prcpucfg.h diff was retrieved from CVS somehow. Google found that one for me. And of course common/include/atomicbase.h needs still to be checked so i read on the Helix website. The %rax pointer seems to be not quite ok. AMD64 assembly seems straight forward, but i have my doubts . C. The adjustments ( helix-amd64-platform.patch.bz2 ) as well as the binary and source RPM's can be be found on : http://crashrecovery.org/helixp/ Thanks best regards, Robert -- Robert M. Stockmann - RHCE Network Engineer - UNIX/Linux Specialist crashrecovery.org stock at stokkie.net -------------- next part -------------- A non-text attachment was scrubbed... Name: helix-amd64-platform.common.patch Type: text/x-patch Size: 6678 bytes Desc: not available Url : http://lists.helixcommunity.org/pipermail/common-dev/attachments/20040930/799d819d/helix-amd64-platform.common.bin