Linker error I've never seen before

[Frederick Gotham]

About ten years ago I thought that I'd seen every kind of compiler and linker error. I know that when templates go wrong you can get a sea of information, but I've at least understood each individual line.

Today I'm stumped. It's a linker error that has me stumped.

Let's say I have already compiled a dynamic shared library, and my library is called 'Monkey'. So on MS-Windows, I have "libMonkey.dll", and on Linux and Mac, I have "libMonkey.so".

So then I write a program that makes use of my Monkey library, and I compile it like so:

g++ -o new_program new_program.cpp -lMonkey

This compilation of "new_program" is failing, and the linker is saying that there are undefined references in the Monkey library. I've never seen this before. My Monkey library has already been successfully compiled. I can't see how "new_program" would fail to link. I've never known a linker to complain that a dynamic shared library, which has already been compiled, contains undefined references. I'm only trying to link with a library that's already been compiled.

I'm working on ARM 32-Bit embedded Linux, and so I build in two steps like this:

arm-linux-gnueabihf-g++ -std=c++11 -o frederick.o -c frederick.cpp

arm-linux-gnueabihf-g++ -std=c++11 -o frederick frederick.o -lMonkey

The first command succeeds and creates the object file.

The second command fails with this output:

libMonkey.so: undefined reference to `log_debug'
libMonkey.so: undefined reference to `log_error'
libMonkey.so: undefined reference to `log_trace'
libMonkey.so: undefined reference to `log_info'
collect2: error: ld returned 1 exit status

I've never seen a linker do this before.

Any got a clue what's going on?

[Öö Tiib]

That is huge topic impossible to answer by so vague problem description.
May be skim over answers in that stack overflow question:
<https://stackoverflow.com/questions/12573816/what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix>
And then come back and explain why none applies on your case.

question

[Paavo Helde]

09.04.2020 15:48 Frederick Gotham kirjutas:
> I've never known a linker to complain that a dynamic shared library, which has already been compiled, contains undefined references. I'm only trying to link with a library that's already been compiled.

This depends on the linker default behavior. With gcc you need to pass
the following to the g++ shared library link command: -Wl,-no-undefined

[Paavo Helde]

To clarify - this does not magically resolve undefined references, it
just reports them earlier, at the first shared library linking stage.

I believe the default behavior is there to allow cyclic dependencies
between .so-s, but I think it's better for everybody to avoid such things.

[Frederick Gotham]

On Thursday, April 9, 2020 at 2:09:27 PM UTC+1, Paavo Helde wrote:

> This depends on the linker default behavior. With gcc you need to pass
> the following to the g++ shared library link command: -Wl,-no-undefined

That particular compiler option didn't work but you pointed me in the right direction.

This one worked:

-Wl,--allow-shlib-undefined

[Frederick Gotham]

I think the Monkey library wants the main executable file to define those logging functions, almost like they were registered callback functions.

Here's what I did in "new_program" to get everything to compile just fine:

On Thursday, April 9, 2020 at 2:25:08 PM UTC+1, Richard Damon wrote:

> Read the documentation for libMonkey, they likely define these functions
> as call backs to the application to allow you to adjust its logging
> behavior. You need not just the signatures, but what they are supposed
> to do. It may be that a basically nil stub would work, but it also might
> not.

I figured it out. Here's what I did in my C++ program:

extern "C" {

int log_error(const char* func, const char *format, ...)
{
return 0;
}

int log_info(const char* func, const char *format, ...)
{
return 0;
}

int log_debug(const char* func, const char *format, ...)
{
return 0;
}

int log_trace(const char* func, const char *format, ...)
{
return 0;
}
}

int main(void)
{

}


Now it compiles just fine without having to pass any special options to the linker.

[Keith Thompson]

Frederick Gotham <cauldwel...@gmail.com> writes:
> About ten years ago I thought that I'd seen every kind of compiler and
> linker error. I know that when templates go wrong you can get a sea of
> information, but I've at least understood each individual line.
>
> Today I'm stumped. It's a linker error that has me stumped.
>
> Let's say I have already compiled a dynamic shared library, and my
> library is called 'Monkey'. So on MS-Windows, I have "libMonkey.dll",
> and on Linux and Mac, I have "libMonkey.so".
>
> So then I write a program that makes use of my Monkey library, and I compile it like so:
>
> g++ -o new_program new_program.cpp -lMonkey
>
> This compilation of "new_program" is failing, and the linker is saying
> that there are undefined references in the Monkey library.

You posted the same question in comp.lang.c, but with "gcc" rather
than "g++".

I would suggest posting only in the newsgroup for whichever language
you're actually using.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Sam]

Frederick Gotham writes:

> The second command fails with this output:
>
> libMonkey.so: undefined reference to `log_debug'
> libMonkey.so: undefined reference to `log_error'
> libMonkey.so: undefined reference to `log_trace'
> libMonkey.so: undefined reference to `log_info'
> collect2: error: ld returned 1 exit status
>
> I've never seen a linker do this before.

This happens to be the most common linking failure error.

> Any got a clue what's going on?

Code in libMonkey.so is referencing those symbols, which are nowhere to be
found. You have to figure out where they are defined, and then figure out
why it's not getting linked correctly.

That's pretty much it. There aren't really that many different ways of
explaining what "undefined reference" means. It always means one thing:
undefined reference.