non-standard glibc location

2017-09-06 Thread Fetchinson . via Python-list
Hi folks,

I'm trying to install a binary package (tensorflow) which contains
some binary C extensions. Now my system glibc is 2.15 but the binaries
in the C extensions were created (apparently) with glibc 2.17. So I
thought no problemo I installed glibc 2.17 to a custom location, built
python2.7 from source (hopefully using my custom glibc) and installed
pip and everything else using this custom built python. But still when
I try to import tensorflow I get:

ImportError: /lib64/libc.so.6: version `GLIBC_2.17' not found
(required by 
/home/nogradi/fetch/custom/lib/python2.7/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so)

So apparently it's trying to use my system glibc, not the custom one.

How do I tell this extension to use the custom glibc? Is it even possible?

But maybe I have an even more basic issue: how do I link python not
with the system glibc but with my custom glibc?

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: non-standard glibc location

2017-09-07 Thread Fetchinson . via Python-list
On 9/7/17, Thomas Jollans  wrote:
> On 2017-09-06 16:14, Fetchinson . via Python-list wrote:
>> Hi folks,
>>
>> I'm trying to install a binary package (tensorflow) which contains
>> some binary C extensions. Now my system glibc is 2.15 but the binaries
>> in the C extensions were created (apparently) with glibc 2.17. So I
>> thought no problemo I installed glibc 2.17 to a custom location, built
>> python2.7 from source (hopefully using my custom glibc) and installed
>> pip and everything else using this custom built python. But still when
>> I try to import tensorflow I get:
>>
>> ImportError: /lib64/libc.so.6: version `GLIBC_2.17' not found
>> (required by
>> /home/nogradi/fetch/custom/lib/python2.7/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so)
>>
>> So apparently it's trying to use my system glibc, not the custom one.
>>
>> How do I tell this extension to use the custom glibc? Is it even
>> possible?
>
> It's going to use the same libc as python, so first of all check which
> libc your python interpreter is actually linked to. Maybe your custom
> build didn't do quite what you wanted.
>
> ldd `which python` # or something like that
>
> Once you've convinced yourself that python has the correct libc, you
> could try building tensorflow from source rather than installing the
> binaries.
>
> Maybe something in here helps:
> https://github.com/tensorflow/tensorflow/issues/53

Thanks a lot for all the comments, my problem was indeed that the
compiled python was still using the system glibc. The solution was to
set the environment variables

p=/path/to/custom/glibc
export CFLAGS=-I${p}/include
export LDFLAGS="-Wl,--rpath=${p}/lib
-Wl,--dynamic-linker=${p}/lib/ld-linux-x86-64.so.2"

And then the compiled python was using the new glibc.

Side note 1 on tensorflow: the compiled tensorflow binary uses unicode
ucs4, so for python I had to ./configure --enable-unicode=ucs4 because
the default is ucs2

Side note 2 on tensorflow: it also depends on libstdc++ and my version
was too old for that as well. Instead of compiling gcc from source
(which includes libstdc++) I copied a binary libstdc++ from a newer
linux distro and it was working fine.

And the reason, if anyone cares, I had to go through the above is that
I couldn't compile tensorflow from source.

Thanks again,
Daniel




>
>>
>> But maybe I have an even more basic issue: how do I link python not
>> with the system glibc but with my custom glibc?
>>
>> Cheers,
>> Daniel
>>
>>
>>
>
>
> --
> Thomas Jollans
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


why does memory consumption keep growing?

2017-10-05 Thread Fetchinson . via Python-list
Hi folks,

I have a rather simple program which cycles through a bunch of files,
does some operation on them, and then quits. There are 500 files
involved and each operation takes about 5-10 MB of memory. As you'll
see I tried to make every attempt at removing everything at the end of
each cycle so that memory consumption doesn't grow as the for loop
progresses, but it still does.

import os

for f in os.listdir( '.' ):

x = [ ]

