Question regarding undefined reference to functions

Nik Twerdochlib nicholas@nikom.net
Thu Aug 8 20:04:27 GMT 2024


Please accept my most since gratitude for your response.  This got me to
thinking, and after some digging I found that we pull in safeclib
through our CMake configuration which did not work as intended when
using a cross compile environment.  I got too wrapped up in my thinking
that it had to be with how I was building glibc and our use of safeclib
just didn't cross my mind.

Nik

On 8/1/2024 12:48, Adhemerval Zanella Netto wrote:
>
> On 01/08/24 13:18, Nik Twerdochlib wrote:
>> I am in the process of building two cross compile tool chains and have
>> run into a linking issue in both of them.  One tool chain is for armv7
>> the other for x86_64.
>>
>> The issue I am running into occurs during the linking phase of my software:
>>
>>    undefined reference to `_memcpy_s_chk'
>>    undefined reference to `sscanf_s'
>>    undefined reference to `_strncpy_s_chk'
>>    undefined reference to `_sprintf_s_chk'
>>    undefined reference to `_strnlen_s_chk'
>>
>> My tool chains use glibc 2.28.  Strangely I can not find any
>> implementation for these '_s' functions.  A google search for these did
>> not lead to anything of value.
>>
>> Wondering if anyone on this list would be willing to provide me with any
>> information?  I feel there is something I overlooked building the tool
>> chains.
> The _s variants are from C11 annex K, and there were never implemented in
> glibc due multiple issues [1] [2].
>
> I am not sure *why* are you seeing them while building glibc 2.28; most
> likely the references come from the programs code or some dependency.
>
> [1] https://open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
> [2] https://sourceware.org/legacy-ml/libc-alpha/2014-08/msg00133.html

--
Nik



More information about the Libc-help mailing list