Summary: | dev-db/sqlite-3.7.17 - ld: /usr/bin: file not recognized: Is a directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Fox <gentoo> |
Component: | [OLD] Library | Assignee: | Arfrever Frehtes Taifersar Arahesis <arfrever.fta> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
sqlite build.log using internally generated libtool (fails to build)
sqlite build.log using system libtool (works) emerge --info on the failing machine sqlite internally generated libtool sqlite environment using internally generated libtool (fails to build) |
Description
Peter Fox
2013-09-07 17:16:19 UTC
Created attachment 358190 [details]
sqlite build.log using internally generated libtool (fails to build)
Created attachment 358192 [details]
sqlite build.log using system libtool (works)
Created attachment 358194 [details]
emerge --info on the failing machine
Created attachment 358196 [details]
sqlite internally generated libtool
The previous version of sqlite (sqlite-3.7.16,2) did the same. My other core2 machine is running x86 and is ok. I have an AMD machine running 64 bit and it is also ok. I have only seen the problem with intel 64 bit, which is based on stage3-amd64-20130822.tar.bz2, if that's relevant. Attach /var/tmp/portage/dev-db/sqlite-3.7.17/temp/environment ...could this be the standard SysRescueCD failure ? You know, a dupe of bug 271942. Created attachment 358224 [details]
sqlite environment using internally generated libtool (fails to build)
Emerging gnome, I find dev-cpp/glibmm-2.32.1 fails in a very similar way:
libtool: link: x86_64-pc-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/crtbeginS.o .libs/action.o .libs/actiongroup.o .libs/actionmap.o .libs/applaunchcontext.o .libs/appinfo.o .libs/application.o .libs/applicationcommandline.o .libs/asyncinitable.o .libs/asyncresult.o .libs/bufferedinputstream.o .libs/bufferedoutputstream.o .libs/cancellable.o .libs/credentials.o .libs/datainputstream.o .libs/dataoutputstream.o .libs/dbusactiongroup.o .libs/dbusaddress.o .libs/dbusauthobserver.o .libs/dbusconnection.o .libs/dbuserror.o .libs/dbuserrorutils.o .libs/dbusinterface.o .libs/dbusinterfacevtable.o .libs/dbusintrospection.o .libs/dbusmenumodel.o .libs/dbusmessage.o .libs/dbusmethodinvocation.o .libs/dbusobject.o .libs/dbusownname.o .libs/dbusproxy.o .libs/dbusserver.o .libs/dbussubtreevtable.o .libs/dbusutils.o .libs/dbuswatchname.o .libs/drive.o .libs/emblem.o .libs/emblemedicon.o .libs/enums.o .libs/error.o .libs/file.o .libs/fileattributeinfo.o .libs/fileattributeinfolist.o .libs/fileenumerator.o .libs/fileicon.o .libs/fileinfo.o .libs/fileinputstream.o .libs/fileiostream.o .libs/filemonitor.o .libs/filenamecompleter.o .libs/fileoutputstream.o .libs/filterinputstream.o .libs/filteroutputstream.o .libs/icon.o .libs/inetaddress.o .libs/inetsocketaddress.o .libs/initable.o .libs/inputstream.o .libs/iostream.o .libs/loadableicon.o .libs/memoryinputstream.o .libs/memoryoutputstream.o .libs/menuattributeiter.o .libs/menulinkiter.o .libs/menu.o .libs/menuitem.o .libs/menumodel.o .libs/mount.o .libs/mountoperation.o .libs/networkaddress.o .libs/networkservice.o .libs/outputstream.o .libs/proxy.o .libs/proxyaddress.o .libs/proxyresolver.o .libs/remoteactiongroup.o .libs/resolver.o .libs/seekable.o .libs/settings.o .libs/simpleaction.o .libs/simpleactiongroup.o .libs/socket.o .libs/socketaddress.o .libs/socketaddressenumerator.o .libs/socketclient.o .libs/socketconnectable.o .libs/socketconnection.o .libs/socketcontrolmessage.o .libs/socketlistener.o .libs/socketservice.o .libs/srvtarget.o .libs/tcpconnection.o .libs/threadedsocketservice.o .libs/themedicon.o .libs/volume.o .libs/volumemonitor.o .libs/desktopappinfo.o .libs/unixconnection.o .libs/unixcredentialsmessage.o .libs/unixfdlist.o .libs/unixfdmessage.o .libs/unixinputstream.o .libs/unixoutputstream.o .libs/unixsocketaddress.o .libs/wrap_init.o .libs/contenttype.o .libs/init.o .libs/slot_async.o -Wl,-rpath -Wl,/var/tmp/portage/dev-cpp/glibmm-2.32.1/work/glibmm-2.32.1/glib/glibmm/.libs -Wl,--as-needed -lgio-2.0 ../../glib/glibmm/.libs/libglibmm-2.4.so /usr/bin /usr/sbin /bin /sbin -lsigc-2.0 -lgobject-2.0 -lgmodule-2.0 -lrt -lglib-2.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/crtn.o -march=nocona -Wl,-O1 -Wl,--export-dynamic -pthread -pthread -Wl,-soname -Wl,libgiomm-2.4.so.1 -o .libs/libgiomm-2.4.so.1.3.0
/usr/bin: file not recognized: Is a directory
collect2: ld returned 1 exit status
make[2]: *** [libgiomm-2.4.la] Error 1
make[2]: Leaving directory `/var/tmp/portage/dev-cpp/glibmm-2.32.1/work/glibmm-2.32.1/gio/giomm'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/dev-cpp/glibmm-2.32.1/work/glibmm-2.32.1'
make: *** [all] Error 2
* ERROR: dev-cpp/glibmm-2.32.1 failed (compile phase):
* emake failed
Do you want to look at this as well?
As part of this bug, or another?
It's interesting that you mention sysrescuecd: I'm building from systemrescuecd-x86-3.4.1.iso running on a usb key. The other thing I noticed was that the package generated libtool would succeed if I remover the -rpath component of the command line, ie: ./libtool --mode=link x86_64-pc-linux-gnu-gcc -DSQLITE_SOUNDEX -march=nocona -O2 -pipe -DSQLITE_OS_UNIX=1 -I. -I./src -I./ext/rtree -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -I/usr/include -DSQLITE_THREADSAFE=1 -DSQLITE_ENABLE_COLUMN_METADATA -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS3_PARENTHESIS -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS4_UNICODE61 -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_UNLOCK_NOTIFY -DSQLITE_ENABLE_ICU -Wl,-O1 -Wl,--as-needed -o libtclsqlite3.la tclsqlite.lo \ libsqlite3.la -ltclstub8.5 -ldl -lpthread -licui18n -licuuc \ -version-info "8:6:8" \ -avoid-version instead of: ./libtool --mode=link x86_64-pc-linux-gnu-gcc -DSQLITE_SOUNDEX -march=nocona -O2 -pipe -DSQLITE_OS_UNIX=1 -I. -I./src -I./ext/rtree -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -I/usr/include -DSQLITE_THREADSAFE=1 -DSQLITE_ENABLE_COLUMN_METADATA -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS3_PARENTHESIS -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS4_UNICODE61 -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_UNLOCK_NOTIFY -DSQLITE_ENABLE_ICU -Wl,-O1 -Wl,--as-needed -o libtclsqlite3.la tclsqlite.lo \ libsqlite3.la -ltclstub8.5 -ldl -lpthread -licui18n -licuuc \ -rpath "/usr/lib64/sqlite-3.7.17" \ -version-info "8:6:8" \ -avoid-version It is a dupe of bug 271942. If I chroot using the following commands it works: chroot /mnt/gentoo /usr/bin/env -i /bin/bash env-update . /etc/profile emerge sqlite Perhaps the quick install guide 'Listing 2.14 chroot' and install guide ch6 'Listing 1.5 Chrooting into the new environment' could be updated to mention this when installing from a system rescue disk (and perhaps other non-gentoo boot images), as using a system rescue cd is widely suggested as a good route to installing gentoo? *** This bug has been marked as a duplicate of bug 271942 *** |