for ( i, line ) in enumerate( open( f ) ):

import mystuff
x.append( mystuff.expensive_stuff( line ) )
del mystuff

import mystuff
mystuff.some_more_expensive_stuff( x )
del mystuff
del x


What can be the reason? I understand that mystuff might be leaky, but
if I delete it, doesn't that mean that whatever memory was allocated
is freed? Similary x is deleted so that can't possibly make the memory
consumption go up.

Any hint would be much appreciated,
Daniel




-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: why does memory consumption keep growing?

2017-10-05 Thread Fetchinson . via Python-list
On 10/5/17, Chris Angelico  wrote:
> On Fri, Oct 6, 2017 at 8:06 AM, Fetchinson . via Python-list
>  wrote:
>> Hi folks,
>>
>> I have a rather simple program which cycles through a bunch of files,
>> does some operation on them, and then quits. There are 500 files
>> involved and each operation takes about 5-10 MB of memory. As you'll
>> see I tried to make every attempt at removing everything at the end of
>> each cycle so that memory consumption doesn't grow as the for loop
>> progresses, but it still does.
>>
>> import os
>>
>> for f in os.listdir( '.' ):
>>
>> x = [ ]
>>
>> for ( i, line ) in enumerate( open( f ) ):
>>
>> import mystuff
>> x.append( mystuff.expensive_stuff( line ) )
>> del mystuff
>>
>> import mystuff
>> mystuff.some_more_expensive_stuff( x )
>> del mystuff
>> del x
>>
>>
>> What can be the reason? I understand that mystuff might be leaky, but
>> if I delete it, doesn't that mean that whatever memory was allocated
>> is freed? Similary x is deleted so that can't possibly make the memory
>> consumption go up.
>
> You're not actually deleting anything. When you say "del x", all
> you're doing is removing the *name* x. Especially, deleting an
> imported module basically does nothing; it's a complete waste of time.
> Modules are kept in their own special cache.

Meaning that if mystuff has some leaky stuff in it, there is no way
for me to recover?

Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


How to make python pick up my new-and-shiny openssl shared object

2018-08-07 Thread Fetchinson . via Python-list
The highest version of openssl available on my system is 1.0.0 which
is not good enough for pip these days (or github for that matter). So
I've installed 1.1.0 to a custom location /home/fetch/opt. But if I do

import ssl
ssl.OPENSSL_VERSION

it still shows me that it is using the system default 1.0.0. How do I
tell python to use /home/fetch/opt for the ssl module? Note that I
have /home/fetch/opt as the first entry in LD_LIBRARY_PATH. Also, I
know for a fact that I don't need to recompile python for this so
please don't suggest "just recompile python with the new openssl
library" as the solution :)

By the way my python is 2.7.3.

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: How to make python pick up my new-and-shiny openssl shared object

2018-08-08 Thread Fetchinson . via Python-list
On 8/8/18, Christian Heimes  wrote:
> On 2018-08-08 00:07, Fetchinson . via Python-list wrote:
>> The highest version of openssl available on my system is 1.0.0 which
>> is not good enough for pip these days (or github for that matter). So
>> I've installed 1.1.0 to a custom location /home/fetch/opt. But if I do
>>
>> import ssl
>> ssl.OPENSSL_VERSION
>>
>> it still shows me that it is using the system default 1.0.0. How do I
>> tell python to use /home/fetch/opt for the ssl module? Note that I
>> have /home/fetch/opt as the first entry in LD_LIBRARY_PATH. Also, I
>> know for a fact that I don't need to recompile python for this so
>> please don't suggest "just recompile python with the new openssl
>> library" as the solution :)
>
> Hi,
>
> first of all, you need to use the library directory for LD_LIBRARY_PATH.
> It's the directory that contains libssl*.so, probably
> /home/fetch/opt/lib or /home/fetch/opt/lib64.

Yes, you are right, thanks. But it still doesn't work, most probably
because of the reason you mention below.


