Note that I'm still working on updates to revdep-rebuild to allow it to work on IRIX: The system is largely Linux-compatible in this respect - with the enormous gaping hole that, whilst IRIX does have 'ldd' and it produces output in the expected format, and errors are output a way that it doesn't seem possible to capture: even redirecting all file-handles to a file results in an empty file and output on the terminal/console in use. The best solution to this appears to be an ldd-replacement wrapper. One of these currently exists and works, but only reports direct dependencies, rather than libraries required by a binary and the libraries it links to.
Created attachment 154071 [details] IRIX binutils/cctools wrapper Script lives in $EPREFIX/usr/mips-sgi-irix6.5/bin/ and this directory should appear as the first entry in $PATH. This directory also contains symlinks for 'c89', 'c99', 'cc', 'CC', 'ld', 'ranlib' and (optionally, for sys-libs/db) 'none'. Files named 'ar', 'as', 'nm', 'objdump', and 'strip' should not appear in this directory, as they break builds (due to not being MIPSpro/IRIX compatible).
I get a 404 on http://files.irix-tools.homeunix.net/irix/IRIX-MIPSpro-wrapper the attached version is ok/recent/latest?
Yeah - my RAID array died, taking the site with it :( I'll attach the latest version from my development box now...
Created attachment 162733 [details] IRIX binutils/cctools wrapper, version 20080811.2 Latest version. Wrapper functions are controlled by MIPSPRO_ environment variables: MIPSPRO_WRAPPER (default 1) - Enable(1)/Disable(0) all wrapper operations; MIPSPRO_DEBUG (def. 0) - Enable(1)/Disable(0) additional debugging output; MIPSPRO_VERBOSE (def. 0) - Enable(1)/Disable(0) verbose output(*); MIPSPRO_ALLOWNOSTD (def. 0) - Enable(1)/Disable(0) use of -nostdlib/-nostdinc; MIPSPRO_PERMISSIVE (def. 1) - Pass(1)/Drop(0) unrecognised options; MIPSPRO_MANGLE (def. 1) - Enable(1)/Disable(0) addition of optimisations. (*) There are a couple of packages whose configure assumes that any output is automatically bad, and so fail to build when verbose output is produced.
Do I understand correctly that this is a wrapper around the native compiler/linker to behave like the GNU-compiler/linker?
Well... sort of ;) It's a wrapper around the native compiler/linker to prevent broken ebuilds which assume a GNU toolchain from passing arguments which the native tools will barf on. Whilst it will try to translate options which have a differently-named counterpart, there are not very many cases where the match is close enough. This is primarily useful when -M* options are used. The wrapper optionally also auto-detects the platform in use and adds any safe optimisations which apply to this. Due to IRIX and the MIPS processors it runs on, this can be an easy big win. Finally, there are a small number of package-specific work-arounds. Certain other packages fail if built above -O1 (bash, for example - although this is now fixed in the ebuild), but since there's no way to reliably detect when one of these is being built, nothing is currently done.
Why I ask: mduft (still on holiday this week) has written a wrapper around M$ toolchain to behave like GNU toolchain, to build native Windows binaries with autotools, initially called "wgcc"[1]. AFAICT he wrote the second implementation "parity"[2] in a way that it's easy to add new backends (as well as frontents)... [1] http://interix-wgcc.sourceforge.net/ superseded by [2] http://sourceforge.net/projects/parity/ What I think of: Eventually the native IRIX toolchain can be added as new backend for parity. But we really have to wait for mduft here.
Interesting suggestion - but one that I feel is, with respect, totally wrong-headed: IRIX (as with any other UNIX) does have a full toolchain which is mature and works correctly. Indeed, most builds do complete successfully using it (which is no small miracle in itself!). The problem is with builds which blindly assume a GNU toolchain, or use GNU-specific constructs in their code without checking whether they are available during the configure stage. The latter can't be fixed with any form of wrapper, and the former is due to ignorance or indifference on the part of the upstream developers. Any package which doesn't work on IRIX is also likely to be broken with the native compilers on Solaris, AIX, Tru64, and all other minority platforms which haven't adopted GNU. The main use of the wrapper I've developed is to ensure that the correct "-L" and "-rpath" options are passed in order for a prefix installation to link to the correct libraries - everything else is an added bonus. (And I'd be wary of adopting any component at such low a level as the toolchain - therefore essential for system use - that's coded in C++. I've quickly browsed the parity source, and it looks as if it would likely be a significant amount of effort to port to anything other than Windows) I stand ready to be corrected ;)
(In reply to comment #8) > IRIX (as with any other UNIX) does have a full toolchain which is mature and > works correctly. Agreed (speaking for Solaris, AIX, HP-UX). Although (except for recent Solaris) they want extra money, especially for the C++ compilers. This is one reason ... > The problem is with builds which blindly assume a GNU toolchain, Agreed. ... and this is another reason why we try hard to use gcc everywhere. Although I'd love to have the option to use the native compilers too. What was the reason you cannot use gcc on IRIX? AFAICS, gcc should be useable on IRIX too[1]: [1] http://gcc.gnu.org/install/specific.html#mips-sgi-irix5 > The main use of the wrapper I've developed is to ensure that the correct "-L" > and "-rpath" options are passed in order for a prefix installation to link to > the correct libraries - everything else is an added bonus. The reason why I named my wrapper package[2] 'toolchain-prefix-wrapper' and not 'ld-prefix-wrapper' was that in principal it should be able to act as native compiler-wrapper too, even if support for that is not implemented yet. [2] http://sources.gentoo.org/viewcvs.py/gentoo-alt/trunk/toolchain-prefix-wrapper/ > I've quickly > browsed the parity source, and it looks as if it would likely be a significant > amount of effort to port to anything other than Windows) Most of parity is Windows specific. But (according to mduft) the parity framework without any platform specifics is very small, and you just might not have found it ;) But parity indeed seems oversized, and the IRIX-wrapping better could be placed in toolchain-prefix-wrapper.
> Agreed (speaking for Solaris, AIX, HP-UX). > Although (except for recent Solaris) they want extra money, especially for the > C++ compilers. > This is one reason ... SGI also want money for licenses for their compiler suite - but if you don't mind a message telling you this on &2 then you can get by regardless. I'm lucky - my machine had a full set of licenses included. > ... and this is another reason why we try hard to use gcc everywhere. I can absolutely see why this is... although in an ideal world, it would be nice to be compiler-agnostic. One day ;) > What was the reason you cannot use gcc on IRIX? It's not so much "cannot" as a matter of efficiency and usability: Although there are IRIX desktop systems running from quad-1GHz MIPS R16k processors, the vast majority of users on this platform will likely have systems of 180MHz - 400MHz. On such machines, small efficiencies can make a huge difference to perceptive performance, and code compiled with MIPSpro is often magnitudes faster than code compiled with gcc. It's unfortunate, but I've read that the gcc MIPS back-end isn't especially strong. The platform compilers are also supported by the SGI WorkShop/SpeedShop IDE, and have a autoparallelisation option which does seem to return good results on multi-CPU systems. The clincher for me, however, is the ability to debug code: MIPSpro dbx is the IRIX debugger, but sometimes struggles to analyse code produced by gcc correctly. gdb, on the other hand, can't seem to correctly debug anything produced by gcc - apparently due to a conflict with IRIX libc (although this may be heresy). When it comes down to it if all was equal then using GCC would greatly simplify running pretty much any software on IRIX - but given the speed decreases and the loss of debugging ability, soldiering on with the platform compilers seems to still be the best option. And we wouldn't want to make things too easy, would we? ;) > AFAICS, gcc should be useable on IRIX too[1]: > [1] http://gcc.gnu.org/install/specific.html#mips-sgi-irix5 We're actually talking IRIX6, but I take your point. I had heard that there was some issue which meant that working IRIX support was stuck as GCC 3.3, but this may well now have been overcome or solved. > The reason why I named my wrapper package[2] 'toolchain-prefix-wrapper' and not > 'ld-prefix-wrapper' was that in principal it should be able to act as native > compiler-wrapper too, even if support for that is not implemented yet. Exactly - and this is what IRIX-MIPSpro-wrapper does (hence the name ;) Whilst the inception was to add the correct options to 'ld', there are a significant minority of packages which won't compile without the build-stage fixes that the wrapper implements. > But parity indeed seems oversized, and the IRIX-wrapping better could be placed > in toolchain-prefix-wrapper. Would there be any milage in the thought of adding IRIX-MIPSpro-wrapper to it's own package pulled in only by the mips-irix profile so that the profile is at least usable, and then see where it can be integrated as we move along? Other small fixes needed - I've package.provided sys-devel/gcc* and sys-devel/binutils* - and get the message: " WARNING: Requested packages will not be merged because they are listed in package.provided: sys-devel/gcc pulled in by 'world' sys-devel/binutils pulled in by 'world' This problem can be solved in one of the following ways: A) Use emaint to clean offending packages from world (if not installed). B) Uninstall offending packages (cleans them from world). C) Remove offending entries from package.provided. The best course of action depends on the reason that an offending package.provided entry exists. " ... every time I run 'emerge'. Is there a fix for this - or a better way to prevent these from being pulled in in the first place? Also, 'euse' or 'emerge --info' say: $ euse -i X global use flags (searching: X) ************************************************************ !!! No gcc found. You probably need to 'source /etc/profile' !!! to update the environment of this terminal and possibly !!! other terminals also. $ emerge --info !!! No gcc found. You probably need to 'source /etc/profile' !!! to update the environment of this terminal and possibly !!! other terminals also. Portage 2.2.00.11421-prefix (default-prefix/irix/6.5/mips, [unavailable], unavailable, 6.5 IP35) ================================================================= System uname: IRIX-6.5-IP35-mips-32bit Timestamp of tree: Mon, 18 Aug 2008 09:11:32 +0000 Is there any simple way to remove the check for gcc (without breaking things)? The "unavailable" fields are compiler version (would 'cc -version', or 'cc --version' with the wrapper not suffice?) and libc version. IRIX libc outputs nothing when executed, so I'm not sure if this field can be usefully used. On the other hand, the 'irix/6.5' profile's package.provided lists 'sys-irix/libc-6.5' - could this value be used?
(In reply to comment #8) <snip> > The main use of the wrapper I've developed is to ensure that the correct "-L" > and "-rpath" options are passed in order for a prefix installation to link to > the correct libraries - everything else is an added bonus. hmm... ok, for that parity may be a little overkill :) > (And I'd be wary of adopting any component at such low a level as the toolchain > - therefore essential for system use - that's coded in C++. I've quickly > browsed the parity source, and it looks as if it would likely be a significant > amount of effort to port to anything other than Windows) > I stand ready to be corrected ;) feel corrected :) i think a backend for a new compiler and linker is no more work than one day. of course not all features of parity would be used then, but some things make sense on windows only, so that should be no problem. simply wrapping one compiler frontend to another should be as easy as writing something like [1] (which is the ms compiler backend) or [2] (which is the ms linker backend). added the similar files for IRIX native compiler should be not too much of a problem. as you can see those two files are quite simple. they just wrap the internal data structures into command line options for the real compiler/linker. adding library and runpaths could be done by configuration files then, no extra coding needed. as for porting the code: it's buildable with gcc and cl.exe, only some parts of the code would have to be disabled in non windows platforms, since it needs a windows compiler to build, but that doesn't matter. the base framework should be quite portable. i even built the base framework on an ia64-hpux, i guess that says all :) still it's up to you to decide. i just wanted to let you know, that i would be willing to help if you want to :) [1] http://parity.svn.sourceforge.net/viewvc/parity/trunk/parity.tasks/MsCompiler.cpp?revision=94&view=markup [2] http://parity.svn.sourceforge.net/viewvc/parity/trunk/parity.tasks/MsLinker.cpp?revision=100&view=markup
When the wrapper is installed as the first thing on a system, building bash with bootstrap-bash.sh fails: ./bootstrap-bash.sh $EPREFIX/tmp --12:05:47-- ftp://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz => `bash-3.2.tar.gz' Resolving ftp.gnu.org... 140.186.70.20 Connecting to ftp.gnu.org|140.186.70.20|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /gnu/bash ... done. ==> PASV ... done. ==> RETR bash-3.2.tar.gz ... done. Length: 2,529,838 (2.4M) (unauthoritative) 100%[====================================>] 2,529,838 340.84K/s ETA 00:00 12:05:56 (316.18 KB/s) - `bash-3.2.tar.gz' saved [2529838] checking build system type... mips-sgi-irix6.5 checking host system type... mips-sgi-irix6.5 checking for emacs... no checking for xemacs... no Beginning configuration for bash-3.2-release for mips-sgi-irix6.5 checking for gcc... c99 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. no arguments or description file (bu7). don't know how to make install (bu42). Looking into gentoo/tmp/bash-build/bash-3.2/config.log, here is the problem: configure:2142: checking for gcc configure:2168: result: c99 configure:2412: checking for C compiler version configure:2415: c99 --version </dev/null >&5 MIPSpro Compilers: Version 7.4.4m configure:2418: $? = 0 configure:2420: c99 -v </dev/null >&5 Unknown flag: r Unknown flag: r Unknown flag: r c99 ERROR: no source or object file given configure:2423: $? = 2 configure:2425: c99 -V </dev/null >&5 Unknown flag: r Unknown flag: r Unknown flag: r c99 ERROR: no source or object file given configure:2428: $? = 2 configure:2451: checking for C compiler default output file name configure:2454: c99 -I/home/portage/gentoo/usr/include conftest.c >&5 Unknown flag: r Unknown flag: r Unknown flag: r c99 ERROR: no source or object file given configure:2457: $? = 2 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "bash" | #define PACKAGE_TARNAME "bash" | #define PACKAGE_VERSION "3.2-release" | #define PACKAGE_STRING "bash 3.2-release" | #define PACKAGE_BUGREPORT "bug-bash@gnu.org" | #define ALIAS 1 | #define PUSHD_AND_POPD 1 | #define RESTRICTED_SHELL 1 | #define PROCESS_SUBSTITUTION 1 | #define PROMPT_STRING_DECODE 1 | #define SELECT_COMMAND 1 | #define HELP_BUILTIN 1 | #define ARRAY_VARS 1 | #define DPAREN_ARITHMETIC 1 | #define BRACE_EXPANSION 1 | #define COMMAND_TIMING 1 | #define EXTENDED_GLOB 1 | #define COND_COMMAND 1 | #define COND_REGEXP 1 | #define ARITH_FOR_COMMAND 1 | #define NETWORK_REDIRECTIONS 1 | #define PROGRAMMABLE_COMPLETION 1 | #define DEBUGGER 1 | #define MEMSCRAMBLE 1 | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2495: error: C compiler cannot create executables See `config.log' for more details. Note that the use of c99 and -I/home/portage/gentoo/usr/include come from my CC/CFLAGS settings, but the same thing happens even if I unset those vars.
Here's the actual offender: If you manually run "cc -v </dev/null >&1", like bash's configure script does, this comes out as an error: Unknown flag: r Unknown flag: r Unknown flag: r cc ERROR: no source or object file given
Non-wrapped version returns: cc -v </dev/null >&1 MIPSpro Compilers: Version 7.4.4m
I wouldn't be surprised if that would be caused by not having a "good" bash. Nice chicken/egg problem then. Can't you bootstrap it without the wrapper?
I did have a good bash installed from other source. I think this whole (simple) problem has to do with wrapper's response to cc -v.
This is why I included debug options ;) Please export MIPSPRO_VERBOSE=1 MIPSPRO_DEBUG=1 and then try again.
It's worth pointing out that with a bootstrapped system with bash already installed, bash can be built. It's also worth point out that any bash built on IRIX with the MIPSpro compilers with any optimisation above -O1 is broken, and may be the cause of the problem. This (currently) includes neko_bash.tardist :(
in our ebuild: # IRIX's MIPSpro produces garbage with >= -O2, bug #209137 [[ ${CHOST} == mips-sgi-irix* ]] && replace-flags -O? -O1
Ah - I know what the problem is! The wrapper script uses 'sed -r', which is a GNU option. If the system sed is invoked with this option, it outputs 'Unknown flag: r' - so the output isn't from the compiler (which isn't being passed incorrect parameters), it's from the script's internal operations. The quick fix is to not use the wrapper until after sed is built (and it is one of the very early packages to bootstrap). In the meantime, I'll try to find a useful work-around...
In principle, my bootstrap order is organised to be first installing some really core packages (bash, sed, grep off the top of my head), then dump in Portage. I think it would be great if the wrapper would only kick in when Portage is installed, but I'm not sure how doable this is. Then still, the wrapper can become a part of the bootstrap, after bash and sed then, if those compile with MIPSpro tools...
(In reply to comment #20) > Ah - I know what the problem is! > > The wrapper script uses 'sed -r', which is a GNU option. You're right. GNU sed fixes the problem and the thing works. (You also write in the top of the script that gnu sed is a requirement, my bad for not spotting it.)
Patch against 20080811.2 attachment to address problems of Bug 223351 --- IRIX-MIPSpro-wrapper-20080811.2 2008-08-21 15:03:19.748636800 +0100 +++ IRIX-MIPSpro-wrapper-20080821.1 2008-08-21 15:04:10.801645600 +0100 @@ -24,12 +24,34 @@ # Required tools: # /bin/uname, /sbin/hinv, tr, grep, cut, GNU sed, sort, head # -# Version 20080811.2 +# Version 20080821.1 # #set -o xtrace # +# Try to confirm that essential GNU versions of tools are available... +# +sed -r -h &>/dev/null +case $? in + 2) # SGI sed? + echo -e "\nWARNING: SGI sed (rather than GNU sed) seems to first in your \$PATH" + echo " Disabling wrapper" + echo + MIPSPRO_WRAPPER=0 + ;; + 4) # GNU sed? + : + ;; + *) # Not a clue! + echo -e "\nWARNING: Unknown sed found - here be dragons" + echo " Please check your \$PATH" + echo + ;; +esac + +# # Environment variables which will affect operation... # @@ -99,6 +121,9 @@ case $tool in ;; esac +# Shortcut attempts to find the version (only) +[ "$@" = "-v" ] && exec /bin/$tool "$@" + shopt -s extglob || die "FATAL: Cannot enable shell option 'extglob'," \ "is $( type -p bash ) really bash?"
(This is 223351! - it's been a long day ;)
Any chance your website comes back soon? I don't dare to put your GPLv3 script in our tree, so I like to download it separately.
Isn't it back? I can click on the link and get the file.
I guess I'm impatient, > 1 minute waiting time means "down" for me ;) (especially when it says "No suitable nodes are available to serve your request.")
Sorry, guys - my website is stored on a RAID array which has been dropping discs lately, and sometimes needs a kick to restart itself. I'm in the process of building a stand-alone webserver to hold this content, but until then please bear with me...
What are the issues with distribution of GPLv3 code? I don't see that the license of the wrapper script impinges on anything else in the tree or anything else built through it... I could add an additional clause specifically allowing distribution for Gentoo-related usage, but this doesn't seem to be prohibited by any of the current terms. What were your specific concerns that would need to be addressed before the script as attached (with patch provided) could be directly incorporated into the tree?
The problem is simple: If I add (a copy of) your script to our tree, it is an GPLv3 thing. Now Gentoo has chosen not to move to GPLv3 for some reasons which IIRC involved the the new way in which the licence tries to transform everything which it touches into GPLv3 as well. I'm not an expert in this area, but I just don't like it. Hence I'd rather just be able to download it, which is currently (aparently) all covered.
I've been upgrading this script over time, and I think it now covers most bases, except for one persistent problem: Some build processes, such as that of gtk+-2 and libIDL, pass strings to the compiler such as: gtk+: cc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"Gtk\" -DGTK_LIBDIR=\"/opt/portage/usr/lib\" -DGTK_DATADIR=\"/opt/portage/usr/share\" -DGTK_DATA_PREFIX=\"/opt/portage/usr\" -DGTK_SYSCONFDIR=\"/opt/portage/etc\" -DGTK_VERSION=\"2.12.12\" -DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"mips-sgi-irix6.5\" -DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"file,lpr\" "-DGTK_PRINT_PREVIEW_COMMAND=\"evince --unlink-tempfile --preview --print-settings %s %f\"" -I../gtk -I.. -I../gdk -I../gdk -I../gdk-pixbuf -I../gdk-pixbuf -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_FILE_SYSTEM_ENABLE_UNSUPPORTED -DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -DG_DISABLE_CAST_CHECKS -D_REENTRANT ... cc-1008 cc: ERROR File = gtksettings.c, Line = 751 A new-line character appears inside a string literal. GTK_PRINT_PREVIEW_COMMAND, ^ 1 error detected in the compilation of "gtksettings.c". libIDL: cc -DPACKAGE_NAME=\"libIDL\" -DPACKAGE_TARNAME=\"libIDL\" -DPACKAGE_VERSION=\"0.8.12\" "-DPACKAGE_STRING=\"libIDL 0.8.12\"" "-DPACKAGE_BUGREPORT=\"http://bugzilla.gnome.org/enter_bug.cgi?product=libIDL\"" -DLIBIDL_VERSION=\"0.8.12\" -DHAVE_CPP_PIPE_STDIN=1 -DCPP_NOSTDINC=\"-I-\" "-DCPP_PROGRAM=\"cc -E\"" -DCPP_PATHS=\"\" -DYYTEXT_POINTER=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE_STDDEF_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DHAVE_POPEN=1 -DHAVE_SYMLINK=1 -DHAVE_ACCESS=1 -DSIZEOF_LONG_LONG=8 -I. -DYYDEBUG=1 -DYYERROR_VERBOSE=1 -I/opt/gentoo/usr/include/glib-2.0 -I/opt/gentoo/usr/lib/glib-2.0/include -I./include -DG_LOG_DOMAIN=\"libIDL\" ... cc-1008 cc: ERROR File = util.c, Line = 235 A new-line character appears inside a string literal. char *fmt = CPP_PROGRAM " " CPP_NOSTDINC " - %s%s %s < \"%s\" %s"; ^ 1 error detected in the compilation of "util.c". ... presumably, these quotes are unescaped by the shell when the wrapper script is invoked, and I can't find a sensible way to re-quote where necessary so that the compiler receives the right information (if this is the problem). In the gtk+ example above, the arguments the wrapper script actually receives are: -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN="Gtk" -DGTK_LIBDIR="/opt/portage/usr/lib" -DGTK_DATADIR="/opt/portage/usr/share" -DGTK_DATA_PREFIX="/opt/portage/usr" -DGTK_SYSCONFDIR="/opt/portage/etc" -DGTK_VERSION="2.12.12" -DGTK_BINARY_VERSION="2.10.0" -DGTK_HOST="mips-sgi-irix6.5" -DGTK_COMPILATION -DGTK_PRINT_BACKENDS="file,lpr" -DGTK_PRINT_PREVIEW_COMMAND="evince --unlink-tempfile --preview --print-settings %s %f" -I../gtk -I.. -I../gdk -I../gdk -I../gdk-pixbuf -I../gdk-pixbuf -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_FILE_SYSTEM_ENABLE_UNSUPPORTED -DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -DG_DISABLE_CAST_CHECKS -D_REENTRANT ... this is then passed on to the compiler in the above form (using 'exec "/bin/$tool" $output' where $tool is 'cc', in this case), and fails. I notice, however, that the compiler output is different if I invoke the exact same command directly - this time failing with: cc-1020 cc: ERROR File = /opt/portage/usr/include/glib-2.0/glib/gmessages.h, Line = 184 The identifier "Gtk" is undefined. g_logv (G_LOG_DOMAIN, G_LOG_LEVEL_ERROR, format, args); ^ ... does this mean that I'm barking up the wrong tree, and the problem isn't with the escaping, but with how I'm calling the compiler? Does 'exec' have different semantics to merely invoking a command? (Incidentally, this is a *horrible* way to hard-code values... what's wrong with a config.h??)
(In reply to comment #31) > cc-1008 cc: ERROR File = gtksettings.c, Line = 751 > A new-line character appears inside a string literal. > and I can't find a sensible way to re-quote where necessary Basically there are two useful ways of quoting: 1) use bash-arrays for argument passing (haven't found an easier syntax), something like: - output="$output $argument" + output=( "${output[@]}" "${argument}" ) - local input="$@" + local input=( "$@" ) - for argument in $input; do + for argument in "${input[@]}"; do - pass2 "$output" + pass2 "${output[@]}" *) use single-quotes in combination with eval: possible, but harder than bash-arrays: try using bash-arrays. > (Incidentally, this is a *horrible* way to hard-code values... what's wrong > with a config.h??) Well, using config.h is *optionally* supported by autotools, and the wrapper should work with any valid argument passed.
Created attachment 181860 [details] IRIX binutils/cctools wrapper, version 20090212.1 Many thanks! Changing the wrapper to use bash arrays, whilst somewhat laborious, has uncovered a few other bugs and fixed the string-quoting problem! I've performed some testing, all of which seems fine, and I'm now rebuilding a couple of systems using the new version to verify correct behaviour and to see whether any currently-broken packages will now work. I've also relicensed the script under GPL2, so that it could potentially be distributed as a prefix package at some point in the future.
Created attachment 187772 [details] IRIX binutils/cctools wrapper, version 20090409.1 Fix a mis-handling of GNU '--options' which was causing libgamin to fail to build.
url is no longer valid. I added sys-devel/irixmipspro-wrappers Please have a look at it, and see if it does anything close to what it should. I had to guess in numerous places...
Created attachment 206422 [details] IRIX binutils/cctools wrapper, version 20090923.1 Sorry for the late reply, I've had a stinker of a cold recently... Attached is a tarball of the latest wrapper, along with the symlinks vital to its correct operation. This should be unpacked to $EPREFIX, so that the files end up in $EPREFIX/sbin and $EPREFIX/usr/mips-sgi-irix6.5/bin/ I also have the following set in the 'portage' user's .bashrc (although it might be relocatable to $EPREFIX/env.d, or better suited to make.conf?): EPREFIX="/opt/gentoo" CHOST="mips-sgi-irix6.5" PATH="\ ${EPREFIX}/home/bin:\ ${EPREFIX}/sbin:${EPREFIX}/usr/sbin:\ ${EPREFIX}/usr/${CHOST}/bin:\ ${EPREFIX}/usr/bin:${EPREFIX}/bin:\ /opt/bin:/usr/local/bin:\ /usr/bsd/bin:/usr/bsd/sbin:$PATH" export PATH CHOST EPREFIX LIBDIR="lib" BINUTILSLIBDIR="$( readlink -e ${EPREFIX}/usr/${LIBDIR}/binutils/mips-sgi-irix6.5/* )" LD_LIBRARYN32_PATH="${EPREFIX}/usr/${LIBDIR}:${EPREFIX}/${LIBDIR}:${EPREFIX}/usr/${LIBDIR}/nspr:${BINUTILSLIBDIR}" export LD_LIBRARYN32_PATH CC="cc" BUILD_CC="cc" CXX="CC" CXXCPP="CC -E" CONFIG_SHELL="$( type -pf bash )" export CC BUILD_CC CXX CXXCPP CONFIG_SHELL PKG_CONFIG_PATH=${EPREFIX}/usr/${LIBDIR}/pkgconfig export PKG_CONFIG_PATH XDG_DATA_HOME=${EPREFIX}/usr/share XDG_DATA_DIRS=${EPREFIX}/usr/share export XDG_DATA_HOME XDG_DATA_DIRS ... the only other issue I'm aware of is that breakage can occur if CFLAGS (and possibly LDFLAGS et al) aren't set in the environment or in make.conf - I think I accidentally commented both out one time, and builds failed in subtle ways. I seem to remember thinking that builds were tripping on functions such as append-flags or strip-flags - but it's entirely possible that there's some oversight in the wrapper.
I have no idea what happened to the spacing there! That should have been: EPREFIX="/opt/gentoo" CHOST="mips-sgi-irix6.5" PATH="\ ${EPREFIX}/home/bin:\ ${EPREFIX}/sbin:${EPREFIX}/usr/sbin:\ ${EPREFIX}/usr/${CHOST}/bin:\ ${EPREFIX}/usr/bin:${EPREFIX}/bin:\ /opt/bin:/usr/local/bin:\ /usr/bsd/bin:/usr/bsd/sbin:$PATH" export PATH CHOST EPREFIX LIBDIR="lib" BINUTILSLIBDIR="$( readlink -e ${EPREFIX}/usr/${LIBDIR}/binutils/mips-sgi-irix6.5/* )" LD_LIBRARYN32_PATH="${EPREFIX}/usr/${LIBDIR}:${EPREFIX}/${LIBDIR}:${EPREFIX}/usr/${LIBDIR}/nspr:${BINUTILSLIBDIR}" export LD_LIBRARYN32_PATH CC="cc" BUILD_CC="cc" CXX="CC" CXXCPP="CC -E" CONFIG_SHELL="$( type -pf bash )" export CC BUILD_CC CXX CXXCPP CONFIG_SHELL PKG_CONFIG_PATH=${EPREFIX}/usr/${LIBDIR}/pkgconfig export PKG_CONFIG_PATH XDG_DATA_HOME=${EPREFIX}/usr/share XDG_DATA_DIRS=${EPREFIX}/usr/share export XDG_DATA_HOME XDG_DATA_DIRS
Created attachment 227113 [details] IRIX binutils/cctools wrapper, version 20100316.1
Created attachment 231107 [details] IRIX binutils/cctools wrapper, version 20100511.1 Add support for -'dumpmachine'; remove broken skip functionality; correctly handle XPG4 options; transform -qchars for media-sound/xmp.
We are sorry to close this bug. We lack the man-power and devotion to support mips-irix in the tree.
