Problem to build in Canonical Launchpad, since PPSSPP uses compiled static libraries in the source code (ffmpeg)

[sergiobenrocha2]

Edit: There is a problem to build packages in Launchpad with binary at source, like static libraries (.a files from ffmpeg/linux/x86_64/lib for example). It is possible to build debian/ubuntu package in a local machine, but not in Launchpad servers.

Old: I'm having problems to make a package in a new/clean Linux environment. It seems that gcc is searching libs from the system, not from the ppsspp code. I had a problem with glew (see the first link), and I had to install libglew-dev to successfully make the package.

libglew-dev: http://pastebin.com/SKJc86WR

ffmpeg/libav: http://pastebin.com/skwvnjUE

I think you should substitue <> to "" when you are want to use own library from ppsspp, i don't why gcc does not do it. See native/gfx/gl_common.h file, instead of:

include <GL/glew.h>

It should be:

include "GL/glew.h" or even #include "native/ext/glew/GL/glew.h", I don't know.

[xsacha]

It works on my system (glew not installed) but perhaps it should be "GL/glew.h" since it is always a build-in. Also, to be more explicit for ffmpeg libs they could either be wrapped in -Bstatic or use full paths.

[hrydgard]

Yeah, should be GL/glew.h with "native/ext/glew" as an include path. Feel free to fix it up and send a pull request.

[sergiobenrocha2]

I already changed:

native/ext/glew/GL/glxew.h native/ext/glew/glew.c native/ext/glew/glewinfo.c native/ext/glew/visualinfo.c native/gfx/gl_common.h native/gfx_es2/gl_state.cpp Core/HLE/sceAtrac.cpp Core/HLE/sceMpeg.cpp Core/HW/MediaEngine.cpp Core/HW/SimpleAudioDec.cpp

https://github.com/sergiobenrocha2/native/compare/hrydgard:master...master https://github.com/sergiobenrocha2/ppsspp/compare/ffmpeg-and-glew-issues

For glew it worked, but not for ffmpeg. Take a look at the log error, at the end: https://launchpadlibrarian.net/180330058/buildlog_ubuntu-trusty-amd64.ppsspp_0.9.8.git.20140719.1~ubuntu14.04.1_FAILEDTOBUILD.txt.gz

Maybe I should change Qt/Native.pro ? There are entries for glew for example, but not for ffmpeg.

[xsacha]

Why did you change the include to ../ext/glew/..? This path is already in include path. "GL/glew.h" works fine.

[xsacha]

Try now. I wrapped ffmpeg libs in a static link.

[sergiobenrocha2]

Didn't worked, same problem.

I tested in 0.9.9 tarball. Do I have to change files in Core/HW and Core/HLE ?

[sergiobenrocha2]

I think I found why in launchpad it does not work. Bzr ignores static library, like the *.a files in ffmpeg/linux/x86_64/lib/ , so you have to add they manually.

Btw, why these libraries are not compile together with all code?

[sergiobenrocha2]

Even with these files in the code, Launchpad complains about missing ffmpeg dependence. This is the last fail log: https://launchpadlibrarian.net/180616209/buildlog_ubuntu-trusty-amd64.ppsspp_0.9.9-0ubuntu2~ubuntu14.04.1_FAILEDTOBUILD.txt.gz

[unknownbrackets]

It works with our travis script, so it ostensibly builds on a clean Ubuntu / linux environment.

Maybe something is filtering out / "cleaning" binary files before the build. You can build ffmpeg every time if you like, but it will definitely increase the build time. Otherwise, you need to debug your build e.g. ls the directory or something.

-[Unknown]

[sergiobenrocha2]

I sent to Hrydgard the builded packages from my machine, 0.9.9 version, i386 and amd64. Any chance to see they at web site ? :)

Forgot to say: it is the Qt build.

[sergiobenrocha2]

unknownbrackets, probably it is a security measure of launchpad, to don't use binary files in the package build. Everything needs the source code, or package dependences.

One workaround I'm thinking is using this ffmpeg PPA: https://launchpad.net/~jon-severinsson/+archive/ubuntu/ffmpeg/+packages

It has the developers packages, so you have to change debian/control and something I don't know yet: use a PPA to build packages for other PPA.

[i30817]

Launchpad does not allow binary dependencies not on the main repository or in another ppa (so a chain of auditing can be established in case of rootkits virus etc). So if you can find a clean ffmpeg ppa with the configuration you want, you can add that as a dependency and leave everything the same in the control file. However i think it unlikely, since PPSSPP specifically needs atrak3plus which isnt in the default config i think. So you might have to create another ppa just for FFMPEG (another messier possibility is to pull the FFMPEG source into a subdirectory from the recipe and build it during the build process so that the output of that build is then used by the PPSSPP build.

If you're going to all this trouble, i'd also like if you'd build two versions of PPSSPP, one using SDL only. I hate having to include QT libs on my machine for one or two programs. You can do that with debian packaging by including two package sections in the control file. 'install', 'postinst' etc files can be duplicated by using: packagename.postinst files and they will only apply to the package etc.

[sergiobenrocha2]

SDL version is not somehow deprecated? I can do this, but it seems that SDL version lacks some features.

[i30817]

No, i build it and it works just fine (with many less dependencies).

[sergiobenrocha2]

Yeah, i know, i builded here too, and worked fine. But:

" Cmake only builds the sdl version which has no menus, no fullscreen toggle, no screenshot functionality

Qt one works on a lot more platforms and handles a lot of the opengl stuff automatically" -xsacha

[unknownbrackets]

Ultimately they are all just small wrappings around the actual main emulator which is the same. SDL won't disable screensaves and etc. but it also won't pull in Qt and all that jazz.

There's already a tree in PPSSPP for ffmpeg. Just run the build script in ffmpeg/linux_x86-64.sh.

-[Unknown]

[i30817]

There is a fullscreen mode, it just needs a shortcut pull commit. I dont use screenshots and i prefer the menus from the sdl version. I would be very very unhappy if SDL started lagging, especially since all GNOME distros (that includes ubuntu) dont have QT libraries installed by default.

[xsacha]

The ffmpeg PPA likely won't work as it wouldn't have ATRAC3+ compiled in to it. If you really must use a freshly-compiled ffmpeg then the only solution is to compile it like @unknownbrackets showed.

[i30817]

To run the build script you're going to have to slightly patch the CMAKE file no? To be honest it probably would be better if CMAKE would do it by default if it didn't find it in system, upstream.

[unknownbrackets]

Maybe as an option. There's a reason we ship libs for primary platforms; it makes the build a lot faster (and more importantly, most Windows users would just give up and never compile PPSSPP.) I don't want travis build speed to pay for some particular buildserver intentionally wiping out binaries.

-[Unknown]

[xsacha]

Doesn't make sense for CMake to build libs that already exist. bzr (aptly named, bizarre?) would be the only thing that requires that. You could just add this to the debian-rules.

It seems like that as long as the .a file was created by the debian-rules script, it would be accepted.

[i30817]

Remember, launchpad doesn't allow any downloading either not just binaries (otherwise things like ivy would work argh). If its really in the tree, it will work, if it requires downloading not-from-a-ppa it wont.

[xsacha]

Everything it needs is in the git repo. So shouldn't need to download anything.

[i30817]

Yes i think a custom debian/rules would work fine then.

[i30817]

BTW, in the SDL version, you yourself as a packager can make the default be fullscreen by including in the debian dir a nameofsdlpackage.desktop file (actually since the desktop standard is shared with KDE you can (should) do it for both). Then inside it (check the standard of desktop files to create a valid one with icon obvs), you can add this line: Exec=PPSSPPSDL --fullscreen

It will make the default start from the menu be fullscreen.

[i30817]

Also here is a example of a build intree of the kind xsacha mentioned (from my exult ppa): http://pastebin.com/raw.php?i=KcZYrYiU You'd remove instead the static ffmpg executable, build it again with the script mentioned (during rules execution so hopefully launchpad wont barf), then run the equivalent of both autogen and configure for PPSSPP ( just run dh_auto_configure. I think cmake . is what it reduces to but its better to make debian use its tools as much as possible so it doesnt get confused). You won't need to actually build it inside the script, it will invoke make on the output of configure itself (that's the %: dh $@ it means 'run everything except what i changed from the default')

I have no idea if cmake needs the optimization levels gcc variable there, maybe not.

All the configure options are exult makefile stuff, i don't think they will be necessary for you. the first '--' after the dh_auto_configure means that the options to dh_auto_configure itself have finished and the rest is for the actual script generated (in this case, cmake makefile output... or cmake itself, not sure).

[sergiobenrocha2]

ppsspp --fullscreen

This parameter does not exists. Are you sure i30817 ?

[i30817]

PPSSPPSDL --fullscreen

It should probably exist on the non-sdl version, but i haven't verified (because i haven't built that one). If you're worried about the executable name, remember it doesn't have to be the same as the compiler output, you can simply rename it on debian/ppsspp.install (and add a conflict for the different SDL vs QT packages)

[sergiobenrocha2]

yeah, i know, in ubuntu it is ppsspp, to both versions Qt and SDL. They conflicts each other, so user can install only one of them.

This issue can be closed, I managed to build the packages. SDL needs only to go fullscreen by default, and it seems that doesn't exists this parameter.

[i30817]

It DOES exist. I just built it here (from git, and yes, it was PPSSPPSDL) and run it with it.

[sergiobenrocha2]

Yeah, it works, my bad. I don't know why didn't work a moment ago.

Needs to add this in man page.

---

Btw, why ppsspp does not have a --help parameter?

[hrydgard]

@sergiobenrocha2 because nobody has made one. Pull requests accepted.