Subject: The wrong-gcc problem

From: Рубен Бучацкий<[email-masked]>
Date: Tue, 13 Sep 2011 17:43:01 +0400

Hello!

I'm building Sqlite 3.7.7.1 with libtool 2.4. I'm doing the cross
compile. Configuring sqlite with CC="my compiler". In compilation mode
everything is ok, but when I link, libtool tries to call the native
gcc (in spite of the fact, that CC="my compiler", not native).

*~/libtool-2.4/libtool* --tag=CC --mode=link *
/home/ruben/x-tools/gcc-trunk-clean/bin/arm-unknown-linux-gnueabi-gcc*   -O2
-mcpu=cortex-a8 -mtune=cortex-a8 -mfloat-abi=softfp -mfpu=neon -mthumb -flto
-DSQLITE_OS_UNIX=1 -I. -I./src -I./ext/rtree -D_HAVE_SQLITE_CONFIG_H
-DNDEBUG   -DSQLITE_THREADSAFE=1 -DSQLITE_OMIT_LOAD_EXTENSION=1     -o
libsqlite3.la alter.lo analyze.lo attach.lo auth.lo backup.lo bitvec.lo
btmutex.lo btree.lo build.lo callback.lo complete.lo ctime.lo date.lo
delete.lo expr.lo fault.lo fkey.lo fts3.lo fts3_aux.lo fts3_expr.lo
fts3_hash.lo fts3_icu.lo fts3_porter.lo fts3_snippet.lo fts3_tokenizer.lo
fts3_tokenizer1.lo fts3_write.lo func.lo global.lo hash.lo icu.lo insert.lo
journal.lo legacy.lo loadext.lo main.lo malloc.lo mem0.lo mem1.lo mem2.lo
mem3.lo mem5.lo memjournal.lo mutex.lo mutex_noop.lo mutex_os2.lo
mutex_unix.lo mutex_w32.lo notify.lo opcodes.lo os.lo os_os2.lo os_unix.lo
os_win.lo pager.lo parse.lo pcache.lo pcache1.lo pragma.lo prepare.lo
printf.lo random.lo resolve.lo rowset.lo rtree.lo select.lo status.lo
table.lo tokenize.lo trigger.lo update.lo util.lo vacuum.lo vdbe.lo
vdbeapi.lo vdbeaux.lo vdbeblob.lo vdbemem.lo vdbetrace.lo wal.lo walker.lo
where.lo utf.lo vtab.lo -lpthread  \
 -rpath "/home/ruben/condor/testings/sqlitesrc/sqlite-src-3070701/build/lib"
-version-info "8:6:8"
libtool: link: *gcc* -shared  -fPIC -DPIC  .libs/alter.o .libs/analyze.o
.libs/attach.o .libs/auth.o .libs/backup.o .libs/bitvec.o .libs/btmutex.o
.libs/btree.o .libs/build.o .libs/callback.o .libs/complete.o .libs/ctime.o
.libs/date.o .libs/delete.o .libs/expr.o .libs/fault.o .libs/fkey.o
.libs/fts3.o .libs/fts3_aux.o .libs/fts3_expr.o .libs/fts3_hash.o
.libs/fts3_icu.o .libs/fts3_porter.o .libs/fts3_snippet.o
.libs/fts3_tokenizer.o .libs/fts3_tokenizer1.o .libs/fts3_write.o
.libs/func.o .libs/global.o .libs/hash.o .libs/icu.o .libs/insert.o
.libs/journal.o .libs/legacy.o .libs/loadext.o .libs/main.o .libs/malloc.o
.libs/mem0.o .libs/mem1.o .libs/mem2.o .libs/mem3.o .libs/mem5.o
.libs/memjournal.o .libs/mutex.o .libs/mutex_noop.o .libs/mutex_os2.o
.libs/mutex_unix.o .libs/mutex_w32.o .libs/notify.o .libs/opcodes.o
.libs/os.o .libs/os_os2.o .libs/os_unix.o .libs/os_win.o .libs/pager.o
.libs/parse.o .libs/pcache.o .libs/pcache1.o .libs/pragma.o .libs/prepare.o
.libs/printf.o .libs/random.o .libs/resolve.o .libs/rowset.o .libs/rtree.o
.libs/select.o .libs/status.o .libs/table.o .libs/tokenize.o .libs/trigger.o
.libs/update.o .libs/util.o .libs/vacuum.o .libs/vdbe.o .libs/vdbeapi.o
.libs/vdbeaux.o .libs/vdbeblob.o .libs/vdbemem.o .libs/vdbetrace.o
.libs/wal.o .libs/walker.o .libs/where.o .libs/utf.o .libs/vtab.o
-lpthread  -O2 -mcpu=cortex-a8 -mtune=cortex-a8 -mfloat-abi=softfp
-mfpu=neon -mthumb -flto  -Wl,-soname -Wl,libsqlite3.so.0 -o
.libs/libsqlite3.so.0.8.6
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
arm architecture of input file `.libs/alter.o' is incompatible with
i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
arm architecture of input file `.libs/analyze.o' is incompatible with
i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
arm architecture of input file `.libs/attach.o' is incompatible with
i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
arm architecture of input file `.libs/auth.o' is incompatible with
i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
arm architecture of input file `.libs/backup.o' is incompatible with
i386:x86-64 output
...............................................................

The solution is to configure libtool by setting CC="my compiler". But
it's not good. I'm not good in m4 scripting, but in attached file is
that, what I changed in configure of libtool. In the old version of
libtool(2.2.6) everything is good. I'm using new libtool, because it
supports LTO.

some links about this problem:

http://www.mail-archive.com/[email-masked]/msg11262.html

http://metastatic.org/text/libtool.html

 --
*С уважением,
**Бучацкий Р.А.* <[email-masked]>
diff --git a/configure b/configure
index de88875..52660c6 100755
--- a/configure
+++ b/configure
@@ -29659,7 +29659,10 @@ old_postuninstall_cmds=$lt_old_postuninstall_cmds
 lock_old_archive_extraction=$lock_old_archive_extraction

 # A C compiler.
-LTCC=$lt_CC
+if [ "x\$CC" == "x" ]; then
+       LTCC=$lt_CC
+else LTCC="\$CC"
+fi

 # LTCC compiler flags.
 LTCFLAGS=$lt_CFLAGS
@@ -29800,7 +29803,10 @@ reload_cmds=$lt_reload_cmds
 old_archive_cmds=$lt_old_archive_cmds

 # A language specific compiler.
-CC=$lt_compiler
+if [ "x\$CC" == "x" ]; then
+       CC=$lt_compiler
+else CC="\$CC"
+fi

 # Is the compiler the GNU compiler?
 with_gcc=$GCC