In message <S2f02ebc0bgcc-sub@aconet.nl>
Frank de Bruijn <gcc-sub@aconet.nl> 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 <528b40a737chrisg@care4free.net>).
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
John.Tytgat@aaug.net
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
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
No comments:
Post a Comment