0

In Linux when I load shared library using dlopen() from executable (or shared library) I expect that undefined symbols in this library will be automatically resolved, of course as long as executable (or shared library) defines these symbols.

For example, I have library A with these header and source files:

#pragma once
int funcA();

#include "A/header.h"
int funcA() {}

also I have library B with this source file:

#include "A/header.h"
void funcB() {
    funcA();
}

for library B I specify path to header of library A, but I don't link library A to library B.

In this case, if I load library B from library A by calling dlopen(), then undefined symbol funcA in library B will be resolved, so library B will be able to call funcA.

Is it also true for Windows, or I have to manually find addresses for all symbols I need?

Alexey Ochapov
  • 11
  • 2

1 Answers1

0

After researching already answered questions on Stack Overflow:

I realized that if I want to make something similar work on Windows, I have to create some import library for my shared library A.

At first I thought it's needed only for MSVC, but looks like MinGW needs import library too, because it's how things work on Windows. Correct me if I miss something.

For me it's big no-no, so probably I will change a way how I work with shared libraries to explicitly retrieve every symbol I need via additional interface. Fortunately, there are not so many of them.

Alexey Ochapov
  • 11
  • 2