You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
When I try to build a multilocale Python library using our --library-python flag, I get this message:
ld: unknown option: -shared
Looking at the man page for ld on my Mac, it appears that the flag to use for building dynamic libraries is instead -dynamic. Additionally, if I modify make/compiler/Makefile.clang to use that instead, I then get an error about not being able to find -lm.
I believe this used to work back when support for multilocale Python interoperability was added. Additionally, it looks like normal compilation of Chapel executables includes -lm, so there's probably some setting we're missing for this compilation mode that is present for other builds. It could also be that we're using a different linker than normal compilation as well, since I would expect single locale Python compilation to also try to build dynamically and I wasn't encountering this issue with those compiles.
Is this issue currently blocking your progress?
No, I think I'll be able to build for multilocale Python interop testing on our new virtual machine, just waiting on information about how to log in there
Summary of Problem
Description:
When I try to build a multilocale Python library using our
--library-python
flag, I get this message:Looking at the man page for
ld
on my Mac, it appears that the flag to use for building dynamic libraries is instead-dynamic
. Additionally, if I modifymake/compiler/Makefile.clang
to use that instead, I then get an error about not being able to find-lm
.I believe this used to work back when support for multilocale Python interoperability was added. Additionally, it looks like normal compilation of Chapel executables includes
-lm
, so there's probably some setting we're missing for this compilation mode that is present for other builds. It could also be that we're using a different linker than normal compilation as well, since I would expect single locale Python compilation to also try to build dynamically and I wasn't encountering this issue with those compiles.Is this issue currently blocking your progress?
No, I think I'll be able to build for multilocale Python interop testing on our new virtual machine, just waiting on information about how to log in there
Steps to Reproduce
Source Code:
Any Chapel code compiled to be a Python library
Compile command:
chpl --library --library-python --library-dir=lib foo.chpl
Execution command:
N/A
Associated Future Test(s):
No specific future for it, since we don't currently have a job to test it.
Configuration Information
chpl --version
: 2.3.0 pre-release$CHPL_HOME/util/printchplenv --anonymize
:CHPL_TARGET_PLATFORM: darwin
CHPL_TARGET_COMPILER: clang
CHPL_TARGET_ARCH: arm64
CHPL_TARGET_CPU: none *
CHPL_LOCALE_MODEL: flat
CHPL_COMM: gasnet *
CHPL_COMM_SUBSTRATE: udp
CHPL_GASNET_SEGMENT: everything
CHPL_TASKS: qthreads
CHPL_LAUNCHER: amudprun
CHPL_TIMERS: generic
CHPL_UNWIND: none
CHPL_MEM: jemalloc
CHPL_ATOMICS: cstdlib
CHPL_NETWORK_ATOMICS: none
CHPL_GMP: bundled
CHPL_HWLOC: bundled
CHPL_RE2: bundled
CHPL_LLVM: none *
CHPL_AUX_FILESYS: none
CHPL_LIB_PIC: pic
gcc --version
orclang --version
: Apple clang version 16.0.0module list
: N/AThe text was updated successfully, but these errors were encountered: