Linking to shared libs (MinGW)

[Epy]

Time for me to look really stupid.

I've compiled a library and can't link to it for some reason, I know I must just be missing some small option. The library is libmodbus, and the compilation produces libmodbus-5.dll, headers, libmodbus.dll.a, and libmodbus.la.

I've been trying to compile a simple test like so:

gcc -Wall -I"C:\MinGW\msys\1.0\local\include\modbus" -L"C:\MinGW\msys\1.0\local\lib" -lmodbus test.c

Like the pkgconfig file shows, but this does not work. The only way I can get it to compile is to link to libmodbus.dll.a directly, which I know is not the proper way to do it:

gcc -Wall -I"C:\MinGW\msys\1.0\local\include\modbus" test.c "C:\MinGW\msys\1.0\local\lib\libmodbus.dll.a"

Most of the time I'm compiling my own code or there's a configure script and Makefile and stuff to do everything for me, so this is new to me. And I feel retarded.

I'd appreciate it if someone could point out to me what small thing I'm missing. Thanks.

[stahta01]

Copy/Rename the file "libmodbus.dll.a" to "libmodbus.a".

The other option is to create the .a file without the ".dll" in the file name.

Tim S.

[Epy]

Didn't work.

[phantomotap]

The only way I can get it to compile is to link to libmodbus.dll.a directly, which I know is not the proper way to do it:

Actually, because "GCC" is so beastly, that is a perfectly acceptable way to link shared libraries.

Didn't work.

O_o

That isn't useful; you know that; you should know better than to respond that way.

How doesn't it work? Is it not linking at all? Is it linking the shared library but failing to grab the DLL on execution? What?

Soma

[Codeplug]

Link Options - Using the GNU Compiler Collection (GCC)

So without renaming anything, "-lmodbus.dll" should translate to "libmodbus.dll.a", according to the manual.

gg

[stahta01]

Link Options - Using the GNU Compiler Collection (GCC)

So without renaming anything, "-lmodbus.dll" should translate to "libmodbus.dll.a", according to the manual.

gg

Edit: Oops, I just realized I missed the .dll in the linker option.

Not my experience.

"-lmodbus" translates to "libmodbus.a" in my experience.


Tim S.

[Codeplug]

HOWTO Create and Deploy a Sample DLL using MinGW | MinGW

Using that example code, I did the following:

>g++ --version
g++ (tdm-1) 4.6.1

>g++ -DBUILDING_EXAMPLE_DLL -shared example_dll.cpp -o e.dll -Wl,--out-implib,libexample.dll.a
Creating library file: libexample.dll.a

>g++ example_exe.cpp -o example.exe -L. -lexample.dll -Wl,--verbose | find /i "example"
attempt to open ./libexample.dll.dll.a failed
attempt to open ./example.dll.dll.a failed
attempt to open ./libexample.dll.a succeeded

So MinGW tries a couple of permutations before falling back on the documented behavior

gg

[Epy]

Sorry for the brief reply before, I do know better. It's not linking. When it does compile, it gave me the can't find dll error, but that was before I added the bin folder to PATH.

C:\Users\Jake\Downloads>gcc -Wall -I"C:\MinGW\msys\1.0\local\include\modbus" -L"
C:\MinGW\msys\1.0\local\lib" -lmodbus test.c
C:\Users\Jake\AppData\Local\Temp\ccYy7B0X.o:test.c.text+0x1e): undefined refer
ence to `_modbus_new_tcp'
C:\Users\Jake\AppData\Local\Temp\ccYy7B0X.o:test.c.text+0x2e): undefined refer
ence to `_modbus_connect'
C:\Users\Jake\AppData\Local\Temp\ccYy7B0X.o:test.c.text+0x52): undefined refer
ence to `_modbus_read_registers'
C:\Users\Jake\AppData\Local\Temp\ccYy7B0X.o:test.c.text+0x5e): undefined refer
ence to `_modbus_close'
C:\Users\Jake\AppData\Local\Temp\ccYy7B0X.o:test.c.text+0x6a): undefined refer
ence to `_modbus_free'
collect2.exe: error: ld returned 1 exit status

C:\Users\Jake\Downloads>gcc -Wall -I"C:\MinGW\msys\1.0\local\include\modbus" -L"
C:\MinGW\msys\1.0\local\lib" -lmodbus.dll test.c
C:\Users\Jake\AppData\Local\Temp\cc41wXKQ.o:test.c.text+0x1e): undefined refer
ence to `_modbus_new_tcp'
C:\Users\Jake\AppData\Local\Temp\cc41wXKQ.o:test.c.text+0x2e): undefined refer
ence to `_modbus_connect'
C:\Users\Jake\AppData\Local\Temp\cc41wXKQ.o:test.c.text+0x52): undefined refer
ence to `_modbus_read_registers'
C:\Users\Jake\AppData\Local\Temp\cc41wXKQ.o:test.c.text+0x5e): undefined refer
ence to `_modbus_close'
C:\Users\Jake\AppData\Local\Temp\cc41wXKQ.o:test.c.text+0x6a): undefined refer
ence to `_modbus_free'
collect2.exe: error: ld returned 1 exit status

C:\Users\Jake\Downloads>gcc -Wall -I"C:\MinGW\msys\1.0\local\include\modbus" -L"
C:\MinGW\msys\1.0\local\lib" test.c "C:\MinGW\msys\1.0\local\lib\libmodbus.dll.a
"

C:\Users\Jake\Downloads>cd C:\MinGW\msys\1.0\local\lib

C:\MinGW\msys\1.0\local\lib>ls
libmodbus.a libmodbus.dll.a libmodbus.la pkgconfig

C:\MinGW\msys\1.0\local\lib>

[phantomotap]

O_o

This is exactly why I needed more context; now I don't need to guess.

The "GCC" suite linker does not apply linked items recursively.

In other words, order matters in linking dependance.

Ignore the names, look at the order you've linked items when it works.

Soma

[anduril462]

Can you post your test.c?

What's with the leading underscores in the compiler error messages? I'm looking at the source code for libmodbus, and I don't see any _modbus_free. Just a modbus_free​.

EDIT: Duh, you can probably ignore this. phantomotap is very probably correct.

[Epy]

Yeah, if I move the -lmodbus.dll behind test.c it compiles. What a piece of ......... I thought common sense dictated that all flags should be before the usual arguments, i.e. files.

test.c is just the test case copied from the website:

#include <stdio.h>
#include <modbus.h>

int main(void)
{
  modbus_t *mb;
  uint16_t tab_reg[32];

  mb = modbus_new_tcp("127.0.0.1", 1502);
  modbus_connect(mb);

  /* Read 5 registers from the address 0 */
  modbus_read_registers(mb, 0, 5, tab_reg);

  modbus_close(mb);
  modbus_free(mb);
	return 0;
}

Anyway, thanks for the help.

[ZuK]

Yeah, if I move the -lmodbus.dll behind test.c it compiles. What a piece of ......... I thought common sense dictated that all flags should be before the usual arguments, i.e. files.

You have to look at this in a different way,
First come the filenames and options that are used by the compiler. The output of the compiler is then fed to the linker with the rest of the arguments like library paths and additional libraries.
Kurt

[phantomotap]

What a piece of ......... I thought common sense dictated that all flags should be before the usual arguments, i.e. files.

O_o

The notion of "common sense" has nothing to do with it.

This has been the default behavior of the "GCC" suite forever.

This is just about being familiar with your tools.

Soma