Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Nov 2018 14:55:19 +0100
From: Gernot Reisinger <>
Subject: Question regarding dynamic loader

I recently stumbled upon an issue with preloading a shared object into a Go
application (see related Go ticket

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

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.