Linux - Compile Guide and Support

[arcum42]

Number 14 I'd already taken care of, but I went ahead and applied the other patches to the trunk.

If you try to actually play a game, you'll see the big reason why the cmake build isn't supported, btw; it crashes when initializing the graphics plugin. I never quite figured that one out, which is why the file lists have been drifting behind.

For that matter, I never got around to creating a cmake build for spu2-x. It actually works fairly nicely in Linux right now.

Thanks for the patches, in any case. If you come up with anything else to help get it working, let me know. I rather want the cmake build working for source-based distributions. And, of course, I'm the only one working on pcsx2 that uses Linux, so any help is always appreciated...

[gregory]

If the code can run with codeblock, it must be able to work with cmake (I hope). Did you try to look ldd output to see missing library in cmake libzerogs binary versus codeblock ?

I do not exactly have a crash but a freeze. But I m not sure that my iso is correct neither my configuration. I will try to dig further to have a better system then maybe fire gdb if still does not working. But I had a crash when clicked ok on the zerogs plugin configuration (rev 2892).

***** the end of my log. I thinks it is the same error.
Initializing plugins...
Init GS
*****

I agree with you a cmake build will be good for distribution and also users. It feels much more easier than autotools. I thinks the others problem for distribution will be the dependence with 3rdparty. In my opinion, there will probably be more linux developer if pcsx2 is integrate in distributions.

Note on previous patches: 8 & 13, it still needed to update plugins/CMakeLists.txt & cmake/SearchForStuff.cmake to enable the new plugins (zeropad & cdvdiso).

[arcum42]

There ought to be a way; I just haven't found it yet. Looks like there may have been an issue with building zlib, but fixing that yielded the same result. All the libraries were there in ldd, though.

And actually, you're right, it was a freeze rather then a crash. (And, ironically, the distribution I actually use would be one of the ones that would need the cmake build system working...)
And we actually used to use autotools. It broke when we migrated to wxwidgets, with the new file structure, and I was having too many hassles trying to get it to be flexible enough to work with our current file structure. Cmake seems much nicer...

The 3rdparty library dependencies aren't as bad as they could be. At least half of those libraries are only used on the Windows side. And I could probably make it use the system copies of zip & bz2. Soundtouch used to be fairly exacting for which version it was on, so that I might want to keep using the built in copy.

Zeropad's mostly supplanted by onepad, which is essentially zeropad with a bunch of code rewritten, so it isn't really critical, and most of what cdvdiso does is duplicated internally, so all it's really needed for now is blockdumps, but I'll take care of that...

[gregory]

Ok for the plugins.

I more or less found the culprit for the problem of the zerogs plugins. I try to mix codeblock build and cmake build. The freeze does not happen with pcsx2 in codeblock and others (plugin, utility, x86 emitter) in cmake. So I compare link flag between process, the major difference was -rdynamic. I modify link.txt to remove it. Now the freeze is gone. I have others error after but I thinks it because I do not have a clean environement. Maybe could you try in your side if you have some free time.

Now the good questions are : where this flag appears ? Was does it do ? Usefull or not ?

I agree with you Cmake is really nicer than autotools. (first time I use cmake)

May I ask you which distribution are you using ? Gentoo ?

EDIT: after digging man page
As a quick workaround you could add the line below in the end of pcsx2/CMakeLists.txt. Xlinker force the option --no-export-dynamic to the linker. It does the contrary of -rdynamic (which give the option --export-dynamic to the linker).
set(CMAKE_EXE_LINKER_FLAGS "-Xlinker --no-export-dynamic")

[arcum42]

That's great. I'll play with it and see the best way to suppress that flag. I did some googling, and it seems that cmake automatically adds that flag into the project for you.
I can see that way back in 0.9.1, the automake files actually had a routine in them to automatically *remove* rdynamic, so I'm sure that's the issue.

This is the first time I've used cmake as well. In fact, the current CMake build system was contributed by Athostr as a work in progress, though I went over it and fixed a bunch of stuff before committing it. I like it, though every so often I run into issues.

