[pypy-dev] RPython Darwin platform description so_prefixes empty

[John Zhang]

Hi all,
I have been doing some coding using RFFI to load function pointers from shared 
libraries (`llexternal` function).
However what bothers me is that apparently `Darwin_x86_64` platform class 
(defined in translator/platform/darwin.py) does not include ‘lib’ in 
`so_prefixes`. This is causing me some problems with not being able to find my 
shared libraries on macOS X.
I’m wondering if that’s intentional, or just a mistake? It should be a simple 
fix if it’s a mistake.

Regards,
John Zhang


--
John Zhang
Research Assistant
Programming Languages, Design & Implementation Division
Computer Systems Group
ANU College of Engineering & Computer Science
108 North Rd
The Australian National University
Acton ACT 2601
john.zh...@anu.edu.au





___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] Bump DARWIN_VERSION_MIN to 10.7?

[Armin Rigo]

Hi all OS/X users,

On 8 October 2016 at 12:59, Jeremy Thurgood  wrote:
> I recently tried to build RevDB on OS X and the build failed because
> __thread isn't supported on OS X 10.6 which RPython specifies as the
> minimum supported version.
>
> I've updated DARWIN_VERSION_MIN to 10.7 in the reverse-debugger
> branch[1], because otherwise it doesn't build at all on OS X. Armin
> suggested that there would be a performance benefit to increasing
> DARWIN_VERSION_MIN for pypy as well (along with adding darwin to the
> SUPPORT__THREAD list). I would like to make this change, but I don't
> want to break pypy for anyone who may still need OS X 10.6 support.

Someone with OS/ user should look at this as well:
https://bitbucket.org/pypy/pypy/issues/2432/problems-with-pypy-on-osx-dyld-symbol-not

There are maybe other similar places, too; you'd need to grep around
to find them.  Making all such places dependent on a single variable,
like this DARWIN_VERSION_MIN, would be a good start.

Then we can decide to bump the minimum OS/X version to 10.7, to get
__thread in the normal PyPy too.  This involves making sure that
__thread is really used systematically then, i.e. there is no "if
platform == darwin" that would disable their use here and there.

If no-one shows up, the current situation will not change (not using
__thread has performance implications, notably in calls to C functions
around which we release the GIL).


A bientôt,

Armin.
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev