Sunday, 18 November 2012

Re: [gccsdk] Building the libraries

In article <aec494f052.Jo@hobbes.bass-software.com>,
John Tytgat <John.Tytgat@aaug.net> wrote:
> In message <S2f02ebc0bgcc-sub@aconet.nl>
> Frank de Bruijn <gcc-sub@aconet.nl> wrote:
> > 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.

It *is* installed, but it fails. See the message I was referring to (by
Chris, dated 5-5-2012, in the thread 'Autobuilder and Scummvm').

> 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.

As far as I can tell, build-libs does use build. The last couple of
lines of build-libs are:

lib=$(getnext)

while [ -n "$lib" ] ; do

$base/build -v $lib

lib=$(getnext)
done

echo "All libraries built"

> Again, 'build-libs' should be able to sort out dependencies by using
> 'build'.

Well, it seems that doesn't always work.

> > 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 ?

I'm using branches/release_4_1_2. I wanted the 'stable' version...

Regards,
Frank


_______________________________________________
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