Undefined symbols dlopen() and friends when cross-compiling for Linux

[Marcel Weiher]

Hi folks,

I am currently getting linker errors when cross-compliing a simple "hello world" example for Linux using Cocotron

marcel@nomad[tests]/Developer/Cocotron/1.0/Linux/i386/gcc-4.3.1/bin/i386-ubuntu-linux-gcc -arch i386  -F/Developer/Cocotron/1.0/Linux/i386/Frameworks  -framework Foundation hello.m 

/Developer/Cocotron/1.0/Linux/i386/Frameworks/Foundation.framework//libFoundation.so: undefined reference to `__dlclose'

/Developer/Cocotron/1.0/Linux/i386/Frameworks/Foundation.framework//libFoundation.so: undefined reference to `__dladdr'

/Developer/Cocotron/1.0/Linux/i386/Frameworks/Foundation.framework//libFoundation.so: undefined reference to `__dlsym'

/Developer/Cocotron/1.0/Linux/i386/Frameworks/Foundation.framework//libFoundation.so: undefined reference to `__dlerror'

/Developer/Cocotron/1.0/Linux/i386/Frameworks/Foundation.framework//libFoundation.so: undefined reference to `__dlopen'

collect2: ld returned 1 exit status

-----

#import <Foundation/Foundation.h>

int main(int argc, char *argv[] ) {

id pool=[NSAutoreleasePool new];

NSLog(@"Hello world!");

exit(0);

[pool release];

return 0;

}

-----

A plain C program works fine:

marcel@nomad[tests]/Developer/Cocotron/1.0/Linux/i386/gcc-4.3.1/bin/i386-ubuntu-linux-gcc -arch i386  hello.c 

marcel@nomad[tests]./a.out 

-bash: ./a.out: cannot execute binary file

marcel@nomad[tests]file ./a.out 

./a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

The symbols it is complaining about are obviously from the dlopen() family of calls, which are used in the Foundation framework.   The same setup used to actually work.    A small test program confirms:

------

#include <stdio.h>

int main(int argc, char *argv[] ) {

printf("Hello world!\n");

dlopen("hi",1);

return 0;

}

------

marcel@nomad[tests]/Developer/Cocotron/1.0/Linux/i386/gcc-4.3.1/bin/i386-ubuntu-linux-gcc -arch i386  dluser.c 

/var/folders/fg/t05zh4jj6d9dw4r68850vx1h0000gn/T//ccdzvVWg.o: In function `main':

dluser.c:(.text+0x2c): undefined reference to `dlopen'

collect2: ld returned 1 exit status

OK, need to add the library:

marcel@nomad[tests]/Developer/Cocotron/1.0/Linux/i386/gcc-4.3.1/bin/i386-ubuntu-linux-gcc -arch i386  dluser.c -ldl

/var/folders/fg/t05zh4jj6d9dw4r68850vx1h0000gn/T//cc6jo85Z.o: In function `main':

dluser.c:(.text+0x2c): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

/Developer_3/Cocotron/1.0/Linux/i386/gcc-4.3.1/bin/../lib/gcc/i386-ubuntu-linux/4.3.1/../../../../i386-ubuntu-linux/lib/libdl.a(dlopen.o): In function `dlopen':

(.text+0x1b): undefined reference to `__dlopen'

collect2: ld returned 1 exit status

Note the double underscore in the function call.   This comes from the "libdl.a" static library:

marcel@nomad[lib]/Developer/Cocotron/1.0/Linux/i386/gcc-4.3.1/bin/i386-ubuntu-linux-nm libdl.

libdl.a   libdl.so  

marcel@nomad[lib]/Developer/Cocotron/1.0/Linux/i386/gcc-4.3.1/bin/i386-ubuntu-linux-nm libdl.a 

dlopen.o:

         U __dlopen

00000000 n __evoke_link_warning_dlopen

00000000 T dlopen

dlclose.o:

         U __dlclose

00000000 T dlclose

dlsym.o:

         U __dlsym

00000000 T dlsym

dlvsym.o:

         U __dlvsym

00000000 W dlvsym

dlerror.o:

         U __dlerror

00000000 T dlerror

dladdr.o:

         U __dladdr

00000000 T dladdr

dladdr1.o:

         U __dladdr1

00000000 T dladdr1

dlinfo.o:

         U __dlinfo

00000000 T dlinfo

dlmopen.o:

         U __dlmopen

00000000 n __evoke_link_warning_dlmopen

00000000 T dlmopen

As far as I could tell, the double underscore variants are defined in libc, but that doesn't seem to help, they aren't picked up.  

As I am not a Linux expert, I am a bit at a loss.   I've got some broad/undefined ideas as to how I might proceed (including re-installing the Linux Platform Interface), but not knowing how I got into this situation, I am not exactly sure how/why that would actually improve things.

Does this ring any bells for anyone?

Thanks!

Marcel

[andyvn22]

I have the exact same problem. Mine surfaced after rebuilding the CDT for Xcode 4.2 and Ubuntu 11.10 (which had its share of other problems, too). I bet I know even less about Linux, but could it have to do with mismatched library versions and/or 64 vs 32 bit?

[xcoder]

i cross compile linux targets flawless. try my clone glennganz1-
cocotron. i use this clone for darwin/windows/linux and solaris
builds.

Glenn

[andyvn22]

Glenn: I don't think it's a problem with the source; it has to do with the tools and/or the platform interface. I have an old Foundation lib compiled with an old platform interface and an old CDT, and it works fine. I can take that same source and recompile and it breaks.

Marcel: I made some progress by deleting all copies of libdl.a from my Cocotron folder (as in, from the platform interface, yes, but also from where I think the install script copies it at Cocotron/1.0/Linux/i386/gcc-4.3.1/i386-ubuntu-linux/lib/), forcing linking with libdl.so instead. You might want to try that. (I also had to fiddle with my libdl.so symlink, which wasn't working right--in the end I wound up just renaming a copy of libdl-2.13.so to libdl.so.)