Closed traversaro closed 11 months ago
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
@conda-forge-admin, please rerender
Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found some lint.
Here's what I've got...
For recipe:
<two spaces>#<one space>[<expression>]
form. See lines [58]Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
@conda-forge/casadi if you have any opinion in favor or against this feel free to comment, thanks!
This PR adds a workaround for the issue discussed in https://github.com/conda-forge/casadi-feedstock/issues/93#issuecomment-1732344044 .
In a nutshell, we have the following problems:
char** environ
global variable, then due to copy relocation two different environ symbols are present, one in the executable .bss and one in the glibc .bss . In normal conditions, the one in in the executable .bss is used (for example, this one is the one actually initialized by glibc), while the one in the glibc .bss simply remains initialized to NULL.environ
global variable (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556). So, if CasADi is used in an executable that access the environ global variable, spral can't work correctly.To workaround this, I made the following modifications for the casadi's routing to open a library via dlopen([..], [..]|RTLD_DEEPBIND):
RTLD_DEEPBIND
is used, we first check if we are in the case of a duplicate environ symbol. This is done by callingdlsym(RTLD_NEXT, "environ")
, that returns the pointer to the second environ symbol in the process symbol table (as opposed todlsym(RTLD_GLOBAL, "environ")
that just returns&environ
). If(char***)dlsym(RTLD_NEXT, "environ") != &environ
, then we know that we are in the case of duplicate environ symbol.*((char***)dlsym(RTLD_NEXT, "environ"))
to the value contained inenviron
, so that libraries loaded via RTLD_DEEPBIND can access the "real" environ.*((char***)dlsym(RTLD_NEXT, "environ"))
andenviron
values, for example due toenviron
reallocations due to calls tosetenv
, at the end of the loading we restore*((char***)dlsym(RTLD_NEXT, "environ"))
to its original value.This workaround is working fine locally to fix https://github.com/conda-forge/casadi-feedstock/issues/93, and I also added a regression test in the CI.
Note that in theory this can be problematic if in another thread there is a call to
setenv
that reallocates (and so invalidates) the value contained inenviron
. However, this is a risk intrinsic in any access to theenviron
global variable. For example, if there is a call tosetenv
after the first loop of https://github.com/gcc-mirror/gcc/blob/15345980633c502f0486a2e40e96224f49134130/libgomp/env.c#L2228, theenviron
variable could not be valid anymore. So the workaround only have a risk similar to any use of theenviron
global variable.Checklist
0
(if the version changed)conda-smithy
(Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)