Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: static linking glxgears and glxinfo now fails (mult. def. _glapi_tls_Context, etc.)

At Mon, 01 Jun 2020 21:29:34 -0700, "Greg A. Woods" <> wrote:
Subject: static linking glxgears and glxinfo now fails (mult. def. _glapi_tls_Context, etc.)
> Perhaps common "global" variables in TLS aren't being merged by the
> linker?  Maybe I can/should just turn off -DGLX_USE_TLS for libGL and
> libglapi?  But why do both libraries define these same variables in
> objects that are pulled in?  (see below for symbols in likely modules)

So, I finally found the following commit (and a related one in
glxcurrent.c using the comment "MASSIVE KLUDGE!"):

RCS file: /cvs/master/m-NetBSD/main/xsrc/external/mit/MesaLib/dist/src/mapi/u_current.c,v
date: 2019-04-09 07:14:59 -0700;  author: maya;  state: Exp;  lines: +74 -39;  commitid: XZNykixsHy1UhGiB;
Add workaround for non-zero initialized initial-exec TLS variables.
NetBSD doesn't support these with dlopen.


Fixes dlopen of libGL reported by prlw1 on current users.
From tnn, via pkgsrc/graphics/MesaLib*.

I'm guessing I just want to avoid GLX_USE_TLS for the static libraries
for now, though I'm guessing also that a proper fix to allow use of TLS
in the static-linked case would still be desirable?  Or does this only
matter for loadable drivers, which cannot be in the static-linked world?

					Greg A. Woods <>

Kelowna, BC     +1 250 762-7675           RoboHack <>
Planix, Inc. <>     Avoncote Farms <>

Attachment: pgpjpDq_fSfVg.pgp
Description: OpenPGP Digital Signature

Home | Main Index | Thread Index | Old Index