Linker error: Undefined symbol: _strlen

[bschrade]

Hello,

i want to migrate a C project to Lazarus and want to keep the tested backend functions, so i created a minimal project to test calling C functions from Pascal. The structure is like this:

Prepare C interface module:

  cstub.c and cstub.h => hpas -cd cstub.h => cstub.pp
  gcc -c -m32 cstub.c => cstub.o

Prepare Pascal interface module pstub.pas and include linker options:
{$link cstub.o}
{$linklib libgcc.a}

Add all of this to the project.

When cstub.c is self contained and does not use any libc functions the project compiles, links and runs as expected.

When cstub.c contains calls to strlen() or strcpy() i get this "undefined symbol" linker error. Strangely enough this error occurs only when compiling on Windows. The same construct compiles, links and runs fine on Linux.

In both cases i used the current versions of Lazarus and gcc available. On Windows i used mingw.

I tried:
- I checked with "strings ...". The symbol _strlen is contained in libgcc.a (which is no surprise) and cstub.o
- When i change the linklib option to a wrong name like "libgccX.a" i get the expected "no such file" linker error.

So it looks to me the linker does load libgcc.a but for some reason cannot match the _strlen contained in cstub.o to the _strlen contained in libgcc.a

Did anyone encounter the same or a similar problem? Any ideas what i did miss?

Best regards, Bruno

[marcov]

Add  "libc"  too? Strictly speaking that is the "C" runtime, while libgcc are the language helper.

Admitted, strlen is on the fence between both.

[Thaddy]

Admitted, strlen is on the fence between both.

It is also confusing, since pascal strings work differently: store length and allow #0 in the middle.
strlen is basically a strscan until the first #0 is encountered. Both slow and incorrect from a pascal programmer point of view.

[trev]

MinGW builds against the Windows C Runtime Library msvcrt using libmsvcrtXX.a, but I haven't looked at Windows and MinGW since Windows XP so things may have changed. Yep, see Microsoft Docs there's a new "Universal CRL".

[bschrade]

Add  "libc"  too? Strictly speaking that is the "C" runtime, while libgcc are the language helper.

MinGW on Windows does not have a libc.a. This is why i checked for presence of the symbol _strlen in libgcc.a

I understand that it should link OK once i find the correct linklib option. I guess the best way to continue will be to add more libc functions and scan the .a files of mingw for them. I will try and come back.

Forgot to mention: On Linux both options: {$linklib c} and {$linklib gcc} link and run fine.

I did not find a way to get a look at the linker command line, can anybody point me into a direction where i can find some way to get a look at it?

Gruß, Bruno

[bschrade]

MinGW builds against the Windows C Runtime Library msvcrt using libmsvcrtXX.a, but I haven't looked at Windows and MinGW since Windows XP so things may have changed. Yep, see Microsoft Docs there's a new "Universal CRL".

Thank you for this hint. This option sequence links and runs fine:

{$link cstub.o}

{$linklib libgcc.a}
{$linklib libucrtbase.a}

Both linklibs located in mingw lib directory.

Gruß, Bruno

[trev]

I'm happy to have helped