Linux - Compile Guide and Support
#41
About NDEBUG and default flag for building :
+ I think NDEBUG must be also added in plugins flags (both codeblock and cmake). Be aware that you will get another bunch of inline problem. In file common/include/PS2Eext.h and /plugins/zerogs/opengl/zerogs.cpp and probably in others plugins that are not yet in cmake (however can be check with codeblock).

+ I think it will also a good idea to clear flags in plugins like we done in pcsx2 cmake file to avoid bad surprise.


I was trying to look into spu2-x. I look into the codeblock xml. It is normal there is no optimization (code is new I thinks), maybe the reason that it was working on codeblock and not autotools ? There is a linking on libUtilities.a and libx86emitter.a is it an intended behavior ? For consistence, the moving of plugins/spu2-x/src/3rdparty/liba52 into the main 3rdparty directory would be a good idea.
Reply

Sponsored links

#42
Hi arcum42,

I have made some progress on the plugin side.
* zzogl is tested ok. The trick was to clear CMAKE_SHARED_LIBRARY_CXX_FLAGS variable to remove fpic option because it breaks some ASM (maybe it would be better to fix the asm I think)

* spu2x is another story. I attached the cmake and some testing hack to build against my library distribution. I attached the hack only for testing does not integrate it (it will broke windows version moreover). Note the detection of liba52 is basic for the moment, but it is not the major problem.

Actual status in debug mode it crashes with :
0xee602612 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at /home/gregory/tmp/debian_packaging/pcsx2_package/package/pcsx2.snapshot-2957/plugins/spu2-x/src/Linux/Config.cpp:48
48 u32 OutputModule = FindOutputModuleById( PortaudioOut->GetIdent() );

Howerever I found a strange solution to get it work. I change the .o order in compilation flag Smile