> You may also have to recompile Python yourself. OpenSSL 1.0.2 is not
> ABI-compatible with OpenSSL 1.0.0. In case you want to use OpenSSL
> 1.1.0, you must update to a more recent version of Python, too. OpenSSL
> 1.1.0 support was added in 2.7.13.

Ach, you are right again! I thought openssl was fully backward
compatible, if not, then indeed I need to recompile, which I'll do
now.

Thanks a lot,
Daniel


> Christian
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


compiling 3.7.0 from source with custom libffi path

2018-09-24 Thread Fetchinson . via Python-list
I'm trying to compile python 3.7.0 from source with a custom libffi
path and the compiler/linker doesn't seem to pick up the right
version. The system libffi doesn't have the development files so I've
installed the latest libffi (also from source) to /opt/custom but
still I get

INFO: Could not locate ffi libs and/or headers

Failed to build these modules:
_ctypes

Although I compile python with --prefix=/opt/custom because that's the
location I'd like to install it too. So how do I tell the build system
where to find my custom libffi?

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: compiling 3.7.0 from source with custom libffi path

2018-09-24 Thread Fetchinson . via Python-list
>> I'm trying to compile python 3.7.0 from source with a custom libffi
>> path and the compiler/linker doesn't seem to pick up the right
>> version. The system libffi doesn't have the development files so I've
>> installed the latest libffi (also from source) to /opt/custom but
>> still I get
>>
>> INFO: Could not locate ffi libs and/or headers
>
> Apparently the configure script uses pkg-config to locate libffi.[1] You
> should be able to get it to find your libffi by setting PKG_CONFIG_PATH
> appropriately (probably to "/opt/custom/lib/pkgconfig" ?)
>
> [1]: https://github.com/python/cpython/blob/v3.7.0/configure.ac#L2936

Thanks, tried it, but still no luck, exact same error message.

Cheers,
Daniel



>>
>> Failed to build these modules:
>> _ctypes
>>
>> Although I compile python with --prefix=/opt/custom because that's the
>> location I'd like to install it too. So how do I tell the build system
>> where to find my custom libffi?
>>
>> Cheers,
>> Daniel
>>
>>
>>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: compiling 3.7.0 from source with custom libffi path

2018-09-24 Thread Fetchinson . via Python-list
On 9/24/18, Thomas Jollans  wrote:
> On 2018-09-24 14:14, Fetchinson . via Python-list wrote:
>>>> I'm trying to compile python 3.7.0 from source with a custom libffi
>>>> path and the compiler/linker doesn't seem to pick up the right
>>>> version. The system libffi doesn't have the development files so I've
>>>> installed the latest libffi (also from source) to /opt/custom but
>>>> still I get
>>>>
>>>> INFO: Could not locate ffi libs and/or headers
>>>
>>> Apparently the configure script uses pkg-config to locate libffi.[1] You
>>> should be able to get it to find your libffi by setting PKG_CONFIG_PATH
>>> appropriately (probably to "/opt/custom/lib/pkgconfig" ?)
>>>
>>> [1]: https://github.com/python/cpython/blob/v3.7.0/configure.ac#L2936
>>
>> Thanks, tried it, but still no luck, exact same error message.
>
> Is there a .pc file for libffi? Can you run pkg-config manually, to
> check if it works, and finds libffi in your environment?

Yes, there is a .pc for libffi and if I first

export PKG_CONFIG_PATH=/opt/custom

then pkg-config finds the necessary include path:

[fetch@fetch]$ pkg-config libffi --cflags-only-I
-I/opt/custom/lib/libffi-3.2.1/include

And of course this path is correct:

[fetch@fetch]$ ls /opt/custom/lib/libffi-3.2.1/include
ffi.h  ffitarget.h

And also the configure script correctly creates the Makefile:

[fetch@fetch]$ grep LIBFFI_INCLUDE Makefile
LIBFFI_INCLUDEDIR=  /opt/custom/lib/libffi-3.2.1/include

