[issue36081] Cannot set LDFLAGS containing $
New submission from Rolf Eike Beer : My use case is: LDFLAGS=-Wl,-rpath,'$ORIGIN/../lib' This works fine for everything build directly by the Makefile, but for everything that is build through the python distutils this breaks. This is not an issue of the python side, it happens because the Makefile passes the information to python using LDSHARED='$(BLDSHARED)'. At this point the variable is expanded and the $ORIGIN is expanded by the shell (or so) before passing it to python, so python actually received "-Wl,-rpath,/../lib" from the environment variable. I have worked around locally by doing something like $(subst $$,~dollar~,$(BLDSHARED)) and replacing that inside python with \\$ or so. Really hacky, but works for my current setup. -- components: Build messages: 336326 nosy: Dakon priority: normal severity: normal status: open title: Cannot set LDFLAGS containing $ type: compile error versions: Python 2.7, Python 3.7 ___ Python tracker <https://bugs.python.org/issue36081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36081] Cannot set LDFLAGS containing $
Rolf Eike Beer added the comment: No, it's not. $ORIGIN is a special value that must be literally in the RPATH (i.e. in the ELF), so that the binary is relocatable and will looks for the libraries relative to it's location. I wonder if I could do "export ORIGIN='$ORIGIN'" instead, so the expansions will bring back the original value again. This is only a solution for this usecase. -- ___ Python tracker <https://bugs.python.org/issue36081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33145] unaligned accesses in siphash24() lead to crashes on sparc
Change by Rolf Eike Beer : -- components: Library (Lib) nosy: Dakon priority: normal pull_requests: 5983 severity: normal status: open title: unaligned accesses in siphash24() lead to crashes on sparc versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28055] pyhash's siphash24 assumes alignment of the data pointer
Change by Rolf Eike Beer : -- pull_requests: +5986 ___ Python tracker <https://bugs.python.org/issue28055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28055] pyhash's siphash24 assumes alignment of the data pointer
Rolf Eike Beer added the comment: So, what is the problem with this? Either the compiler knows that unaligned accesses are no problem and optimizes them away anyway, or it is kept because it would crash otherwise. I can confirm that no sparc version >= 3.5 (have not tried older) survives the test suite on Gentoo Sparc (64 bit kernel, 32 bit userspace) without memcpy(). -- nosy: +Dakon ___ Python tracker <https://bugs.python.org/issue28055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
