Gnat arm elf 12.2.1 (alire) undefined reference to strlen

Merry xmas all.

I simplified my Last Chance Handler by using


The compiler output undefined reference to ‘strlen’


I could go back to my manual string null termination finding function. Or should I look into Gnat. Could someone point me to the right place to report and or submit a patch (is it gerrit that GCC uses or something)?

Please show the full link command line - it’s either missing the C library that contains strlen, or it’s in the wrong order.

This is most likeley a packaging issue, so the place to submit an issue is GitHub - alire-project/GNAT-FSF-builds: Builds of the GNAT Ada compiler from FSF GCC releases

1 Like

Is this that I had kept, enough? I might actually be happier with my own solution now but happy to revert it if more is needed.

/home/kc/.config/alire/cache/dependencies/gnat_arm_elf_12.2.1_9be2ca0e/bin/…/lib/gcc/arm-eabi/12.2.0/…/…/…/…/arm-eabi/bin/ld: /home/kc/.config/alire/cache/dependencies/gnat_arm_elf_12.2.1_9be2ca0e/arm-eabi/lib/gnat/light-cortex-m4f/adalib/libgnat.a(i-cstrin.o): in function interfaces__c__strings__value': i-cstrin.adb:(.text.interfaces__c__strings__value+0xe): undefined reference to strlen’

You could try adding -lc to your linker switches (that runtime seems not to include libc by default, see runtime.xml).

I had a look at the object file, can’t see any reason why it’d want _strlen, and disassembling the object doesn’t show it as undefined. Baffled.


Thanks for your efforts Simon. -lc doesn’t seem to have any affect on the output. I shall try not to bring this up again (now getting deja vu about bringing this up previously).

I do see a -nolibc flag at the last stage when building my project. I would rather keep libc away if possible anyway, so not sure if I caused that or not but I can’t see where currently.

I am happy to move on but I have saved the output, if you would like to see it?

I found out a lot more about this: see this issue.

You could try adding your own System.Strlen ([bs]), on the lines of s-memcpy - could perhaps just copy over the loop part of the implementation from i-cstrin?

But then, using your own implementation seems a pretty good solution too!

1 Like

Crazy. I might have to call you Sherlock from now on!