So I'd say everything should work but it doesn't, I reran ./configure
and also make of course.

Cheers,
Daniel











>>
>> Cheers,
>> Daniel
>>
>>
>>
>>>>
>>>> Failed to build these modules:
>>>> _ctypes
>>>>
>>>> Although I compile python with --prefix=/opt/custom because that's the
>>>> location I'd like to install it too. So how do I tell the build system
>>>> where to find my custom libffi?
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>>
>>> --
>>> https://mail.python.org/mailman/listinfo/python-list
>>>
>>
>>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: compiling 3.7.0 from source with custom libffi path

2018-09-24 Thread Fetchinson . via Python-list
On 9/24/18, Thomas Jollans  wrote:
> On 2018-09-24 16:30, Fetchinson . via Python-list wrote:
>> [fetch@fetch]$ grep LIBFFI_INCLUDE Makefile
>> LIBFFI_INCLUDEDIR=  /opt/custom/lib/libffi-3.2.1/include
>>
>> So I'd say everything should work but it doesn't, I reran ./configure
>> and also make of course.
>
> I'm confused. ./configure succeeds? Then where's the error?

Yes, ./configure succeeds, also make succeeds in general, so it
produces a usable python executable but _ctypes is not compiled so
_ctypes is not usable and can not be imported, libffi is only needed
for _ctypes AFAIK. The error, or better said INFO message, comes from
make:

INFO: Could not locate ffi libs and/or headers

Failed to build these modules:
_ctypes

But nevertheless make install also succeeds, the only thing is that
_ctypes does not work.

Cheers,
Daniel

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: So apparently I've been banned from this list

2018-10-01 Thread Fetchinson . via Python-list
On 10/1/18, Roel Schroeven  wrote:
> jkn schreef op 1/10/2018 om 20:25:
>> On Monday, October 1, 2018 at 6:57:30 PM UTC+1, Ethan Furman wrote:
>>> On 09/30/2018 09:30 AM, Steven D'Aprano wrote:
>>>
 Notwithstanding Ethan's comment about having posted the suspension
 notice
 on the list, I see no sign that he actually did so.
>>>
>>> My apologies to you and the list.  I did indeed only send the notice to
>>> the other moderators.
>>>
>>> I have updated the filter that should be catching your posts, so
>>> hopefully the suspension is now working properly.  Since you did choose
>>> to ignore the ban, the two-month period restarts now.
>>>
>>
>> As a reader of /occasional contributor to, this newsgroup (via GG,
>> admittedly)
>> since around the year 2000, I for one am mightily unimpressed with this.
>> There's a lot of heavy-handedness going around.
>>
>> And then ... you make a mistake, and then restart the ban?? Sheesh, where
>> has
>> happened to the the grown-up behaviour that c.l.python has always had?
>> That has been one of its hallmarks for the past nearly twenty years.
>>
>> I'm not going to go as far as to agree with anything RR says on the matter
>> -
>> but c'mon guys, lighten up.
>
> Yeah I don't understand this neither.
>
> I'm not very active here, but I've been lurking for years. In my eyes
> Steven has always been active and helpful. Now he has *once* been a
> *tiny bit* rude, and he's banned for that?
>
> As far as I can see the moderators do a pretty good job overall, but
> this decision is ... weird.

+1

Steven has been around for a long time, after a quick search it seems
for at least 15 years, I mean on python-list. He has consistently been
helpful and has dedicated an amazing number of man hours to altruistic
help of fellow python users, beginners, experts, etc.

I'm totally amazed by this decision to ban him. The official
explanation has referenced 2 potentially mildly problematic posts.

I guess the moderators do have and should have the power to ban people
but we all have the right to criticise these bans on a case by case
basis. I'm not implying that Ethan and the moderators who were
involved in the ban are doing a bad job in general, but in this
particular case it does seem hyper excessive.

