Re: [gccsdk] [GCCSDK commit] peter - r4189 - trunk/gcc4
In message e1n6uyr-0005gk...@riscos.info you wrote: Author: peter Date: 2009-11-07 15:19:12 -0800 (Sat, 07 Nov 2009) New Revision: 4189 Modified: trunk/gcc4/create-gcckit trunk/gcc4/create-riscpkg Log: Fix path to zip Modified: trunk/gcc4/create-gcckit === --- trunk/gcc4/create-gcckit 2009-11-07 15:40:41 UTC (rev 4188) +++ trunk/gcc4/create-gcckit 2009-11-07 23:19:12 UTC (rev 4189) @@ -345,8 +345,8 @@ if [ $GCCSDK_DO_PKG == YES ] ; then # Package all the kits: - if [ ! -f $GCCSDK_CROSS_PREFIX/bin/zip ] ; then -echo Unable to create kits because of missing zip executable $GCCSDK_CROSS_PREFIX/bin/zip. + if [ ! -f $GCCSDK_INSTALL_ENV/bin/zip ] ; then +echo Unable to create kits because of missing zip executable $GCCSDK_INSTALL_ENV/bin/zip. exit 1 fi I know this is continuing on a change made in the past, but it still feels wrong to have tools running on the host hardware installed and deployed at $GCCSDK_INSTALL_ENV/bin, that really should be $GCCSDK_CROSS_PREFIX/bin together with the rest of the cross compiler toolchain. We should expect that all binaries at $GCCSDK_INSTALL_ENV/bin are RISC OS binaries, like we expect that all libraries at $GCCSDK_INSTALL_ENV/lib are RISC OS libraries. And that all binaries at $GCCSDK_CROSS_PREFIX/bin (mmh, which is also $GCCSDK_INSTALL_CROSSBIN) are binaries running on the host computer, i.e. that platform on which the cross-compiler tools run on. John. -- John Tytgat, in his comfy chair at home BASS john.tyt...@aaug.net ARM powered, RISC OS driven ___ 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
Re: [gccsdk] Problems building crosscompiler
On Sun, 2009-11-08 at 11:36 +, chr...@care4free.net wrote: On Nov 7 2009, John Tytgat wrote: I would be surprised this would a problem in your host compiler (i.e. the compiler used on your Ubuntu 9.10) and that we have to look for a solution there. My bet is that this is a case of not using autoconf2.59 (gcc4.1 really need this exact version). Have you installed the autoconfig2.59 package ? After you've done that, restart for scratch (ie. the srcdir needs to be reconfigured using the recipe/scripts/reconf-*). I got this too on ubuntu 9.10 even though I had all the correct versions installed. I got round it by renaming autoconf then symlinked autoconf to autocont2.59. I'm not having a lot of success with it :( I uninstalled 2.13 and tried to remove 2.64, but somehow it seems 2.59 is dependent on 2.64 (not sure how that works...) so I ended up with both of them. I renamed /usr/bin/autoconf to /usr/bin/autoconf2.64 and made /usr/bin/autoconf a symlink to /usr/bin/autoconf2.59 but I got the exact same problem. I then did the same to /usr/bin/autoreconf* but I'm not so sure that that will have the desired effect. Any other suggestions? Cheers, Jan-Jaap FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more! ___ 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
Re: [gccsdk] Problems building crosscompiler
Hi Jan-Jaap, I renamed /usr/bin/autoconf to /usr/bin/autoconf2.64 and made /usr/bin/autoconf a symlink to /usr/bin/autoconf2.59 but I got the exact same problem. I then did the same to /usr/bin/autoreconf* but I'm not so sure that that will have the desired effect. How about getting the source tar for the desired version and ./configure it with a --prefix of some temp. directory, e.g. /tmp/jjac. Build and install. Then ensure /tmp/jjac/bin is up the front of your PATH when you want to do stuff that needs it. Cheers, Ralph. ___ 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
Re: [gccsdk] Problems building crosscompiler
On Sun, 2009-11-08 at 15:14 +0100, John Tytgat wrote: In message 1257687807.2209.6.ca...@ubuntu Jan-Jaap van der Geer jjvdg...@inbox.com wrote: I'm not having a lot of success with it :( I uninstalled 2.13 and tried to remove 2.64, but somehow it seems 2.59 is dependent on 2.64 (not sure how that works...) so I ended up with both of them. I don't think this is a problem. That's what I have right now as well (but using Ubuntu 9.04) No, I agree. It seemed familiar, so I'd seen that before, probably on 9.04. I renamed /usr/bin/autoconf to /usr/bin/autoconf2.64 and made /usr/bin/autoconf a symlink to /usr/bin/autoconf2.59 but I got the exact same problem. I then did the same to /usr/bin/autoreconf* but I'm not so sure that that will have the desired effect. Any other suggestions? Just to be 100% sure: did you restart with a fresh srcdir (i.e. throw it away, it will be regenerated) ? As otherwise you might still have some leftovers there of the wrong auto* tools. Yes, I started with a whole new gcc4 directory, to be on the safe side. Does build-world also remove the srcdir? Anyway, using Ralph's suggestion worked (Thanks, Ralph!), so I now should have a working crosscompiler again. Looking at my temporary autoconf directory, I suppose it is not enough to symlink autoconf and autoreconf, but I should also have symlinked autoheader, autom4te, autoscan, autoupdate and ifnames. Maybe I should do just that, so I do not need to remember to put this tempdir in my path next time I want to build the compiler. Cheers, Jan-Jaap GET FREE 5GB EMAIL - Check out spam free email with many cool features! Visit http://www.inbox.com/email to find out more! ___ 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
Re: [gccsdk] Objasm record layouts revisited
In message 4e7fd8b250.bel...@ivy.at.home
Christopher Martin bel...@internode.on.net wrote:
A month ago, I offered a tiny patch to objasm intended to allow
expressions with record layout symbols. At the time, I did not
appreciate all the issues with record layouts.
I have since revisited the code and made another attempt to resolve the
long-outstanding issues. More work is probably required, but I think
this attempt is a good start. Sorry it has taken a month to get this
far. It has been many years since I had such difficulty understanding
another's code.
Many thanks for your efforts. Yes, the objasm (or asasm it is now
called) sources are not the most easy ones to understand.
I have attached a diff file and a zip archive of my modified objasm
sources from the 4.1.1 1b release. Note that my files are organised
according to RISC OS convention; I hope this is okay.
The RISC OS filename convention gave a little bit of trouble but that
was easy to overcome.
But I had much more trouble that this is a context diff and not a unified
one (diff option -u) which makes it much more difficult to apply,
moreover when the source on trunk have been updated since last release.
And those changes were made in the same area as your changes.
In fact I'm not even sure if I got your changes applied correctly as
the previous failing tests_fail/register_based_map_fail.s is still
not processing correctly. Or am I assuming something wrong here ?
May I suggest the following ? Assuming you want to develop asasm
on RISC OS, please grap a copy of the RISC OS subversion port at
URL:http://www.cp15.org/versioncontrol/ and in a TaskWindow
go to a directory where you want to checkout the latest version
by doing:
* svn co svn://svn.riscos.info/gccsdk/trunk/gcc4/riscos/asasm
Despite the sources are checked in as foo.c/foo.h filenames in our
repository, by default on RISC OS you'll end up with c.foo and h.foo
files so you'll probably just have to add a RISC OS makefile (which
I guess you already have).
And when you want to submit your work, just a svn diff my_patch
will do (unified diff output is standard with svn).
I've attached the differences I made using your patch and those are
made against what we have now in trunk. Could you verify if those
are still correct and if so, which test case they solve (as I don't
see failing tests_fail/register_based_map_fail.s being solved) ?
Thanks,
John.
--
John Tytgat, in his comfy chair at home BASS
john.tyt...@aaug.net ARM powered, RISC OS driven
Index: code.c
===
--- code.c (revision 4189)
+++ code.c (working copy)
@@ -204,6 +204,45 @@
error (ErrorSerious, FALSE, Internal codeBool: overflow);
}
+void
+codeValue (const Value *value)
+{
+ switch (value-Tag.t)
+{
+ case ValueInt:
+codeInt (value-ValueInt.i);
+break;
+ case ValueFloat:
+codeFloat (value-ValueFloat.f);
+break;
+ case ValueString:
+codeString (value-ValueString.len, value-ValueString.s);
+break;
+ case ValueBool:
+codeBool (value-ValueBool.b);
+break;
+ case ValueCode:
+switch (value-ValueCode.c-Tag)
+ {
+case CodeSymbol:
+ codePosition (value-ValueCode.c-CodeSymbol.symbol);
+ break;
+default:
+ error (ErrorSerious, FALSE, code::codeValue received a
non-CodeSymbol ValueCode);
+ }
+break;
+ case ValueLateLabel:
+codeSymbol (value-ValueLate.late-symbol);
+codeInt (value-ValueLate.i);
+codeOperator (Op_add);
+break;
+ case ValueAddr:
+codeInt (value-ValueAddr.i);
+break;
+ default:
+error (ErrorSerious, FALSE, code::codeValue received a Value of
unhandled type);
+}
+}
/* TRUE if codeEvalLowest succeeded */
static BOOL
Index: code.h
===
--- code.h (revision 4189)
+++ code.h (working copy)
@@ -75,6 +75,7 @@
void codeString (int len, const char *str);
void codeFloat (FLOAT value);
void codeBool (BOOL value);
+void codeValue (const Value *value);
Value codeEvalLow (ValueTag legal, int size, Code *program);
Value codeEval (ValueTag legal);
Index: m_cpuctrl.c
===
--- m_cpuctrl.c (revision 4189)
+++ m_cpuctrl.c (working copy)
@@ -242,7 +242,7 @@
WORD ir = cc ~1, ir2 = 0; /* bit 0 set to indicate ADRL */
Value im;
ir |= DST_OP (getCpuReg ());
- ir |= LHS_OP (15) | IMM_RHS; /* pc */
+ ir |= LHS_OP (15) | IMM_RHS; /* pc, may have to undo this later */
skipblanks ();
if (inputLook () == ',')
{
@@ -252,10 +252,10 @@
else
error (ErrorError, TRUE, %sdst, InsertCommaAfter);
/* The label will expand to either a field in a based map or a
Re: [gccsdk] Problems building crosscompiler
Jan-Jaap van der Geer jjvdg...@inbox.com wrote: Anyway, using Ralph's suggestion worked (Thanks, Ralph!), so I now should have a working crosscompiler again. Looking at my temporary autoconf directory, I suppose it is not enough to symlink autoconf and autoreconf, but I should also have symlinked autoheader, autom4te, autoscan, autoupdate and ifnames. I've been following this with interest, as I'm also trying to build a copy of GCCSDK on Ubuntu 9.10. In this case 3.4.6, as that's what I was using on RISC OS and I'd like to get cross-compilation working on my projects with that before changing anything else. Anyway, I've made the changes Jan-Jaap suggests above, but the build still fails with gcc -o /home/riscos/cross/bin/arm-riscos-aof/3_4/cpp /home/riscos/gccsdk/gcc/arm-riscos-aof/gcc-3_4/gcc/stage1/gcc.o /home/riscos/gccsdk/gcc/arm-riscos-aof/gcc-3_4/gcc/stage1/cppspec.o \ /home/riscos/gccsdk/gcc/arm-riscos-aof/gcc-3_4/gcc/stage1/version.o /home/riscos/gccsdk/gcc/arm-riscos-aof/gcc-3_4/gcc/stage1/config/arm/rname.o /home/riscos/gccsdk/gcc/arm-riscos-aof/gcc-3_4/gcc/stage1/config/arm/cross.o /home/riscos/gccsdk/gcc/arm-riscos-aof/gcc-3_4/gcc/stage1/prefix.o -L/home/riscos/gccsdk/gcc/arm-riscos-aof/libiberty/stage1 -liberty -lm sed -e /^@@ifobjc.*/,/^@@end_ifobjc.*/d -e /^@@ifc.*/d -e /^@@end_ifc.*/d c-parse.in c-parse.y bison -d c-parse.y -o c-parse.c c-parse.y:1649.19-20: $$ for the midrule at $4 of `structsp_attr' has no declared type c-parse.y:1660.19-20: $$ for the midrule at $4 of `structsp_attr' has no declared type c-parse.y:1669.19-20: $$ for the midrule at $4 of `structsp_attr' has no declared type c-parse.y:1674.19-20: $$ for the midrule at $3 of `structsp_attr' has no declared type make[2]: *** [c-parse.c] Error 1 make[2]: Leaving directory `/home/riscos/gccsdk/gcc/gcc/gcc' make[1]: *** [gcc] Error 2 make[1]: Leaving directory `/home/riscos/gccsdk/gcc/gcc' make: *** [gcc-stg1] Error 2 Google doesn't turn much up: there are a couple of mentions concerning building GCC for Microchip products, but no obvious solutions. Anyone seen this before with the GCCSDK? Am I using a too-recent version of Bison? -- Steve Fryatt - Leeds, England http://www.stevefryatt.org.uk/ ___ 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
Re: [gccsdk] Problems building crosscompiler
Steve Fryatt wrote: Jan-Jaap van der Geer jjvdg...@inbox.com wrote: Anyway, using Ralph's suggestion worked (Thanks, Ralph!), so I now should have a working crosscompiler again. Looking at my temporary autoconf directory, I suppose it is not enough to symlink autoconf and autoreconf, but I should also have symlinked autoheader, autom4te, autoscan, autoupdate and ifnames. I've been following this with interest, as I'm also trying to build a copy of GCCSDK on Ubuntu 9.10. In this case 3.4.6, as that's what I was using on RISC OS and I'd like to get cross-compilation working on my projects with that before changing anything else. Anyway, I've made the changes Jan-Jaap suggests above, but the build still fails with [bison] I think this route might be more effort than it's worth. The GCC 3 stuff hasn't been seriously maintained in several years. Also, as I suspect you're aware, things build with GCC 3 default options have a chance of not working on the BeagleBoard. I suggest going straight to GCC 4.1. If you have any problems building your stuff with that, we easily help you there. ___ 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
Re: [gccsdk] Problems building crosscompiler
On Sun, 2009-11-08 at 16:19 +0100, John Tytgat wrote: In message 1257692054.2209.19.ca...@ubuntu Jan-Jaap van der Geer jjvdg...@inbox.com wrote: Looking at my temporary autoconf directory, I suppose it is not enough to symlink autoconf and autoreconf, but I should also have symlinked autoheader, autom4te, autoscan, autoupdate and ifnames. Maybe I should do just that, so I do not need to remember to put this tempdir in my path next time I want to build the compiler. Care to craft a little paragraph describing all this so we can add this to README ? :-) And/or a little patch for build-world or other relevant script ? I would like to, but I am not sure if my own suggestion is a good one. I did the above and removed the local copy of autoconf from my path and then it was OK to compile the crosscompiler. So I was happy and thought I had a solution. However, I then continued to build a package with the autobuilder, which then insisted on me installing autoconf2.13. Installing this did something to /usr/bin/autoconf which is now a script which seems to check from parameters which version of autoconf to call. I think (but am not sure) that this was the script that was also there when it did not work, right after installation of Ubuntu 9.10, so I suspect my setup again will not work. I have not checked this, though. Of course I could apply another round of symlinking, but I am not really sure what to do with this script. Of course I could just scrap it, but I am not sure about the consequences of that. What is it that depends on autoconf2.13 anyway? Cheers, Jan-Jaap ___ 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
Re: [gccsdk] [GCCSDK commit] peter - r4189 - trunk/gcc4
John Tytgat wrote: I know this is continuing on a change made in the past, but it still feels wrong to have tools running on the host hardware installed and deployed at $GCCSDK_INSTALL_ENV/bin, that really should be $GCCSDK_CROSS_PREFIX/bin together with the rest of the cross compiler toolchain. We should expect that all binaries at $GCCSDK_INSTALL_ENV/bin are RISC OS binaries, like we expect that all libraries at $GCCSDK_INSTALL_ENV/lib are RISC OS libraries. And that all binaries at $GCCSDK_CROSS_PREFIX/bin (mmh, which is also $GCCSDK_INSTALL_CROSSBIN) are binaries running on the host computer, i.e. that platform on which the cross-compiler tools run on. I understand where you're coming from. But in practice env/bin contains mostly things which are used for builds - a lot of it library config scripts, etc. It does also contain a number of RISC OS binaries, but their presence there is of questionable use. These are mostly things that are library utilities, and got installed along with them. Finally, there are a couple of native binaries used for cross build config - stuff like orbit-idl-2. The reason I also put 'zip' here is that it's build as part of the autobuilder. I wanted to keep cross/bin entirely for stuff built by the gcc4 tree. It makes certain clean builds and stuff easier, since you can remove each directory independently. I appreciate that there's something of a circular dependency here, in that the packaging of GCC requires zip. However, in practice it will also require 'make' (the RISC OS binary) and perhaps other stuff we choose to package with the !GCC app. None of this is ideal, but it does seem the most practical after using this setup for quite some time. ___ 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
Re: [gccsdk] Ports needing Love
Peter Naulls wrote: Mesa et al: http://www.simonrules.com/iyonixmesa/ I took a look at this. I can built it ok (needs some minor changes for GCC 4), but the sample apps - both supplied and as I built crash under 5.14/15. Additionally, the Mesa libraries on which it is based are particularly old. The links on the page above are also broken, and probably the BeOs stuff has been updated since. I can put this in the autobuilder, but I'm not sure how to proceed from this point. ___ 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
Re: [gccsdk] Problems building crosscompiler
Peter Naulls pe...@chocky.org wrote: I think this route might be more effort than it's worth. The GCC 3 stuff hasn't been seriously maintained in several years. Also, as I suspect you're aware, things build with GCC 3 default options have a chance of not working on the BeagleBoard. True. I had a vague memory of issues with old libraries and V4 (in terms of the new binary formats), but hadn't got around to checking. I'd avoided the issue by not upgrading on the RISC OS side. I suggest going straight to GCC 4.1. If you have any problems building your stuff with that, we easily help you there. OK, that builds OK (I think). That's using the sources from /gccsdk/trunk as advised on the Using_GCCSDK page. However, things then seem to diverge from the README. Section 3 still advises setting GCCSDK_INSTALL_CROSSBIN=/home/riscos/cross/bin and prepending this to PATH, which is how version 3 worked. The only problem is, ~/cross/bin contains a load of files prefixed arm-unknown-riscos- and so this doesn't seem to work (calling gcc as normal results in the standard compiler being used, as I'd expect). ~/cross/arm-unknown-riscos/bin does contain suitably names binaries, but if I try this path then #include... doesn't work as the compiler claims that it can't find the headers required (eg. stdio.h). Unfortunately, this is the point at which my limited knowledge runs out. Am I missing something obvious here? -- Steve Fryatt - Leeds, England http://www.stevefryatt.org.uk/ ___ 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
Re: [gccsdk] Problems building crosscompiler
Steve Fryatt wrote: However, things then seem to diverge from the README. Section 3 still advises setting GCCSDK_INSTALL_CROSSBIN=/home/riscos/cross/bin and prepending this to PATH, which is how version 3 worked. The only problem is, ~/cross/bin contains a load of files prefixed arm-unknown-riscos- and so this doesn't seem to work (calling gcc as normal results in the standard compiler being used, as I'd expect). /home/riscos is kind of a legacy thing, and doesn't have any particular meaning. A better setup which works just as well is something like: home gccsdk/gcc4(checked out) /autobuilder (checked out) /cross (built by GCC 4) /env (built by install-env and target for installs) /build (autobuilder work directory) ~/cross/arm-unknown-riscos/bin does contain suitably names binaries, but if I try this path then #include... doesn't work as the compiler claims that it can't find the headers required (eg. stdio.h). Unfortunately, this is the point at which my limited knowledge runs out. Am I missing something obvious here? I don't really recommend having the compilers in your explictly in your $PATH, and didn't know that was there. I had be planning to try and simplify some of the GCCSDK documentation, since I think it's a bit confusing as it is. There are a numbers of ways things can be done, all to support various build setups. If you have a Makefile, you probably want to call ro-make to do the dirty work. A simple Makefile might therefore look like this: CFLAGS = -I $(GCCSDK_INSTALL_ENV)/include LDFLAGS = -L $(GCCSDK_INSTALL_ENV)/lib all: program,e1f program,e1f: program.o etc. ___ 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
Re: [gccsdk] Problems building crosscompiler
In message mpro.kst8q8040jm8w03d4.li...@stevefryatt.org.uk Steve Fryatt li...@stevefryatt.org.uk wrote: However, things then seem to diverge from the README. Section 3 still advises setting GCCSDK_INSTALL_CROSSBIN=/home/riscos/cross/bin and prepending this to PATH, which is how version 3 worked. The only problem is, ~/cross/bin contains a load of files prefixed arm-unknown-riscos- and so this doesn't seem to work (calling gcc as normal results in the standard compiler being used, as I'd expect). The prefix arm-unknown-riscos- is a standard way these days to indicate that this is the cross-compiler for the arm-unknown-riscos- target. It would be possible to drop the prefix (one of many configure options) but that tends to confuse the build procedure based on autotools unless you start massaging its options (and there are projects who need access to the host compiler, i.e. gcc, to build a tool needed to build the rest of the project). For makefiles used for cross compilation, you can use something like: CC := $(wildcard $(GCCSDK_INSTALL_CROSSBIN)/*gcc) And use $(CC) for specifying your compiler in the rest of your Makefile. John. -- John Tytgat, in his comfy chair at home BASS john.tyt...@aaug.net ARM powered, RISC OS driven ___ 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
Re: [gccsdk] Problems building crosscompiler
John Tytgat john.tyt...@aaug.net wrote: The prefix arm-unknown-riscos- is a standard way these days to indicate that this is the cross-compiler for the arm-unknown-riscos- target. It would be possible to drop the prefix (one of many configure options) but that tends to confuse the build procedure based on autotools unless you start massaging its options (and there are projects who need access to the host compiler, i.e. gcc, to build a tool needed to build the rest of the project). For makefiles used for cross compilation, you can use something like: CC := $(wildcard $(GCCSDK_INSTALL_CROSSBIN)/*gcc) And use $(CC) for specifying your compiler in the rest of your Makefile. Thanks (and to Peter) -- that all makes sense. I was still thinking in the mindset of calling gcc from the user riscos. I'll go away and have a play with all this again, and see how far I get. -- Steve Fryatt - Leeds, England http://www.stevefryatt.org.uk/ ___ 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
Re: [gccsdk] [GCCSDK commit] peter - r4189 - trunk/gcc4
John Tytgat wrote: In message 4af71a7b.4000...@chocky.org Peter Naulls pe...@chocky.org wrote: I understand where you're coming from. But in practice env/bin contains mostly things which are used for builds - a lot of it library config scripts, etc. It does also contain a number of RISC OS binaries, but their presence there is of questionable use. These are mostly things that are library utilities, and got installed along with them. I don't think we should fight common conventions to repurpose $PREFIX/bin in builds using cross-compiler by placing native build tools there. I'm not sure you're adequately distinguishing between the different contents of this directly. On my setup, there are no less than 80 scripts there, which are used for library configuration purposes. In fact, I don't think we should be installing RISC OS binaries at all here, and I'm tempted to modify ro-install to ditch any such binaries placed here, since they have no purpose. I disagree that we are fighting anything - this is just how it works out with the extant build systems, many of which know nothing about cross compilation. A 'make install' installs binaries in $PREFIX/bin and those binaries are in our case RISC OS ones. Let's not contaminate that directory with host binaries. We should not have $PREFIX/bin in our PATH during Autobuild builds. It has to be in the path - or something does - to pick up the above scripts, and occasional binary. If someone happens to have qemu activated with the binfmt_misc enabled for AOF/ELF binaries, you suddenly going to execute those RISC OS binaries during building which will give for sure interesting and confusing fallouts. All RISC OS binaries should end in ,e1f - so unless qemu is somehow picking these up, I don't see this scenario - in any case, this can be avoided by not installing the RO binaries in the first place. If that's the only reason, let's create an env/bin-cross directory holding those native zip/orbit-idl etc binaries and then we avoid possible contamination of host and RISC OS binaries and by removing $GCCSDK_INSTALL_ENV you can start from a clean state as well. Well, there are actually other scripts in env itself, and we could move things there if that was really your objection. However enforcing this in general is a bit tricky, although it's only a couple of cases. ___ 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
Re: [gccsdk] Problems building crosscompiler
In message mpro.kstgn305m9dmo03d4.li...@stevefryatt.org.uk Steve Fryatt li...@stevefryatt.org.uk wrote: Peter Naulls pe...@chocky.org wrote: A simple Makefile might therefore look like this: CFLAGS = -I $(GCCSDK_INSTALL_ENV)/include LDFLAGS = -L $(GCCSDK_INSTALL_ENV)/lib etc. OK, that all seems to work, and it's a lot neater than having to use the riscos user -- thanks for the help. It now falls over on linking, with file not recognized: File format not recognized on the old OSLib32.o library. I assume this to simply be AOF vs ELF, in which case I'll return to it another day. You need OSLib 7 but that hasn't been released yet. An older set of binaries can be found at URL:http://joty.drobe.co.uk/oslib/, if you use UnixLib as runtime library, take the softfloat one; if you use SharedUnixLibrary in your program, take the 'module' one (SCL build SCL for module build should be the same for OSLib). Is there a guide anywhere online to the changes with ELF? From what I can tell with Google, GCC V4 only works with ELF format binaries. Have a look at gcc4/riscos/dist/!GCC/docs/index.html which is the main page of !GCC documentation for the RISC OS build of gcc. It points to other documentation which is created during the build so not all links there will work from that document. Is this correct, or can it still output an AIF executable if asked to (as far as I can see, it can not accept AOF libraries any more)? AIF does not imply AOF or visa versa. Yes AIF binaries are possible, cfr above mentioned documentation and the elf2aif binary. Be sure to specify the -static option when linking and you want AIF executable using elf2aif as the documentation has not been updated enough for the shared library building which is currently the default for the cross-compiler. This was the other issue I was hoping to avoid by sticking with V3 for the time being, as it looks like most things like OSLib are still in a DIY-ELF state. It would indeed nice to have OSLib 7 release, one of many items on my todo/wouldbenicetohave list. :-/ John. -- John Tytgat, in his comfy chair at home BASS john.tyt...@aaug.net ARM powered, RISC OS driven ___ 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
Re: [gccsdk] Problems building crosscompiler
John Tytgat wrote: In message mpro.kstgn305m9dmo03d4.li...@stevefryatt.org.uk Steve Fryatt li...@stevefryatt.org.uk wrote: Peter Naulls pe...@chocky.org wrote: A simple Makefile might therefore look like this: CFLAGS = -I $(GCCSDK_INSTALL_ENV)/include LDFLAGS = -L $(GCCSDK_INSTALL_ENV)/lib etc. OK, that all seems to work, and it's a lot neater than having to use the riscos user -- thanks for the help. It now falls over on linking, with file not recognized: File format not recognized on the old OSLib32.o library. I assume this to simply be AOF vs ELF, in which case I'll return to it another day. You need OSLib 7 but that hasn't been released yet. An older set of binaries can be found at URL:http://joty.drobe.co.uk/oslib/, if you use UnixLib as runtime library, take the softfloat one; if you use SharedUnixLibrary in your program, take the 'module' one (SCL build SCL for module build should be the same for OSLib). In practice, it's probably just easier to build it yourself. This is very easy, e.g.: /usr/src/gccsdk/autobuilder/build oslib Also, DeskLib and a couple of other RISC OS libraries are there. ___ 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
