ld: cannot find crti.o: No such file or directory

[Iain Buclaw]

Binary package hint: binutils

Recent update in natty (something multiarch-related) and all my local gcc builds can no longer link any executables.

/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find crtn.o: No such file or directory
collect2: ld returned 1 exit status
make: *** [libgcc_s.so] Error 1

The internal linker script needs to add /usr/lib/i386-linux-gnu to the list of search directories.

Regards

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: binutils 2.21.0.20110302-2ubuntu2
ProcVersionSignature: Ubuntu 2.6.38-7.35-generic 2.6.38
Uname: Linux 2.6.38-7-generic i686
Architecture: i386
Date: Sat Mar 19 08:57:16 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20101202)
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: binutils
UpgradeStatus: No upgrade log present (probably fresh install)

[Duncan Sands (baldrick-free)]

Same problem here. For example, it is no longer possible to build gcc from source: once the build gets to the point where
the new gcc needs to build a program linking fails with

/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find crtn.o: No such file or directory
collect2: ld returned 1 exit status

This is after recently updating natty on an x86-64 machine

[Iain Buclaw (iainb)]

*WORKAROUND*

LIBRARY_PATH=/usr/lib/i386-linux-gnu:$LIBRARY_PATH
export LIBRARY_PATH

That in your .bashrc file (or ran from a console) is enough for GCC to find the new location of library/ctor/dtor files.

Regards

[Iain Buclaw (iainb)]

May have to move this over to GCC, as it actually looks to be the role of the compiler to find crti.o, crtn.o, etc. Not the linker...

[Steve Langasek (vorlon)]

How are you building gcc? It sounds like you're trying to build a gcc from upstream sources, not from one of the Ubuntu packages, correct?

The default binutils path does not include the multiarch directories because this change was rejected by binutils upstream and the Debian maintainer when it was first proposed - we were told that this should be put only in the gcc spec files, which is how it's implemented now in natty. If you are bootstrapping a gcc build other than the Ubuntu package, you will have to apply the same Ubuntu patches for multiarch support to your gcc as well if you expect it to be used with the system libc.

[Iain Buclaw (iainb)]

Yes, using upstream sources (I am developing the D frontend language to work with GCC-4.6). I take it that there are no multiarch patches available yet for 4.6? Debian experimental maybe?

[Duncan Sands (baldrick-free)]

I am building GCC from upstream (I do some work on GCC). Are you planning to push a patch upstream?
Another annoyance is that I have several custom versions of GCC I obtained from a commercial company.
These all broke too, and I can't rebuild them myself. However Iain's LD_LIBRARY_PATH workaround is
effective, so it's not the end of the world.

[Steve Langasek (vorlon)]

On Wed, Mar 23, 2011 at 02:12:21PM -0000, Duncan Sands wrote:
> I am building GCC from upstream (I do some work on GCC). Are you planning
> to push a patch upstream? Another annoyance is that I have several custom
> versions of GCC I obtained from a commercial company. These all broke
> too, and I can't rebuild them myself.

Of course, since GCC is licensed under the GPL, commercial companies have a
legal obligation to provide you with full copies of the source, including
"the scripts used to control compilation and installation of the
executable".

But yes, this bug report makes it apparent that the experience is far from
ideal when building compilers other than those included in the Ubuntu
archive. We're discussing how best to address this in binutils.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Paul Gevers (paul-climbing)]

I believe that packages built (even in launchpad) with the free pascal compiler (fpc) also fail on this issue. See for instance my ppa builds of winff [1]:

Linking winff
/usr/bin/ld: warning: link.res contains output sections; did you forget -T?
/usr/bin/ld: cannot find -lX11
/usr/bin/ld: cannot find -lgobject-2.0
/usr/bin/ld: cannot find -lglib-2.0
/usr/bin/ld: cannot find -lgthread-2.0
/usr/bin/ld: cannot find -lgmodule-2.0
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -latk-1.0
/usr/bin/ld: cannot find -ldl
/usr/bin/ld: cannot find -lc
winff.lpr(48,1) Error: Error while linking

This "did you forget -T" warning is explained at [2].

Other than introducing the workaround (export LIBRARY_PATH) to my package rules file, is there anything else I could do in a sane way to my package to prevent this from happening? I say from the perspective of building completely different packages, this should "just work". I fear that if we now rebuild winff (and possibly other packages built by fpc) included in Ubuntu it will FTBFS.

[1] http://launchpadlibrarian.net/67113259/buildlog_ubuntu-natty-amd64.winff_1.3.2-2~ppa1n_FAILEDTOBUILD.txt.gz
[2] http://www.freepascal.org/faq.var#unix-ld219

[Launchpad Janitor (janitor)]

This bug was fixed in the package binutils - 2.21.0.20110322-1ubuntu2

---------------
binutils (2.21.0.20110322-1ubuntu2) natty; urgency=low

  * Add multiarch directories to linker search path. Closes: #369064.
    LP: #738098.
 -- Matthias Klose <email address hidden> Sat, 26 Mar 2011 11:27:54 +0100

[Piotr Krukowiecki (piotr-krukowiecki-news)]

On Ubuntu 11.10 I'm getting the same error when building gcc 4.7.0:

/usr/local/src/gcc/gcc-4.7.0-objdir/./gcc/xgcc -B/usr/local/src/gcc/gcc-4.7.0-objdir/./gcc/ -B/usr/local/compilers/gcc-4.7.0/x86_64-unknown-linux-gnu/bin/ -B/usr/local/compilers/gcc-4.7.0/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/compilers/gcc-4.7.0/x86_64-unknown-linux-gnu/include -isystem /usr/local/compilers/gcc-4.7.0/x86_64-unknown-linux-gnu/sys-include -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o _multc3_s.o _powitf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
/usr/bin/ld: cannot find crti.o: No such file or directory
collect2: error: ld returned 1 exit status
make[3]: *** [libgcc_s.so] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory `/usr/local/src/gcc/gcc-4.7.0-objdir/x86_64-unknown-linux-gnu/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/usr/local/src/gcc/gcc-4.7.0-objdir'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/usr/local/src/gcc/gcc-4.7.0-objdir'
make: *** [all] Error 2

I think this problem is also mentioned here:

http://gcc.gnu.org/ml/gcc/2012-02/msg00210.html

The "export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu" workaround works in my case.

I wonder if this is the same problem?