6

Running Debian/Linux x86_64 with GNU ld 2.21.

Quite simply, if I link with

ld -o main main.o /usr/lib/crti.o /usr/lib/crt1.o /usr/lib/crtn.o -lc -lm

It works, but when I link with

ld -r -o main1.o main.o /usr/lib/crti.o /usr/lib/crt1.o /usr/lib/crtn.o -lc -lm

It complains

ld: cannot find -lc
ld: cannot find -lm

I'm not actually trying to compile code this way, but rather I'm trying to figure out why someone else's test to see if a library exists is not working. (Thus I don't really understand what's going on with ld... usually I just use GCC to link)

Why would telling ld to link in a relocatable fashion make it suddenly unable to find libraries? If I just want to test that -lm exists, what should I do besides

ld -r -lm

so that it will find the library?

If you want to see the source that I'm dealing with, you can download it here: https://github.com/jeremysalwen/ESPS (note, that the first commit is the original source code, and the subsequent ones are changes I have personally made.)

Jeremy Salwen
  • 8,061
  • 5
  • 50
  • 73
  • @Jeremy: Maybe it's an old version of `ld`, which doesn't support it? Also, just try `--relocatable` instead and see what it says. – user541686 Jul 07 '11 at 00:30
  • I'm running debian/linux x86_64, with "GNU ld (GNU Binutils for Debian) 2.21.51.20110523" which is the most up-to-date version. – Jeremy Salwen Jul 07 '11 at 00:45
  • @Mehrdad: No difference if I use --relocatable or -r. The man pages support the notion that -r and --relocatable are supported and synonymous. – Jeremy Salwen Jul 07 '11 at 00:47
  • @Mehrdad: just an FYI; the `-r` option was available in Version 7 UNIX back in the late 70's. It is likely one of the less used options, but it has, in general, been around since the dawn of (UNIX) time. – Jonathan Leffler Jul 07 '11 at 01:10
  • Thanks for adding the platform information. As a matter of curiosity, on which platform does the "someone else's test" work? Presumably not Debian/Linux x86_64, but which ... – Jonathan Leffler Jul 07 '11 at 01:12
  • 1
    @Jonathan Supposedly "Apple Mac-OS-X [versions?] and the Fedora Core 3-6, Ubuntu 8.04 and Scientific Linux 5 (clone of Centos 5, clone of RHEL 5) Linux distributions." It's hard to tell if anyone but the developers have gotten this particular package working on any system. I can tell you that at least one other person is having problems compiling it with some sort of Debian system, but I can't find information about anyone else. The package is Entropic Signal Processing System which was recently released as open source and doesn't seem to have a lot of web activity surrounding it. – Jeremy Salwen Jul 07 '11 at 02:54
  • My Google-fu is failing; I can't see the open source location on the web (under ESPS or the full name). Ah well. It might be good to put the information into the question, along with the URL for the code. Then we can clean up the comments and avoid 'Please avoid extended discussions in comments' nag lines. – Jonathan Leffler Jul 07 '11 at 03:00
  • @Jonathan, Don't worry, the reason your google foo is failing you is because it is obscure. The only reason I know about it is because of a mailing list. I've updated the post with a link. If you want the original tarball, see http://ldc.upenn.edu/myl/esps60.6.linmac.src.tgz – Jeremy Salwen Jul 07 '11 at 09:10

2 Answers2

4

MacOS X

On MacOS X, the man page for ld is quite explicit about the -r option:

-r Merges object files to produce another mach-o object file with file type MH_OBJECT.

So, if you are on MacOS X, the trouble is that -lm is not a Mach-O object file, and neither is -lc. However, in theory, if you have object files main.o, obj1.o and obj2.o and you do:

cp obj1.o ./-lm
cp obj2.o ./-lc
ld -r -o main1.o main.o -lm -lc

then it might work. In practice, it doesn't, and amongst the errors you get:

ld: warning: unexpected dylib (/usr/lib/libm.dylib) on link line
ld: warning: unexpected dylib (/usr/lib/libc.dylib) on link line

However, running:

ld -r -o main1.o -arch x86_64 main.o obj1.o obj2.o

worked without any whingeing from the loader.

Linux

On Linux the man page for ld is less explicit, but says:

-i Perform an incremental link (same as option -r).

-r
--relocatable

Generate relocatable output---i.e., generate an output file that can in turn serve as input to ld. This is often called partial linking. As a side effect, in environments that support standard Unix magic numbers, this option also sets the output file’s magic number to "OMAGIC". If this option is not specified, an absolute file is produced. When linking C++ programs, this option will not resolve references to constructors; to do that, use -Ur.

When an input file does not have the same format as the output file, partial linking is only supported if that input file does not contain any relocations. Different output formats can have further restrictions; for example some "a.out"-based formats do not support partial linking with input files in other formats at all.

This option does the same thing as -i.

Reading between the lines, this also takes object files and converts them to object files; it does not add libraries into the mix. If you think about it, object files are not created containing references to libraries.

So, although there might be platforms where it is possible to specify libraries to the linker (loader) when using the -r option, there are others where it is not.

Workarounds

The original problem is to establish whether the libraries are present. Why not mimic what autoconf does, and create a main.c that would, for preference, contain a reference to a symbol defined in the library, but which could simply contain:

int main(void){return 0;}

and compile and link it with the C compiler:

cc -o main main.c -lm -lc

If it doesn't work, then one of the libraries is missing. If you've already checked that -lc is present, then you can infer that -lm is missing.

Community
  • 1
  • 1
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
0

What is echo $LD_PRELOAD showing you?

Perhaps the error message is saying ld is unable to find the .so of the linked libraries. You could help by setting LD_PRELOAD to point to those .so files.

vpit3833
  • 7,817
  • 2
  • 25
  • 25
  • I have no LD_PRELOAD. As you can see in the question, it manages to link with the first options given, so I don't think the problem is LD_PRELOAD. – Jeremy Salwen Jul 07 '11 at 03:07