<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">Simon Kissel <<a href="mailto:simon.kissel@nerdherrschaft.com">simon.kissel@nerdherrschaft.com</a>> schrieb am So., 28. Okt. 2018, 12:30:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Florian,<br>
<br>
> The %gs based approach works only for object files linked statically to<br>
> the executable. In general there are four TLS access models on linux and<br>
> at least three of them need to be supported, if one wants to support <br>
> dyn. libraries in a usefull manner.<br>
<br>
Are you talking about being able to create dynlibs in FPC,<br>
that then are consumed by FPC, and need to be able to support<br>
exceptions?<br>
<br>
I know an approach is needed that FPC benefits from in a generic<br>
way, but for my case: We don't do that. As long as I am able<br>
to link against glibc-based stuff, I am fine.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The thing is that we can't enable or disable a feature based on whether a program links third party libraries or a unit is included in a library or not, cause we might need to work with precompiled units. So either you'll need to enable this feature for a locally build FPC amd be aware that you can't really create libraries then or the feature needs to be implemented completely. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>