> On 13 Jan 2026, at 12:45, hongxu via lists.openembedded.org > <[email protected]> wrote: > > $ echo "TCLIBC = 'musl'" >> conf/local.conf > $ echo "MACHINE = 'qemux86'" >> conf/local.conf > $ bitbake flac > ... > | libtool: link: (cd .libs/libFLAC++-static.lax/libFLAC-static.a && > i686-oe-linux-musl-gcc-arx > "/buildarea5/hjia/oe-core/build/tmp/work/core2-32-oe-linux-musl/flac/1.5.0/build/src/libFLAC++/ > ../libFLAC/.libs/libFLAC-static.a") > | > build/tmp/work/core2-32-oe-linux-musl/flac/1.5.0/recipe-sysroot-native/usr/bin/ > i686-oe-linux-musl/../../libexec/i686-oe-linux-musl/gcc/i686-oe-linux-musl/15.2.0/ld: > .libs/metadata.o: in function `FLAC::Metadata::VorbisCo > mment::set_comment(unsigned int, FLAC::Metadata::VorbisComment::Entry > const&)': > | /usr/src/debug/flac/1.5.0/src/libFLAC++/metadata.cpp:913:(.text+0x2032): > undefined reference to `__stack_chk_fail_local' > ... > > Disable stack smash protection to workaround the failure
Disabling stack smash protection in a library whose sole job is to parse untrusted files sounds dangerous. Can we just fix the linkage instead? If this is a case where musl doesn’t implement enough support for GCC’s functionality then the disabling should probably be done globally in security_flags.inc with good references as to why that is being done. Ross
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#229628): https://lists.openembedded.org/g/openembedded-core/message/229628 Mute This Topic: https://lists.openembedded.org/mt/117242048/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