And, yes, I'm using Gentoo, though technically at this point, it's Funtoo, since I used one of the ~amd64 funtoo stage files on my last reinstall[1], and am using the funtoo git repository. Arch is probably the next distribution I'd go to if I wasn't going to use Gentoo. Though I have Ubuntu on a local file server out of inertia, and my eeePC has eeebuntu on it (with an ssd drive and a rather slow processor, I figure it isn't really meant for a compile-based distribution.)

And from some discussion I found, it looks like if I set CMAKE_SHARED_LIBRARY_LINK_C_FLAGS & CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS, it'll get rid of the -rdynamic that is normally tacked on them...

[1] I added a bigger hard drive, was re-partitioning everything, and decided it'd be easier to reinstall the os and then copy my old files over. It was a good chance to get rid of some clutter...

[gregory]

Ok nice.

I also find the difference between codeblock and cmake with the inlining problem in release mode. The cmake build has a define on NDEBUG. It does not appear in codeblock. The macro seems to only impact ./common/include/Pcsx2Defs.h. It appears from a magical hat It is maybe a special reserved macro.

The macro seems to change the behavior of inlining. I do not know if it must be enabled (to really do the inlining, in this case the code does not work) or no (as codeblock, in this case maybe rename the macro). Do you have any idea on the subject ?

Hopefully we progress to make cmake usable

Edit:
Well, I found when it appears. Default C flags are not properly unset.
Line like set(CMAKE_C_FLAGS_DEBUG) must be replace with set(CMAKE_C_FLAGS_DEBUG "")
There is some others options sill present "-g -O2 -pthread", general variable CMAKE_C_FLAGS and CMAKE_CXX_FLAGS must be also clean.

[gregory]

Ok nice.

I also find the difference between codeblock and cmake with the inlining problem in release mode. The cmake build has a define on NDEBUG. It does not appear in codeblock. The macro seems to only impact ./common/include/Pcsx2Defs.h. It appears from a magical hat It is maybe a special reserved macro.

The macro seems to change the behavior of inlining. I do not know if it must be enabled (to really do the inlining, in this case the code does not work) or no (as codeblock, in this case maybe rename the macro). Do you have any idea on the subject ?

Hopefully we progress to make cmake usable

Edit:
Well, I found when it appears. Default C flags are not properly unset.
Line like set(CMAKE_C_FLAGS_DEBUG) must be replace with set(CMAKE_C_FLAGS_DEBUG "")
There is some others options sill present "-g -O2 -pthread", general variable CMAKE_C_FLAGS and CMAKE_CXX_FLAGS must be also clean.

Please find attached some patches againts rev 2943
* 01 -> add a minor check to avoid some problem if you have svn client without using svn repository
* 08,13 -> properly add zeropad and cdvdiso to be complete.
* 16 -> properly set default flags. Note I puts a '-pthread' in common flags do not know if it must be kept. It seems not bad. Note it also unsets NDEBUG see above for the impact.

Cheers,

[arcum42]

Hmm. Actually, that looks like a bug in the codeblock projects as well, then. NDEBUG should be set if it's not a debug build. Of course, given that the default build in cmake is a debug build, it shouldn't be set there. I'll have to go ahead and just uninline anything that complains.

What I'm sure happened is there was a tangled mess in there a while back that was making it so some builds of pcsx2 required a debug build of wxwidgets, where others required a release version. I straightened it out, but I think I deleted one too many definitions from the project at the time.

Oh, and the reason why it adds both always_inline and unused is because a lot of times it's being used in functions in headers, and doing it this way suppresses warnings about unused functions in that particular case.

Hopefully my last commit will straighten that out. I went ahead and enabled the zeropad and CDVDiso builds as well...

Edit: Didn't see your last post. I'll go ahead and make some of the changes from that patch, but probably wont get to it till tomorrow. (Tonight for me, but it'll be past midnight.)

[gregory]

Ok no problem. We are not in hurry.

In any case defaulf cflags must be cleared because it adds some -02 or -03 that causes some crashes. Note it would be a good idea to also clear the flags in plugins.

Just for information. When I uninline GetMemPtr in spu-2X is got problem during the loading of the plugins because it does not found GetMemPtr symbol. It missing some definitions I think.


With all this changes I get after FFX intro without crash. So I thinks big bug are gone.

[arcum42]

Yeah, the major one is gone. And I've committed the changes...

And I've had issues with -O2 before. In fact, when gcc 4.4.0 first came out, having so much as -O1 would make it unstable. The reason why I have such an odd list of optimization flags is that I took all the flags comprising -O2, and removed things till it was stable. By now, theres a decent chance that I could just do -O2 instead...

Spu2-x was rather touchy when I was creating a code::blocks project for it, and that's actually the only working build system for it. The automake files in there shouldn't be used for reference, as they are from my first, failed attempt to port it. (Hmmm... I should delete those, thinking about it.)

And right now it looks pretty good. If we can get spu2-x and zzogl-pg with working cmake builds, It'll start to be comparable with the codeblocks build.