On Jun 3, 2013, at 10:44 AM, Peter Wemm <pe...@wemm.org> wrote:
>>
>> Unfortunately, this means python needs to be recompiled from ports with
>> the following fix:
>>
>> Index: files/patch-Modules-_ctypes-libffi-fficonfig.py.in
>> ===================================================================
>> --- files/patch-Modules-_ctypes-libffi-fficonfig.py.in (revision 0)
>> +++ files/patch-Modules-_ctypes-libffi-fficonfig.py.in (working copy)
>> @@ -0,0 +1,10 @@
>> +--- Modules/_ctypes/libffi/fficonfig.py.in.orig 2013-06-03
>> 07:16:44.000000000 -0700
>> ++++ Modules/_ctypes/libffi/fficonfig.py.in 2013-06-03
>> 07:17:03.000000000 -0700
>> +@@ -1,7 +1,6 @@
>> + ffi_sources = """
>> + src/prep_cif.c
>> + src/closures.c
>> +-src/dlmalloc.c
>> + """.split()
>> +
>> + ffi_platforms = {
>>
>> This has been tested with python-2.7.5. I can't say anything about
>> other versions.
>>
>> Do people concur that this is the right fix?
>
> Forgive me for asking dumb questions, but:
>
> * Does this fix the firefox, chromium etc problems? (were they linked
> to python?)
libffi and this _ctypes.so is (based on an educated guess) the core
of Python bindings. Anything that has a python binding is likely to
have been broken.
> * Even if the python code is wrong, is this one of those things that's
> going to keep biting us going forward? Interactions between
> dlopen/dlsym/rtld/library dependencies/embedded malloc
> replacements/etc has been accumulated a large number of casualties
> over the years.
Possibly. We do not seem to have ever had weak symbols for malloc()
et al. Any shared library that exports malloc() and/or friends is
potentially causing breakages. Those are breakages only seen on
FreeBSD, I would think.
I can do some analysis if people prefer. All it takes is the complete
set of packages and run nm on any ELF files to see if malloc() or
friends is defined as a global symbol to havea protential problem.
With a bit of scripting we can come up with a list of candidates.
We can go from there...
--
Marcel Moolenaar
mar...@xcllnt.net
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
