[Scummvm-devel] PSP build failure on buildbot due to Broken Sword 2.5

[yotam barnoy]

I'm forwarding this discussion to -devel because it merits its own
thread. Everyone can read the forwarded entries below to catch up.

It turns out this problem is more serious than expected. I can add
libpng to the plugins, but after trying and failing, I realized I
can't add the needed PSP libs. This is because the PSP libs aren't
available in compiled code -- they're simply jumps to the correct
addresses in the PSP flash, and they can only be fixed up for the main
executable in a special process. This means that the plugins can never
directly access PSP functions.

There is one possible 'easy' solution, which is to include all the
requested PSP libs and cause fake calls to the libraries that call
those PSP functions in the main executable, so that the plugins can
find everything they need in the main executable. I'm not 100% certain
this will work.

The other solution is to deal with the lua issues which are detailed
below and fix them.

For now, I recommend that Broken Sword 2.5 not be built for the PSP.

Yotam


For reference, these are the errors we're getting on buildbot:
engines/sword25/gfx/screenshot.o: In function
`Sword25::Screenshot::SaveToFile(Graphics::Surface*,
Common::WriteStream*)':
screenshot.cpp:(.text+0xcc): undefined reference to `png_create_write_struct'
screenshot.cpp:(.text+0x1c0): undefined reference to `png_set_write_fn'
screenshot.cpp:(.text+0x1d4): undefined reference to `png_write_png'
screenshot.cpp:(.text+0x1e0): undefined reference to `png_destroy_write_struct'
/mnt/sda2/toolchains/psp/bin/../lib/gcc/psp/4.3.2/../../../../psp/lib/libc.a(clock.o):
In function `clock':
../../../../../../newlib/libc/sys/psp/libcglue.c:498: undefined
reference to `sceKernelLibcClock'
/mnt/sda2/toolchains/psp/bin/../lib/gcc/psp/4.3.2/../../../../psp/lib/libc.a(_rename.o):
In function `_rename':
../../../../../../newlib/libc/sys/psp/libcglue.c:941: undefined
reference to `sceIoRename'
/mnt/sda2/toolchains/psp/bin/../lib/gcc/psp/4.3.2/../../../../psp/lib/libc.a(setsockopt.o):
In function `setsockopt':
../../../../../../newlib/libc/sys/psp/socket.c:293: undefined
reference to `sceNetInetSetsockopt'
../../../../../../newlib/libc/sys/psp/socket.c:296: undefined
reference to `sceNetInetGetErrno'
/mnt/sda2/toolchains/psp/bin/../lib/gcc/psp/4.3.2/../../../../psp/lib/libc.a(setsockopt.o):
In function `getsockopt':
../../../../../../newlib/libc/sys/psp/socket.c:167: undefined
reference to `sceNetInetGetsockopt'
../../../../../../newlib/libc/sys/psp/socket.c:170: undefined
reference to `sceNetInetGetErrno'


>Hi there,

>could you please take a look into the PSP build failure on buildbot? It seems that it believes libpng is present (the headers are, apparently), but then fails during linking.

>See <http://buildbot.scummvm.org/buildbot/builders/trunk-psp/builds/6747/steps/compile/logs/stdio>.

>Cheers,
>Max

On Tue, Oct 19, 2010 at 4:08 PM, Joost Peters <joostp at 7fc1.org> wrote:
> Hmmm, there are 2 issues here:
>
> - Some socket functions are apparently now indirectly referenced (through
> lua, presumably), easily "fixed" by adding -lpspnet_inet to psp.spec, but
> I'm not too happy with this addition.  Any thoughts on this, Yotam?

We should probably #ifdef out the parts in Lua that reference sockets
since they're irrelevant to ScummVM.

The other issues come up because lua uses the clock() function and the
rename() function. We should replace clock() with our tick
implementation and rename() should also be replaced by our file
functions. For now we can add a library for the  functions missing, in
which case either -lpsplibc or -lpspuser should do the trick.

> - The sword25 engine references stuff from libpng directly, which isn't
> being linked with the plugins.
> This could probably be fixed by conditionally adding -lpng to the plugin
> linking, which would have to be done for each platform.
> A better solution would be to move pngloader to common/ and change the
> Sword25::Screenshot::SaveToFile() to use the same thumbnail saving code
> other engines use.

Indeed. This should be an issue for every plugin based system.

Yotam

On Tue, Oct 19, 2010 at 5:03 PM, Max Horn <max at quendi.de> wrote:
> Hi folks,
>
> can you please either forward the mails in this thread to -devel, or alternative write a summary of what has been said here? Point is, other ports may be affected by the very same issues.
>
>
> Cheers,
> Max