Cheers,
Daniel

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


web facing static text db

2016-04-29 Thread Fetchinson . via Python-list
Hi folks,

I have a very specific set of requirements for a task and was
wondering if anyone had good suggestions for the best set of tools:

* store text documents (about 10 pages)
* the data set is static (i.e. only lookups are performed, no delete,
no edit, no addition)
* only one operation required: lookup of pages by matching words in them
* very simple web frontend for querying the words to be matched
* no authentication or authorization, frontend completely public
* deployment at webfaction
* deadline: yesterday :)

Which web framework and db engine would you recommend?

So far I'm familiar with turbogears but would be willing to learn
anything if sufficiently basic since my needs are pretty basic (I
think).

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: web facing static text db

2016-04-30 Thread Fetchinson . via Python-list
On 4/30/16, Gordon Levi  wrote:
> "Fetchinson ."  wrote:
>
>>Hi folks,
>>
>>I have a very specific set of requirements for a task and was
>>wondering if anyone had good suggestions for the best set of tools:
>>
>>* store text documents (about 10 pages)
>>* the data set is static (i.e. only lookups are performed, no delete,
>>no edit, no addition)
>>* only one operation required: lookup of pages by matching words in them
>>* very simple web frontend for querying the words to be matched
>>* no authentication or authorization, frontend completely public
>>* deployment at webfaction
>>* deadline: yesterday :)
>>
>>Which web framework and db engine would you recommend?
>>
>>So far I'm familiar with turbogears but would be willing to learn
>>anything if sufficiently basic since my needs are pretty basic (I
>>think).
>>
>
> What do need that storing the documents in HTML format and Google
> Custom Search does not provide
> ?

Wow! Thanks, I was not aware of that, sounds exactly what I need.

Thanks for all the other ideas too.

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


building 3.7.1 from source, _ctypes and libffi troubles

2018-12-20 Thread Fetchinson . via Python-list
Hi all, I'm trying to build 3.7.1 from source and having trouble with
libffi and _ctypes. I'm on linux and have installed libffi also from
source to a custom location:

$HOME/opt/lib64/libffi.so.6.0.4
$HOME/opt/lib64/libffi.a
$HOME/opt/lib64/libffi.la
$HOME/opt/lib64/libffi.so.6
$HOME/opt/lib64/libffi.so
$HOME/opt/lib/pkgconfig/libffi.pc
$HOME/opt/lib/libffi-3.2.1/include/ffi.h
$HOME/opt/lib/libffi-3.2.1/include/ffitarget.h
$HOME/opt/share/info/libffi.info

I have no idea why the installation is somewhat scattered, these are
the default locations that were created by

./configure --prefix=$HOME/opt

of the source libffi.

In any case, just to be sure, I've copied the header files to

$HOME/opt/include/ffi.h
$HOME/opt/include/ffitarget.h

Looks like pkg-config works as intended:

[fetch@fetch opt]$ pkg-config --libs libffi
-L/home/fetch/opt/lib/../lib64 -lffi

[fetch@fetch opt]$ pkg-config --cflags libffi
-I/home/fetch/opt/lib/libffi-3.2.1/include

And as far as I know pkg-config is used by python's configure script
so everything should be fine. I also set
LD_LIBRARY_PATH=/home/fetch/opt/lib:/home/fetch/opt/lib64 and also
C_INCLUDE_PATH=/home/fetch/opt/include

And still I get

Failed to build these modules:
_ctypes

from make when I try to build python 3.7.1 Also tried adding
--with-system-ffi to ./configure but that didn't help either.

Does anyone have an idea what's wrong? I've seen some related bug reports, e.g.

https://bugs.python.org/issue35170

but these were typically solved by the OP installing libffi from the
repository of his/her distro. Note that in my case I must compile
libffi from source.

Any ideas?

Thanks a lot,
Daniel





-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: building 3.7.1 from source, _ctypes and libffi troubles

