sqlite auto-generates a 'parse.h' header, which on IRIX is correctly but contains junk characters ("^@"s and "0"s) inserted between the symbol being defined and the value. I can successfully build sqlite by editing the ebuild file so that the 'econf' step is performed as part of 'src_unpack', and using the ebuild command to compile the package (which will fail), editing 'parse.h', and the compiling again. I replaced the characters in vim with ':%s/^@\+0* / /g', which entirely clears the problem and results in the correct formatting as a result too. The real question is - where is this junk being generated?? (The output before fixing parse.h was: >>> Compiling source in /usr/opt/portage/var/tmp/portage/dev-db/sqlite-3.5.6/work/sqlite-3.5.6 ... sed -e s/--VERS--/3.5.6/ ./src/sqlite.h.in | \ sed -e s/--VERSION-NUMBER--/3005006/ >sqlite3.h cc -c99 -O2 -n32 -mips4 -DSQLITE_SOUNDEX=1 -o lemon ./tool/lemon.c cp ./tool/lempar.c . cp ./src/parse.y . ./lemon parse.y mv parse.h parse.h.temp gawk -f ./addopcodes.awk parse.h.temp >parse.h cat parse.h ./src/vdbe.c | gawk -f ./mkopcodeh.awk >opcodes.h ./libtool --mode=compile --tag=CC cc -c99 -O2 -n32 -mips4 -DSQLITE_SOUNDEX=1 -I. -I./src -DNDEBUG -DSQLITE_ALLOW_XTHREAD_CONNECT=1 -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -c ./src/alter.c mkdir .libs cc -c99 -O2 -n32 -mips4 -DSQLITE_SOUNDEX=1 -I. -I./src -DNDEBUG -DSQLITE_ALLOW_XTHREAD_CONNECT=1 -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -c ./src/alter.c -DPIC -o .libs/alter.o cc-3342 cc: ERROR File = ./parse.h, Line = 1 An invalid character appears in the input line. #define TK_SEMI 00 1 ^ cc-3342 cc: ERROR File = ./parse.h, Line = 2 An invalid character appears in the input line. #define TK_EXPLAIN 2 ^ cc-3342 cc: ERROR File = ./parse.h, Line = 3 An invalid character appears in the input line. #define TK_QUERY 0 3 ^ ... etc. All of the characters indicated are the ^@ control-characters.) I suppose that the ebuild could be updated to remove instances of corruption - but that'd be a nasty hack :(
Additionally, even though tcl is successfully installed, sqlite fails with FEATURES="test" because non the of Tcl* symbols resolve when linked: ./libtool --mode=link cc -c99 -O2 -n32 -mips4 -DSQLITE_SOUNDEX=1 -I. -I./src -DNDEBUG -DSQLITE_ALLOW_XTHREAD_CONNECT=1 -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 \ -DSQLITE_NO_SYNC=1 -DTEMP_STORE=1 \ -o testfixture ./src/attach.c ./src/btree.c ./src/build.c ./src/date.c ./src/expr.c ./src/func.c ./src/insert.c ./src/malloc.c ./src/os.c ./src/os_os2.c ./src/os_unix.c ./src/os_win.c ./src/pager.c ./src/pragma.c ./src/prepare.c ./src/printf.c ./src/random.c ./src/select.c ./src/test1.c ./src/test2.c ./src/test3.c ./src/test4.c ./src/test5.c ./src/test6.c ./src/test7.c ./src/test8.c ./src/test9.c ./src/test_autoext.c ./src/test_async.c ./src/test_btree.c ./src/test_config.c ./src/test_devsym.c ./src/test_hexio.c ./src/test_malloc.c ./src/test_md5.c ./src/test_onefile.c ./src/test_schema.c ./src/test_server.c ./src/test_tclvar.c ./src/test_thread.c ./src/tokenize.c ./src/utf.c ./src/util.c ./src/vdbe.c ./src/vdbeapi.c ./src/vdbeaux.c ./src/vdbemem.c ./src/where.c parse.c ./src/tclsqlite.c \ libsqlite3.la cc -c99 -O2 -n32 -mips4 -DSQLITE_SOUNDEX=1 -I. -I./src -DNDEBUG -DSQLITE_ALLOW_XTHREAD_CONNECT=1 -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 -DSQLITE_NO_SYNC=1 -DTEMP_STORE=1 -o .libs/testfixture ./src/attach.c ./src/btree.c ./src/build.c ./src/date.c ./src/expr.c ./src/func.c ./src/insert.c ./src/malloc.c ./src/os.c ./src/os_os2.c ./src/os_unix.c ./src/os_win.c ./src/pager.c ./src/pragma.c ./src/prepare.c ./src/printf.c ./src/random.c ./src/select.c ./src/test1.c ./src/test2.c ./src/test3.c ./src/test4.c ./src/test5.c ./src/test6.c ./src/test7.c ./src/test8.c ./src/test9.c ./src/test_autoext.c ./src/test_async.c ./src/test_btree.c ./src/test_config.c ./src/test_devsym.c ./src/test_hexio.c ./src/test_malloc.c ./src/test_md5.c ./src/test_onefile.c ./src/test_schema.c ./src/test_server.c ./src/test_tclvar.c ./src/test_thread.c ./src/tokenize.c ./src/utf.c ./src/util.c ./src/vdbe.c ./src/vdbeapi.c ./src/vdbeaux.c ./src/vdbemem.c ./src/where.c parse.c ./src/tclsqlite.c ./.libs/libsqlite3.so -lpthread -Wl,-rpath -Wl,/opt/portage/usr/lib ./src/attach.c: ./src/btree.c: ./src/build.c: ./src/date.c: ./src/expr.c: ./src/func.c: ./src/insert.c: ./src/malloc.c: ./src/os.c: ./src/os_os2.c: ./src/os_unix.c: ./src/os_win.c: ./src/pager.c: ./src/pragma.c: ./src/prepare.c: ./src/printf.c: ./src/random.c: ./src/select.c: ./src/test1.c: cc-1140 cc: WARNING File = ./src/test1.c, Line = 3553 A value of type "void *" cannot be used to initialize an entity of type "const char *(*)(sqlite3_stmt *, int)". const char *(*xFunc)(sqlite3_stmt*, int) = clientData; ^ cc-1140 cc: WARNING File = ./src/test1.c, Line = 3607 A value of type "void *" cannot be used to initialize an entity of type "const void *(*)(sqlite3_stmt *, int)". const void *(*xFunc)(sqlite3_stmt*, int) = clientData; ^ cc-1140 cc: WARNING File = ./src/test1.c, Line = 3644 A value of type "void *" cannot be used to initialize an entity of type "int (*)(sqlite3_stmt *, int)". int (*xFunc)(sqlite3_stmt*, int) = clientData; ^ ./src/test2.c: ./src/test3.c: ./src/test4.c: ./src/test5.c: ./src/test6.c: ./src/test7.c: ./src/test8.c: ./src/test9.c: ./src/test_autoext.c: ./src/test_async.c: ./src/test_btree.c: ./src/test_config.c: ./src/test_devsym.c: ./src/test_hexio.c: ./src/test_malloc.c: ./src/test_md5.c: ./src/test_onefile.c: ./src/test_schema.c: ./src/test_server.c: ./src/test_tclvar.c: ./src/test_thread.c: ./src/tokenize.c: ./src/utf.c: ./src/util.c: ./src/vdbe.c: ./src/vdbeapi.c: ./src/vdbeaux.c: ./src/vdbemem.c: ./src/where.c: parse.c: ./src/tclsqlite.c: ld32: Mapped === ./.libs/libsqlite3.so ==== at address 0x41e4000 ld32: Processing ./.libs/libsqlite3.so. ld32: WARNING 85 : Definition of sqlite3_enable_shared_cache in btree.o preempts that definition in ./.libs/libsqlite3.so. ld32: WARNING 85 : Definition of sqlite3_soft_heap_limit in malloc.o preempts that definition in ./.libs/libsqlite3.so. ... ld32: Giving up after printing 50 warnings. Use -wall to print all warnings. ld32: ERROR 33 : Unresolved text symbol "Tcl_WrongNumArgs" -- 1st referenced by test1.o. ld32: ERROR 33 : Unresolved text symbol "Tcl_GetString" -- 1st referenced by test1.o. ld32: ERROR 33 : Unresolved text symbol "Tcl_GetCommandInfo" -- 1st referenced by test1.o. ld32: ERROR 33 : Unresolved text symbol "Tcl_AppendResult" -- 1st referenced by test1.o. ...
What is interesting here is that addopcodes.awk has a shebang pointing to /usr/bin/awk. Now technically, gawk is being run and the file is given as argument, but I'm still wondering whether this perhaps could go wrong. Since it complains about TK_SEMI (the first entry, not even added by the AWK script, but just echoed (print $0), which here for me is generated by lemon and looks like this: #define TK_SEMI 1 I get the impression that lemon is the thing that's wrong in your case, as I have only spaces, nothing weird. Looks like this piece of code is where it is printed (tool/lemon.c:3568) fprintf(out,"#define %s%-30s %2d\n",prefix,lemp->symbols[i]->name,i); Does IRIX' libc like the string fill formatter? Looks like it does some filling and then at the end inserts some garbage. Seems unlikely that lemp->symbols[i]->name contains garbage (to me). What if we say goodbye to nice formatting, and just use "#define %s%s %2d\n" instead? Would that solve the weirdness?
A quick test suggests that string fill formatting does work on IRIX - but I'll give sqlite a try without it (who needs fancy spacing anyway?) to see if it makes a difference...
There's *lots* of files running utilities outside of the prefix :( However, addopcodes.awk doesn't seem to be the problem: this acts on parse.h.temp, *which is already corrupt*! This pretty much proves that lemon is at fault. Infact, "parse.out" generated by lemon starts with: State 0: input ::= * cmdlist cmdlist ::= * cmdlist ecmd cmdlist ::= * ecmd ecmd ::= * SEMI ecmd ::= * explain cmdx SEMI (6) explain ::= * explain ::= * EXPLAIN explain ::= * EXPLAIN QUERY PLAN ^@^@^@^@00 SEMI shift 436 ^@^@^@ EXPLAIN shift 386 ^@^@^@^@0 input accept ^@^@^@ cmdlist shift 132 ^@^@^@^@00 ecmd shift 414 ^@^@^@ explain shift 2 ^@ {default} reduce 6 ... so this is corrupt too. Removing the string-fill formats from tools/lemon.c seems to fix the parse.h output, though.
lemon works on parse.y, is that still a valid file?
I just fixed readline detection in configure call, what files do you see that do not respect the prefix?
I can't interpret parse.y manually, but it looks valid. It might have junk in it, of course, but I can't see it if there is... Scripts which aren't prefix-aware: addopcodes.awk:#!/usr/bin/awk configure:#! /bin/sh config.guess:#! /bin/sh config.sub:#! /bin/sh ext/fts2/mkfts2amal.tcl:#!/usr/bin/tclsh ext/fts3/mkfts3amal.tcl:#!/usr/bin/tclsh install-sh:#!/bin/sh Makefile:#!/usr/make Makefile.arm-wince-mingw32ce-gcc:#!/usr/make Makefile.in:#!/usr/make Makefile.in.orig:#!/usr/make Makefile.linux-gcc:#!/usr/make mkdll.sh:#!/bin/sh mkextu.sh:#!/bin/sh mkextw.sh:#!/bin/sh mkopcodec.awk:#!/usr/bin/awk -f mkopcodeh.awk:#!/usr/bin/awk -f mkso.sh:#!/bin/sh publish.sh:#!/bin/sh publish_osx.sh:#!/bin/sh tool/speedtest2.tcl:#!/usr/bin/tclsh tool/mksqlite3c.tcl:#!/usr/bin/tclsh tool/mksqlite3internalh.tcl:#!/usr/bin/tclsh tool/soak1.tcl:#!/usr/bin/tclsh tool/speedtest.tcl:#!/usr/bin/tclsh tool/mkopts.tcl:#!/usr/bin/tclsh www/version3.tcl:#!/usr/bin/tclsh www/quickstart.tcl:#!/usr/bin/tclsh www/oldnews.tcl:#!/usr/bin/tclsh www/mkapidoc.tcl:#!/usr/bin/tclsh www/index.tcl:#!/usr/bin/tclsh (on IRIX all of these interpretor binaries are valid - and most likely incompatible with the usage they are being put to, due to age or being non-GNU. Not an issue if they aren't directly invoked, of course...)
There's a new, seemingly related problem in sqlite-3.6.10: Around line 86228, sqlite3.c contains: /* Include keywordhash.h in the middle of tokenize.c */ /* Begin file keywordhash.h */ /***** This file contains automatically generated code ****** ** ** The code in this file has been automatically generated by ** ** $Header: /sqlite/sqlite/tool/mkkeywordhash.c,v 1.36 2008/12/31 21:52:41 drh Exp $ ** ** The code in this file implements a function that determines whether ** or not a given identifier is really an SQL keyword. The same thing ** might be implemented more directly using a hand-written hash table. ** But by using this automatically generated code, the size of the code ** is substantially reduced. This is important for embedded applications ** on platforms with limited memory. */ /* Hash score: 171 */ static int keywordCode(const char *z, int n){ /* zText[] encodes 801 bytes of keywords in 541 bytes */ /* REINDEXEDESCAPEACHECKEYBEFOREIGNOREGEXPLAINSTEADDATABASELECT */ /* ABLEFTHENDEFERRABLELSEXCEPTRANSACTIONATURALTERAISEXCLUSIVE */ /* XISTSAVEPOINTERSECTRIGGEREFERENCESCONSTRAINTOFFSETEMPORARY */ /* UNIQUERYATTACHAVINGROUPDATEBEGINNERELEASEBETWEENOTNULLIKE */ /* CASCADELETECASECOLLATECREATECURRENT_DATEDETACHIMMEDIATEJOIN */ /* SERTMATCHPLANALYZEPRAGMABORTVALUESVIRTUALIMITWHENWHERENAME */ /* AFTEREPLACEANDEFAULTAUTOINCREMENTCASTCOLUMNCOMMITCONFLICTCROSS */ /* CURRENT_TIMESTAMPRIMARYDEFERREDISTINCTDROPFAILFROMFULLGLOBYIF */ /* ISNULLORDERESTRICTOUTERIGHTROLLBACKROWUNIONUSINGVACUUMVIEW */ /* INITIALLY ^@^@^@^@00000000000000000000^@^@^@^@012345678 ^@^@^@^@0000000000000 */ ... with the ^@'s on the final line throwing off the compiler even through they're within a comment.
The code generating this error in sqlite3.c is the following from tool/mkkeywordhash.c: if( j>0 ){ printf("%*s */\n", 74-j, ""); } What happens if j>=74? I've not tested it, but it strikes me as entirely possible that the IRIX C library might do something strange if asked to string-fill a zero or negative number of spaces... I suspect that, as with Bug 223873, this is simply a case of the developers not accounting for edge-cases. (The string-fill operator doesn't seem to be broken in general cases: sqlite makes extensive use of them, and only this breakage seems to occur)
This can how be worked-around (although it's a nasty hack) with the following ebuild change and patch: --- sqlite-3.6.15.ebuild +++ sqlite-3.6.15.ebuild @@ -39,6 +39,8 @@ src_prepare() { epatch "${FILESDIR}"/${PN}-3.6.2-interix.patch epatch "${FILESDIR}"/${PN}-3.6.11-interix.patch + epatch "${FILESDIR}"/${PN}-3.6-irix.patch + epunt_cxx } @@ -59,6 +61,18 @@ src_configure() { } src_compile() { + if [[ ${CHOST} == *-irix* ]]; then + for FILE in $( + find "${S}" -type f + ); do + grep "%-[0-9]\+s" "$FILE" >/dev/null 2>&1 && \ + sed -i 's/%-[0-9]\+s/%s/g' "$FILE" + + head -n 1 "$FILE" | grep "^#\![[:space:]]*/" | grep -v "$EPREFIX" >/dev/null 2>&1 && \ + sed -i "s|^#![[:space:]]*/|#!$EPREFIX/|" "$FILE" + done + fi + emake TCLLIBDIR="${EPREFIX}/usr/$(get_libdir)/${P}" || die "emake failed" }
Created attachment 196255 [details, diff] Patch to remove string-formatting code, to enable builds on IRIX The TCL scripts are just dumb, breaking if the length of a file-patch is greater than 65 characters - but I don't know why the string-formatting within the C code fails. This does, however, allow sqlite to build on IRIX, with the only apparent side-effect being slightly less-nicely formatted output...
this still applies to sqlite-3.6.19?
Yup - applies to all 3.6.x so far. I'll attach my ebuild for the latest sqlite with the patch mentioned in Comment #10. It's worked for all versions for the last one-and-a-half (or so) years(!)...
Created attachment 208378 [details] sqlite-3.x ebuild with IRIX patch and string-format hack Patch from Comment #11 is still identical, latest ebuild attached.
We are sorry to close this bug. We lack the man-power and devotion to support mips-irix in the tree.
