Patch file to comply with Fedora build policy

[GoogleCodeExporter]

Hi, I'm packaging PSCX2 for rpmfusion repository, which handles the stuff that 
doesn't fit in Fedora's policies like emulators, proprietory software etc etc.

In order to comply with package build policies I must patch the source to 
change the CFLAGS that pcsx2 builds against, specicially I must strip out -m32. 
Because I have patched the source, the rule from rpmfusion is that I file a bug 
report with upstream to explain the patch, as explained in the rpmfusion review 
here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2455

I am patching the source like so.....

#patch to alter cflags in build and strip out -m32 to comply with fedora build 
policy
--- pcsx2-1.1.0/cmake/BuildParameters.cmake
+++ pcsx2-1.1.0/cmake/BuildParameters.cmake
@@ -94,7 +94,7 @@
 # Set some default compiler flags
 #-------------------------------------------------------------------------------
 set(DEFAULT_WARNINGS "-Wno-write-strings -Wno-format -Wno-unused-parameter -Wno-unused-value -Wstrict-aliasing -Wno-unused-function -Wno-attributes")
-set(DEFAULT_GCC_FLAG "-m32 -msse -msse2 -march=i686 -pthread 
${DEFAULT_WARNINGS}")
+set(DEFAULT_GCC_FLAG "-msse -msse2 -march=i686 -pthread ${DEFAULT_WARNINGS}")
 set(DEFAULT_CPP_FLAG "${DEFAULT_GCC_FLAG} -Wno-invalid-offsetof")

 #-------------------------------------------------------------------------------

Obviously this bug has no impact on anyone very much. I don't know much about 
CFLAGS (I'm barely a competent packager) so don't know if this 'issue' can be 
rectified. Meantime, thanks for the great software - and I'm really hoping this 
report is clear !

Original issue reported on code.google.com by gbirchle...@gtempaccount.com on 25 Jun 2013 at 10:11

[GoogleCodeExporter]

-m32 force gcc to generate 32 bits code even on 64 bits machine. Without this 
flags it won't build anymore on 64 bits machine.

What is the issue exactly on fedora? FYI, on debian you need to depends on 
gcc...-multilib to allow -m32/-m64 flags.

Original comment by gregory....@gmail.com on 26 Jun 2013 at 6:07

• Added labels: OpSys-Linux, Priority-Low, Type-Other
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Maybe you can come up with a build system check for this. Somehow disable 
building on x64 systems until the user has allowed the -m32 flag.

Original comment by ramapcsx2.code on 27 Jun 2013 at 11:29

[GoogleCodeExporter]

Well, I think they reach a 'status quo' on the rpmfusion review. Gbirchley can 
you confim me it is ok and that I can close the bug.

Original comment by gregory....@gmail.com on 28 Jun 2013 at 6:28

[GoogleCodeExporter]

Yes it looks like I was misadvised over -m32.
However, I have now added a patch to strip out the optimsation cflags that are 
already applied with -O2. I have packaged with this, but haven't tested the 
executable at all, so please leave the bug open and I'll update when I'm tested 
that pcsx2 will execute as normal.

The patch is as follows:

#Alter optimisation cflags to strip out those already automatically specified
#by %%cmake rpm macro (which uses -o2) 
--- pcsx2-1.1.0/pcsx2/CMakeLists.txt
+++ pcsx2-1.1.0/pcsx2/CMakeLists.txt
@@ -33,44 +33,8 @@ set(DebugFlags

 # set optimization flags
 set(OptimizationFlags
-   -falign-functions
-   -falign-jumps
-   -falign-labels
-   -falign-loops
-   -fcaller-saves
-   -fcprop-registers
-   -fcrossjumping
-   -fcse-follow-jumps
-   -fcse-skip-blocks
-   -fdefer-pop
-   -fdelete-null-pointer-checks
-   -fgcse
-   -fgcse-lm
-   -fif-conversion
-   -fif-conversion2
-   -fmerge-constants
-   -foptimize-sibling-calls
-   -fpeephole2
-   -fregmove
-   -freorder-blocks
-   -freorder-functions 
-   -frerun-cse-after-loop
-   -fsched-interblock
-   -fsched-spec
    -fstrict-overflow
-   -fthread-jumps
-   -ftree-ccp
-   -ftree-ch
-   -ftree-copyrename
-   -ftree-dce
-   -ftree-dominator-opts
-   -ftree-fre
-   -ftree-lrs
-   -ftree-pre
-   -ftree-sra
-   -ftree-ter
-   -ftree-vrp
-   -funit-at-a-time)
+   -ftree-lrs)

 # Debug - Build
 if(CMAKE_BUILD_TYPE STREQUAL Debug)

Original comment by gbirchle...@gtempaccount.com on 30 Jun 2013 at 1:54