undefined reference to shm_open #1
Comments
|
Are you able to run oss-build-and-test.sh ? If you are what is the output of that? |
|
Same issue: |
|
Maybe I can help with this issue. I've got a similar problem and I think I fixed by doing some changes to the Makefile.pre.in: diff --git a/Makefile.pre.in b/Makefile.pre.in
index b2d5908..7158b2a 100644
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -119,13 +119,7 @@ PY_CXXFLAGS_NODIST=$(CONFIGURE_CXXFLAGS_NODIST) $(CXXFLAGS_NODIST) -I$(srcdir)/I
# environment variables
PY_CPPFLAGS= $(BASECPPFLAGS) -I. -I$(srcdir)/Include -I$(srcdir)/ThirdParty/fmt-6.1.1/include -I$(srcdir)/ThirdParty/i386-dis $(CONFIGURE_CPPFLAGS) $(CPPFLAGS) -DFMT_HEADER_ONLY=1
PY_LDFLAGS_NODIST=$(CONFIGURE_LDFLAGS_NODIST) $(LDFLAGS_NODIST)
-OS_NAME := $(shell uname -s)
-ifeq ($(OS_NAME), Darwin)
- LRT_FLAG=
-else
- LRT_FLAG=-lrt
-endif
-PY_LDFLAGS= $(CONFIGURE_LDFLAGS) $(LDFLAGS) $(LRT_FLAG)
+PY_LDFLAGS= $(CONFIGURE_LDFLAGS) $(LDFLAGS)
NO_AS_NEEDED= @NO_AS_NEEDED@
SGI_ABI= @SGI_ABI@
@@ -256,6 +250,10 @@ INSTSONAME= @INSTSONAME@
LIBS= @LIBS@
+OS_NAME := $(shell uname -s)
+ifneq ($(OS_NAME), Darwin)
+ LIBS += -lrt
+endif
LIBM= @LIBM@
LIBC= @LIBC@
SYSLIBS= $(LIBM) $(LIBC)After applying the changes, I did a The problem is that the I'm sorry I don't have the time to make a proper PR and to find out if this really fixes the build on Ubuntu 20.04 (as some modules apparently still can't be build and I don't know if it is related to my changes or they couldn't be build from the start) but it's progress :-) |
alexdoesh
added a commit
to alexdoesh/cinder
that referenced
this issue
May 6, 2021
|
It would also be possible to define |
facebook-github-bot
pushed a commit
that referenced
this issue
Jul 14, 2021
Summary: This is basically backing away from the approach used in D28698373 (695adea). It turns out `set_type` isn't a very good place to centralize these checks. There's a few of problems: 1) With an error sink used for error reporting, we end up reporting multiple errors when we are otherwise doing type checks later. First we report an error about the `type_ctx` in `set_type`, and then we report an error when we check the error. 2) Related to #1 we also have a pattern that's developed of `try/except TypedSyntaxError:` to improve the error messages. This also leads to duplicate messages about the same error. 3) Without a `type_ctx` we end up reporting a worse error than we could if we check later. You can see that in this diff where a lot of errors in test cases go from a random type mismatch to an unexpected return type. 4) We typically flow down the existing `type_ctx` and don't introduce a new one. We could start doing `visit(..., type_ctx or DYNAMIC)` but given the first two issues that doesn't seem like that's the right solution. So this diff introduces a new `visitExpectedType` which visits the node, and then validates that the type is assignable with the option for a custom error message. This API doesn't necessarily have to be used consistently because we frequently do type checks for other calls. It removes the type check in `set_type` but doesn't yet update the callers to remove passing the parameter, that'll come in a separate diff to keep things simple. That'll be done in the next diff. Reviewed By: carljm Differential Revision: D29577188 fbshipit-source-id: 84da687
facebook-github-bot
pushed a commit
that referenced
this issue
Nov 1, 2021
Summary: We always create fresh context when starting new eagerly executed coroutine that could be wrapped by the task otherwise. Currently if coroutine is suspended and task is created to drive the coroutine going forward - task unconditionally captures the copy of the context so when coroutine is resumed - it will be running under different context than one that was used to start the coroutine. ``` # context #1 is created before we start the execution async def g(): # here we use context #1 # this line cause the coroutine to be suspended # Task that will be created will implicitly capture the copy of context #2 so the rest of the coroutine will use context #2 await asyncio.sleep(0) # here we use context #2 ``` This causes issues when contextvars are used since they often assume that context is consistent for the entire body of the coroutine. Simplest solution seems to be to swap context #2 with context #1. We do this by adding new function to the dispatch table. Reviewed By: mpage Differential Revision: D32070818 fbshipit-source-id: 1e118de
facebook-github-bot
pushed a commit
that referenced
this issue
May 25, 2023
Summary: This diff adds initial implementation of cycle checking when running `AsyncLazyValue` is awaited directly or via result of `ensure_future` (support for doing this in `gather` is coming in subsequent diff) Idea of the implementation: We augment `AsyncLazyValue` so when it is started we try to find `AsyncLazyValue` that is currently running - it would be recorded in `AsyncLazyValue.parent` attribute. Lookup is done via stack walk - we use dedicated Python entrypoint that will not be JIT-ted so we can find Python frame for it during the stack walk and pull local value from a known slot. When `ALVResultFuture` #1 is awaited we again look for `AsyncLazyValue` #2 that is currently running. If it is not found - this means that code is executed outside of `AsyncLazyValue` and we can continue as-is. Otherwise we set the bit on future #1 so it could be distinguished later and do a recursive walk over futures in `AsyncLazyValue`'s starting from #2 trying to find #1. If we succeed - this means that `AsyncLazyValue` that supposed to provide value for #1 is already blocked expecting result from #2 so computation will never finish. Reviewed By: mpage, carljm Differential Revision: D45214461 fbshipit-source-id: 82bb92f28305ea559a5283a81ad4a9304395afaf
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I get a couple of these errors when linking the final executable:
Adding
-lrtto the makefileLIBSvariable solved this for me. This is on Ubuntu 20.04.The text was updated successfully, but these errors were encountered: