10

I'm cross-compiling an application, but linking blows up with an error that it

"cannot find /lib/libc.so.6".

The libc.so.6 that it should be using is the one that sits at /home/work/worldcom/filesys/lib/libc.so.6. What have I got wrong here?

linking libobj.so
arm-none-linux-gnueabi-g++ obj1.o obj2.o obj2.o  -o libobj.so -L/home/work/worldcom/filesys/usr -Wl,-O1 -Wl,-z,defs -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=both -L/home/work/worldcom/filesys -L/home/work/worldcom/filesys/lib -L/home/work/worldcom/filesys/usr/lib -lcurl -shared
/home/lishevita/armv5tel/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/home/lishevita/armv5tel/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find /lib/libc.so.6
collect2: ld returned 1 exit status<br />
make: *** [libobj.so] Error 1<br />

My makefile is handwritten (i.e. not generated by Autotools). In order to avoid a blanket "your Makefile is broken" here are some details from the makefile that might help clarify.

CROSS_COMPILE = arm-none-linux-gnueabi-  
SYSROOT = /home/work/worldcom/filesys/  
DESTDIR = /home/work/worldcom/filesys/  

RELEASE_CXXFLAGS = -Os  
DEBUG_CXXFLAGS = -O0 -gstabs  
PKGCONFIG=`env ROOT=/home/work/worldcom/filesys cross-pkg-config glib-2.0 libcurl --cflags`  

CC = $(CROSS_COMPILE)gcc  
CXX = $(CROSS_COMPILE)g++  
LD = $(CROSS_COMPILE)ld  
AR = $(CROSS_COMPILE)ar  

LDFLAGS = -Wl,-O1 -Wl,-z,defs -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=both -L$(SYSROOT) -L$(SYSROOT)lib -L$(SYSROOT)usr -L$(SYSROOT)usr/lib -lcurl  

libobj.so: $(LIBOBJ_OBJS)  
        @echo linking $@  
        $(CXX) $^ -o $@ $(LDFLAGS) -shared $(PKG_LIBS)

Of course there is also a definition and target for the LIBOBJ_OBJS but those are irrelevant to the problem.

T3 H40
  • 2,326
  • 8
  • 32
  • 43
lishevita
  • 103
  • 1
  • 1
  • 6
  • You should have a look at the output from gcc -dumpspecs - it may have something in there about where it searches for libc. – Aidan Cully Dec 27 '09 at 20:52

4 Answers4

14

You didn't indicate what gcc version you are using, but if it is a recent enough one (4.0.0 and above me thinks) you should try adding the --sysroot flag to g++/ld. Point it to $SYSROOT as defined in your Makefile. For example:

--sysroot=$(SYSROOT)

Assuming recent enough gcc version, it will work.

Seanny123
  • 8,776
  • 13
  • 68
  • 124
gby
  • 14,900
  • 40
  • 57
  • 1
    My Hero!!! :) It's actually --sysroot without "with-", but you pointed me in the right direction and it works. Now I have a new error. New errors are good. It means I got past one problem and have an entirely new challenge to induce high blood pressure! :) Here's the new line in my Makefile: $(CXX) $^ -o $@ $(LDFLAGS) -shared $(PKG_LIBS) --sysroot=$(SYSROOT) – lishevita Dec 27 '09 at 21:13
  • And now today, 10.5 years after this answer was posted, you are my hero too. – BigHeadCreations Jul 14 '20 at 15:13
1

I just went through the same issue; adding --sysroot=/rootfs/prefix helped me get closer to the real issue. I got it fixed by installing package libstdc++-dev in target.

Andro Selva
  • 53,910
  • 52
  • 193
  • 240
Ester
  • 11
  • 1
0

Have you not considered that possibly the LIBPATH is set and hard-coded to look for the /lib/libc.so.6 and therefore the /lib path?

Have you tried to set the environment variable like this on the command line, prior to issuing make when cross-compiling:

LIBPATH=/home/work/worldcom/filesys/lib

In your specific case, as you have mentioned in the tag 'cross-compiling', it might be worth it to remove any references to /lib to wholly force the linker to look in your own home directory instead as not to interfere with the cross-compile process.

The other possibility is that the gcc compiler when it was built for your environment, the configuration during the building of the compiler from source, was specified to point to the /lib path.

Hope this helps, Best regards, Tom.

t0mm13b
  • 34,087
  • 8
  • 78
  • 110
  • Just tried export LIBPATH=/home/work/worldcom/filesys/lib and got no joy. Maybe you are right about the gcc compiler being built to point to the /lib path, although that seems weird. I'll look into that as a possible source of the problem. Thanks, Lisha – lishevita Dec 27 '09 at 02:45
-3

It seems that the makefile is broken, because the libc.so.6 is assumed to be located in the /lib/ folder (note the preceding slash indicating an absolute path! ). This seems to be the issue.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
moritz
  • 2,448
  • 1
  • 20
  • 25
  • Sure, but WHAT in the makefile could be broken? You can see from what I've pasted exactly what is getting linked in, right? And all those -L's point to places that clearly aren't /. Soooo... There's got to be something else I'm missing. I'll add in more information on my question and see if that helps clarify any... – lishevita Dec 27 '09 at 02:28
  • Okay, I guess I wasn't clear enough here.. :-). There is a huge difference between a path name like /foo/bar and foo/bar. The first is always pointed at /foo/bar /, as seen from the root of your file system, the latter one depends on your current working directory. Because the path in the makefile seems to be absolute, i.e. from the root ongoing, your search paths aren't even looked up and searched for the libc.so . hope that helped. – moritz Dec 27 '09 at 15:06
  • It's not the makefile that's broken, the absolute paths are contained in linker scripts. This is not necessarily wrong, since cross-compilation linkers are supposed to search beneath a sysroot prefix... but it does make for very confusing error messages. – Ben Voigt May 08 '13 at 16:48