BAD
/usr/bin/c++ -fPIC -shared -Wl,-soname,libspu2x.so -o /tmp/libspu2x.so CMakeFiles/spu2x.dir/*.o CMakeFiles/spu2x.dir/Linux/*.o ../../../common/src/Utilities/libUtilities.a ../../../common/src/x86emitter/libx86emitter.a -lasound -lportaudio -lportaudiocpp ../../../3rdparty/SoundTouch/libSoundTouch.a -la52 -m32 -pthread -lwx_baseu-2.8 -lwx_gtk2u_core-2.8 -lwx_gtk2u_adv-2.8

GOOD
/usr/bin/c++ -fPIC -shared -Wl,-soname,libspu2x.so -o /tmp/libspu2x.so CMakeFiles/spu2x.dir/Linux/*.o CMakeFiles/spu2x.dir/*.o ../../../common/src/Utilities/libUtilities.a ../../../common/src/x86emitter/libx86emitter.a -lasound -lportaudio -lportaudiocpp ../../../3rdparty/SoundTouch/libSoundTouch.a -la52 -m32 -pthread -lwx_baseu-2.8 -lwx_gtk2u_core-2.8 -lwx_gtk2u_adv-2.8

Now it is over my skill. Fast google suggests bad constructor/destructor calling order. We surely know C++ better than me. Do you have any idea ?

Edit:
If you change the .o order you have the same error in codeblock. The reason it is working in codeblock by default, it is because codeblock puts all .o in one directory. With luck .o in that come from Linux directory are in the begin due to the naming convention.

Edit 2:
I just had one stupid idea. The worst, it is working Smile We can change the link order in cmake, just need to change add_library call order. See lines below. Be aware that it mask some potential problem.
add_library(${spu2xName} SHARED
${spu2xLinuxSources}
${spu2xLinuxHeaders}
${spu2xSources}
${spu2xHeaders})
Reply
#43
As far as the assembly in zzogl, I'm actually aware that fpic breaks it, since that used to be an issue in automake as well. Fixing the assembly is a good idea; I've just avoided it because I'm not exactly good at assembly...

And you know, as far as spu2-x, while it works pretty well, it was still recently ported to Linux, and still has some legacies from that. On the line you mentioned, try changing it to "u32 OutputModule = 0;", and see if it works without the hacks. ^_^

You see, it actually is supposed to set OutputModule when reading it's ini file, and has goes in there for setting the default if it's not there. But when I was first porting it, I had to hard code the value, because the ini code wasn't working. Sad

At this point the ini code actually works now, so that shouldn't be an issue.

And thanks for the patches. That takes care of a bunch of the things I was going to work on this weekend, actually...
Reply
#44
I'am afraid that you will have to find another activity for this weekend Wink Note my patches can stil be improved however.

Yes the fix on spu2-x is working.

Well I thinks there is still plenty work.
* Finish to port others plugins
* polish search for stuff in cmake
* Fix the stripping with an option (like CMAKE_BUILD_TYPE in previous version) to enable/disable it. Can do it.
* Build on amd64 without chroot (seems to be fine on my system Wink but one part of is a bit hackish in cmake) But I can still send you the good part.
* Then clean autobuild, build scripts etc... and use cmake ^^

I will try to look into the assembly but I did not promess to be successful. It can impact performance. Actually fpic reserves the register ebx so we are short in registers in this silly architecture.
Reply
#45
Yeah, there are actually plenty of other things to do. If nothing else, zzogl needs tons of work. And I still have to adjust, test, and commit the patches, in any case.

And having it build without a chroot will be nice, actually. Though I've gotten very used to firing up a chroot every time I work on pcsx2...
Reply
#46
Please find attached some patches agains rev 2957 (and my others patches, expect some fuzzing)

20_strip_flags.patch: fix the stripping and add an option to control it. Handy for distribution. Default value is enable for release mode.

08_fix_asm_with_fpic.patch: I change the register ebx to another namely esi. I think it will be ok but it will need more test. I have some crash with zzogl in eeRecDispatchers so I did not test a lots however it is not related. Maybe the cmake file or my svn repository is already too old.

** Building without chroot
02_cmake_force_32bit_link.patch: force the linker in 32 bits mode so it pick 32 bits library
Note cmake still find library in the /usr/lib but it call the linker with -lLIB. Fortunately the linker take the good arch library.

99_hack_for_32bit_mode.patch: Here the bad thing ! I thinks it will not work on 32 bit chroot in 64bits. And it probably does not work on all system.
What it does. Wx needs some specials include for the configuration (-isystem option of make). The problem is cmake will take the 64 bits versions. So I changed the patch with a replace to take the 32 bits versions. It is just to show the core problem.

For completeness it works but I have some error message due to bad 32 bits library I think. It concers gvfs in glib but I do not thinks we use it in pcsx2 anyway. So expect message like:
Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so
/usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64
Reply
#47
Hi,

I was trying to convert CDVDisoEFP to cmake and I found an interesting problems (yet another one Wink).

In the plugin there is an include of a local "version.h" but unfortunately it take the file "/usr/include/alsa/version.h"... SearchForStuff.cmake puts all includes directories for all libraries founds then its impacts all sub-cmake. In this case I thinks there are 2 possibilities.
1/ Eithers move the include command in cmake related plugins/exe.
2/ Rename version.h to avoid a conflict with others include file. Note there is potentially others file in this situation.

What do you think is better ?
Reply
#48
To be honest, I don't even build CDVDisoEFP. LinuzCDVDiso is better then efp, and there wasn't really any reason to use efp instead, iirc. The other efp one is included in case anyone wants to run from a dvd instead of an iso, and I haven't even looked at that one for a while.

With the current state of the emulator, though, usually you run the iso straight from pcsx2 without a plugin. The only times you really need a cdvd plugin is:
a) To make a dump file.
b) To run from a dvd instead of an iso.

I'd have no issue with renaming the file, or even copying the code from it into another header; I'm just not sure there's a point in getting that particular plugin where it will build, since I haven't been planning on including it in the next version.

I was planning on including all the null plugins, linuz iso, zzogl, spu2-x, zerospu2, onepad, probably efp polling, and possibly zeropad. PeopsSpu2, ZeroGS, and EFP iso seem a bit pointless to include, and any other plugins in the list don't compile in Linux...

(And I ended up not feeling in a coding mood most of the weekend, and didn't really get anything done. Main thing is that I want to be sure any changes I make don't break Windows compiling.)
Reply
#49
Yes no worry. Actually it was my third option anyway.

Just for information it also happens in CDVDlinuz (which I think is efp polling). Anyway it is clearly a low priority. I just wanted to dig a little further to have an overview of all eventual issues.

To sum up the possible remaining issue in cmake.
* spu2x does not like optimization of libx86emitter.a and libUtilities.a in cmake do not know in codeblock. I will try to dig a bit more.
* zzogl have some crashes. Done see edit

I know that this 2 plugins need tons of work. Actually my purporse is to have cmake fully working witout regression so we can really use it.

Edit: Sorry Blush it seems I missed some flags in zzogl cmake. Probably the crash when code is optimized.

Edit2: Please find a patch agains my previous one. It set same flags as codeblock for zzopengl. Fortuanely if fix my crash.
Reply
#50
Its likely. My original codeblock project file for zzogl generated a version of the plugin that crashed all the time, and I had to go over the list of flags very carefully to fix it.
If in doubt on that one, refer to the automake file, since that's been working properly longer then the codeblock file...
Reply




Users browsing this thread: 1 Guest(s)