Hi Adrian,
On 2021-09-26 15:43:02 +0200 John Paul Adrian Glaubitz
<glaub...@physik.fu-berlin.de> wrote:
On 9/26/21 15:39, Riccardo Mottola wrote:
That's a bit a similar issue with building libffi locally. In
/usr/local
I am unsure it would be picked up. I can of course still do it and
perhaps
have GNUstep pick it up and do some tests there.
In the meanwhile, I'm setting up to configure and build libffi
locally.
You can build libffi locally and then make your application make use
of it
by setting LD_LIBRARY_PATH=/path/to/local/libffi so that your
application
picks it up from there, e.g.
$ LD_LIBRARY_PATH=/home/user/libffi/ python2.7
While out to a walk, I had the same idea.. I wasn't sure it would work
but "ldd" confirms that the local version of the library is picked up.
Thus I got latest git of libffi from the repository you usggested.
Configured and built without any additional parameter.
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
And things works. Python does not crash and GNUstep works, as I am
typing this right mail from my iMac.
Now this means that thebug is not present in current upstream. Either
it is already solved, or there is an issue in the Debian package.
Would you like me to build the latest "release" of libffi ?
I'd like to run libffi tests, which would be a little more certain
instead of jjust trying out application, but it fails fro missing
"runtest". Is that a developer package I never heard of?
Cheers,
Riccardo
--
Sent with GNUMail from iMac PowerPC 64bit running GNUstep on Debian/PPC
