Date: Wed, 21 Nov 2018 14:55:19 +0100 From: Gernot Reisinger <Gernot.Reisinger@...ino.at> To: musl@...ts.openwall.com Subject: Question regarding dynamic loader Hi, I recently stumbled upon an issue with preloading a shared object into a Go application (see related Go ticket https://github.com/golang/go/issues/28909 ). In short - Go comes with an internal linker which will not link crt code to the application. The entry point will directly execute Go standard library code. As musl libc calls shared object constructors in crt code, the shared objects constructors subsequently will never be invoked. Things will work on glibc systems / processes. it It seems to be a subtle - but in this case wide reaching - behavioral difference to glibc. I wonder if calling constructor functions from crt code is an intended musl libc behavior. My personal - non expert - gut feeling considers glibc behavior "more correct". Is there a chance that musl will change this behavior? br Gernot Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.