Forum > Beginners

Linker error: Undefined symbol: _strlen

(1/2) > >>


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

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

Admitted, strlen is on the fence between both.


--- Quote from: marcov on April 23, 2021, 09:42:39 pm ---Admitted, strlen is on the fence between both.

--- End quote ---
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.

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".


--- Quote from: marcov on April 23, 2021, 09:42:39 pm ---Add  "libc"  too? Strictly speaking that is the "C" runtime, while libgcc are the language helper.

--- End quote ---

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


[0] Message Index

[#] Next page

Go to full version