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