[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALsoeqnLKzNMdkEUtkevpG3Upgn6HFJMvESc+N=D796acTdA2g@mail.gmail.com>
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.
