Hi everybody, I have a HUGE problem, since my project depends of compiling a program which I haven't found the way of doing it. In the directory ./scope-src/ I have a library named 'libscope.a'. Doing the command below, I got to compile my program in my University, but I haven't in my laptop.

g++ LBPROT.cpp -L./scope-src/ -lscope
/usr/bin/ld: cannot find -lscope
collect2: ld returned 1 exit status

The big problem till now is that every change I do in my code, it means I have to upload it, say, via ssh, compile it there and downloading. As you should understand this is really boring and wastes my time. So, do you know how might a solve my problem?


Thaks to all for you great help!!

You are using a path relative to the current directory with the -L switch (the . signifies the current dir). Try using an absolute path, or cd to the parent of the scope-src directory.

Well, I've tried using absolute path and I got the same. Somehow after having started my machine, I get new error when execute the same command line:

g++ LBPROT.cpp -L./scope-src/ -lscope
/tmp/ccKayoVt.o: In function `getimagef(char *, image_data *)':
/tmp/ccKayoVt.o(.text+0x24): undefined reference to `getimage(data *, char *, char *)'
collect2: ld returned 1 exit status


Any other suggestion??

Thanks mate for your help!

specify the library as a file to include in the compile as well. Here's an example that worked for me:

Sorry mate but this still continues without working. Anyway, thank you very much for you help.

If you or any one else wants to try with other solution, it'll be great!!

Do you have any other alternative?

Was the library compiled using the same compiler (and version !) as you use to compile your program ? (This is a C++ problem, when C++ uses conventional link technology it needs hacks like namemangling, which is compiler dependend). Also check for special compiler flags used when compiling the lib.

Another useful check: use tools like nm and objdump to look for exported symbols from the library and symbols imported by your program. Focus on just a few, lik getimage. Note the unmangled symbol names (see man page).

You are right DIYLinux, the library was coded in C and compile using, I suppose, GCC 2.96. I'm doing my program in C++ and using GCC 3.2.2 to compile. However, when I compile in my University, where the GCC 2.96 is, I don't have any problem at all. So, I'm doubting of my compiler version, as it might have problems with previous versions' compiled code. Don't you think? Do you know any parameter that might help me to solve that?

A MILLION OF THANKS MATE!

You are right DIYLinux, the library was coded in C and compile using, I suppose, GCC 2.96. I'm doing my program in C++ and using GCC 3.2.2 to compile. However, when I compile in my University, where the GCC 2.96 is, I don't have any problem at all. So, I'm doubting of my compiler version, as it might have problems with previous versions' compiled code. Don't you think? Do you know any parameter that might help me to solve that?

A MILLION OF THANKS MATE!

There is more:

Interfacing to C should not be a problem from C++, regardless of GCC version, if mind the following:

1. Use the following in the header around the declarations for the C stuff:

#ifdef __cplusplus
extern "C" {
#endif

// declarations


#ifdef __cplusplus
}
#endif

2. Beware of using the option to pass arguments in registers. If you use it, you should use it throughout your ENTIRE system. Not just your source, but also glibc and other libraries.

Well, the results:

I did the point one (about 'extern' ...) and I get the same output. I don't know what you mean with the second point. If you mean that I have to use 'register' keyword in the entire system, I don't use it in my code. I don't know how the library is impleted in detail. So, I don't know if you'll know another possible solution.

Thanks mate!

Disregard point 2. Its an obscure gcc switch which could be renamed -fgive_me_enough_rope_to_hang_myself. Heres what is does:

Normally, if you call a function, the compiler emits code that pushes the arguments on the stack, then pushes its the location of the next instruction on the stack and finally jumps to the code of this function. A slightly faster way would be to load the arguments in some free registers.

This requires different code for both the callee and the caller, so you have to recompile the whole system with this option.

I am a bit puzzled why the first suggestion doesnt work. I know that different versions of gcc mangle (see below for explanation) symbols in different ways, but the C calling convention (the code emitted for function calls and prologues/epilogues) has not changed in many years. This is why C is a system programming language, and C++ not.

Mangling: since the linker (ld on Linux) barfs at multiple definitions of the same symbol, overloading requires function symbols to be altered. For example (not gcc's mangling though):

int foo(int); => foo_int
int foo(double); => foo_double

The extern "C" directive (see some files in /usr/include for examples) tells gcc that the function follows both C calling convention and that the compiler should not mangle the name when emitting import records in the object file. This should be sufficient to prevent your problem.

It might be the problem with gcc-2.96. This is an unofficial version, I believe by Red Hat. The official gcc jumped from 2.95.3 to 3.0.0. Try google for background.

Cheers mates! I really appreciate you help, which although it didn't work for any misterious reason, it has been great!! If you have any other suggestion, don't hesitate to let me know, please!

A deal of thanks!!