Thanks for the bug report. I'll try and sort these issues out this
There's a good reason it's currently painful to cross-compile, and it's
not CMake's fault. The SVN version of Player is using an entirely new
build system that was written from scratch by someone who was learning
CMake at the same time (i.e. me). It's had about 1.5 months of testing.
Don't expect the more complex things like cross-compiling to work
straight away. Once we have things ironed out, it will be very easy to
cross compile. Until then it's going to be painful while we get all the
bugs out of the new build scripts. Any help (including detailed bug
reports like you gave below) is more than welcome.
If you don't want/don't have time to help and just want to cross-compile
without any trouble, I suggest you stick to 2.1. The cmake scripts won't
be in a release version for 6 months or so at least.
Paul Osmialowski wrote:
> Hello devels,
> As I've expected, crosscompilation latest snapshots of Player for
> unfamiliar systems is currently painful. Fortunately it is possible and
> not much needs to be done to fix it.
> I've installed cmake 2.6.0 on the host with cris/etrax crosscompilation
> environment. I've started cmake in the directory called 'build' by typing:
> CMAKE_SYSTEM_NAME=linux CMAKE_SYSTEM_PROCESSOR=cris cmake
> ../player-20080604 -i
> Drivers that I've compiled-in for my embedded system are:
> cameracompress (but see below)
> camerauncompress (but see below)
> This is the list of problems that I had:
> 1. Two more libraries had to be installed into my crosscompilation
> environment even if Player itself + just a few drivers that I'm using does
> not need them. These are: jpeglib and zlib: some parts of core library
> needs jpeglib headers (previously preprocessor directive like HAVE_JPEG
> was used for checking if these headers need to be included); at the end of
> building process linker instantly tries to link against libz, which wasn't
> needed before. The good side of having jpeglib is that now I can have two
> more drivers: cameracompress/camerauncompress, however they're rather not
> useful for me, as spca USB camera that I'm using here gives jpeg
> compressed images already. What is zlib needed for, I don't know really.
> 2. For some unknown reason cmake tries to build librtk2 (even if I marked
> that I don't want it) and linker tries to link against librtk2. I had to
> remove lines from Makefile manually in order to build Player binary. This
> needs to be fixed.
> 3. At the end of building Player binary, linker wants to link against
> glib, gtk2, pango, atk, gdk-pixbuf-2.0 (probably because some of the
> drivers open new windows, as simpleshape, or use gdk-pixbuf routines to
> manage with bitmap files, as mapfile). My embeded system is headless, so
> no chances for X and no need for xlib, therefore gtk/gdk won't be ever
> installed. I've deleted things from link.txt file and finally I got player
> binary able to run on my embedded system (to my surprice, it was bit
> smaller than the one built previously with autotools, even if there are
> two more drivers now and two more static libraries linked, libz.a,
> 4. Whole make process stopped at 75% during building utils (it was
> playercam which uses gtk, no headers on my building environment). I don't
> know how can I turn it down, I don't need utils. One of them has built
> successfully as ETRAX executable (playerlogsplitter), still I don't need
> Next week I'll try to build Player on QNX Neutrino 6.2.0/x86 using cmake
> 2.6.0 that I've compiled there. I expect lots of troubles.