2018-12-20 Thread Fetchinson . via Python-list
On 12/20/18, Fetchinson .  wrote:
> Hi all, I'm trying to build 3.7.1 from source and having trouble with
> libffi and _ctypes. I'm on linux and have installed libffi also from
> source to a custom location:
>
> $HOME/opt/lib64/libffi.so.6.0.4
> $HOME/opt/lib64/libffi.a
> $HOME/opt/lib64/libffi.la
> $HOME/opt/lib64/libffi.so.6
> $HOME/opt/lib64/libffi.so
> $HOME/opt/lib/pkgconfig/libffi.pc
> $HOME/opt/lib/libffi-3.2.1/include/ffi.h
> $HOME/opt/lib/libffi-3.2.1/include/ffitarget.h
> $HOME/opt/share/info/libffi.info
>
> I have no idea why the installation is somewhat scattered, these are
> the default locations that were created by
>
> ./configure --prefix=$HOME/opt
>
> of the source libffi.
>
> In any case, just to be sure, I've copied the header files to
>
> $HOME/opt/include/ffi.h
> $HOME/opt/include/ffitarget.h
>
> Looks like pkg-config works as intended:
>
> [fetch@fetch opt]$ pkg-config --libs libffi
> -L/home/fetch/opt/lib/../lib64 -lffi
>
> [fetch@fetch opt]$ pkg-config --cflags libffi
> -I/home/fetch/opt/lib/libffi-3.2.1/include
>
> And as far as I know pkg-config is used by python's configure script
> so everything should be fine. I also set
> LD_LIBRARY_PATH=/home/fetch/opt/lib:/home/fetch/opt/lib64 and also
> C_INCLUDE_PATH=/home/fetch/opt/include
>
> And still I get
>
> Failed to build these modules:
> _ctypes
>
> from make when I try to build python 3.7.1 Also tried adding
> --with-system-ffi to ./configure but that didn't help either.
>
> Does anyone have an idea what's wrong? I've seen some related bug reports,
> e.g.
>
> https://bugs.python.org/issue35170
>
> but these were typically solved by the OP installing libffi from the
> repository of his/her distro. Note that in my case I must compile
> libffi from source.
>
> Any ideas?
>
> Thanks a lot,
> Daniel

I just found a bug report from the end of September detailing the
exact same problem:

https://bugs.python.org/issue34823

It's still open with no comments at all :(

Is there a chance this will be fixed?

Summarizing: the problem is that python can't be build on linux from
source if libffi is installed to non-standard directories.

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: building 3.7.1 from source, _ctypes and libffi troubles

2018-12-25 Thread Fetchinson . via Python-list
>> And as far as I know pkg-config is used by python's configure script
>> so everything should be fine. I also set
>> LD_LIBRARY_PATH=/home/fetch/opt/lib:/home/fetch/opt/lib64 and also
>> C_INCLUDE_PATH=/home/fetch/opt/include
>
> I looked into this a little. I found that setting C_INCLUDE_PATH as you
> did disables finding libffi headers since pkg-config prints nothing with
> pkg-config --cflags libffi then and it seems the headers are found with
> pkg-config.

This didn't actually occur for me, I had C_INCLUDE_PATH set and your
second suggestion (see below) worked.

> As for the libraries, detect_modules() in setup.py wants to find extra
> library directories from the generated makefile so you need to make sure
> they actually go in there, like this for example:
>
> LDFLAGS=`pkg-config --libs-only-L libffi` ./configure
>
> Then you'll have CONFIGURE_LDFLAGS and PY_LDFLAGS set in the generated
> makefile and setup.py will pick up the directory from there.

Thanks a lot! This indeed worked, now _ctypes compiles no problemlo!

Cheers,
Daniel


> Anyways, hope it helps. This worked for me on Ubuntu 16.04.5 LTS.
-- 
https://mail.python.org/mailman/listinfo/python-list