In message <[email protected]> Frank de Bruijn <[email protected]> wrote:
> Right. Had another go at this. In order to get as far as I did, I had to > hack things all over the place. The following is what I did until I got > stuck. > > I ran build-libs from inside the gccsdk/build directory and building > started with tk8/4 (keep in mind that bash scripting functions do not > sort directories alphabetically). > > The first problem was rman failing on building libx11. I created a > symlink called rman pointing to /bin/true to hack that out of the way > (cf. list message <[email protected]>). Or either install rman on your build machine. We're checking on a minimal set of buildtools in 'build' but I don't think 'build-libs' is using 'build'. And that's probably also the cause of the dependencies issues you're reporting here. > The next error occurred while building gdk-pixbuf. The message indicated > glib2-0.dev wasn't available, so I did 'build -v libglib2.0-0' to force > building this library separately. This failed with a message about the > -j option for make needing a numerical argument. > > At first I suspected 'env/ro-make' but it turned out that wasn't > involved (yet). The error was actually caused by line 16 of > 'autobuilder/libraries/gtk/libglib2.0-0/setvars' which reads: > 'make -j$AB_CPUS install' (a configure/make sequence in a setvars file? > really?). > At that point the variable AB_CPUS contains X (for 'guess number of > CPUs') so that will never work. I (temporarily) changed that line to > 'make -j$NUMCPUS install' and libglib2.0-0 was eventually built > successfully. Theo recently added automatic -j option adding to the MAKEFLAGS. I don't think a 'setvars' file should explicitely add it anymore. Theo, can you confirm tis ? > At least that's what it claimed. I wonder. I saw an awful lot of > 'unrecognized option: -pthread' errors scroll by during the build. pthread support is part of UnixLib and you don't need additional compiler flags to enable it. I don't think it can harm, on the other hand, a simple patch might be in order to tame the build log output. > I then restarted the build-libs at gdk-pixbuf and this time it aborted a > few lines further in the process, again because of a missing dependency. > Restarted build-libs after a succesfull 'build -v libtiff4'. Aborted > again. Another dependency (libpng12-0) (I assumed the build dependencies > were read from the sources files, but a closer look at build and > fetch-depends suggests they aren't). Again, 'build-libs' should be able to sort out dependencies by using 'build'. > After this the process trudged along for a while, until it was building > cairo-gtk2, when it aborted with an error about never calling > bits/byteswap.h directly. > Looking at the byteswap.h files in cross/arm-unknown-riscos/include/bits > and .../string revealed an '#if !defined' test failed because after > #define-ing __BYTESWAP_H (two underscores) in .../string, the test in > .../bits is for _BYTESWAP_H (one underscore). After I added an > underscore in .../bits, the build passed that point. This is a bug in UnixLib @ trunk. I've just fixed that. Thanks :-) > The next failure (still with cairo-gtk2), is where I got stuck (see > last-failure in the attached tarball). > The failing #include is for .../bits/socket2.h and this actually does > not exist. I found a socket2.h file -which does indeed define macros- on > my host system in /usr/include/i386-linux-gnu/bits, but I'm not sure if > I can copy that to the cross compiler's .../bits unchanged. This was a couple of months ago fixed in UnixLib @ trunk. Are you using the cross-compiler (recently ?) built from trunk/gcc4 or branches/release_4_1_2 ? John. -- John Tytgat, in his comfy chair at home [email protected] _______________________________________________ GCCSDK mailing list [email protected] Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
