[reportlab-users] Symbol not found in flat namespace when running on macOS 12.0.1

[Robin Becker]

On 16/11/2021 14:46, Markus Gerards wrote:
> Hi Robin,
> 
>> this makes sense, but I suppose you don't have the build log as pip probably hides the build_ext command output. What 
>> does your otool say about the created package ie is there a _renderPM.so somewhere in the venv lib. That was the thing 
>> that used freetype. So the renderPM package can use ttf fonts.
> 
> hmmm… it still does not reference anything of freetype…. But it still works, so I really don’t know, what was the 
> problem before. I only saw other libraries that where you can read out the reference of the shared library and my 
> assumption was that the same is true with this one…

inaa linux build I see this sort of thing with ldd

> $ ldd build/lib.linux-x86_64-3.10/reportlab/graphics/_renderPM.cpython-310-x86_64-linux-gnu.so 
> 	linux-vdso.so.1 (0x00007ffdcb356000)
> 	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f5f0753a000)
> 	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f5f07519000)
> 	libc.so.6 => /usr/lib/libc.so.6 (0x00007f5f0734d000)
> 	libz.so.1 => /usr/lib/libz.so.1 (0x00007f5f07333000)
> 	libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f5f07320000)
> 	libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f5f072e9000)
> 	libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007f5f0720e000)
> 	libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0x00007f5f07200000)
> 	/usr/lib64/ld-linux-x86-64.so.2 (0x00007f5f07651000)
> 	libm.so.6 => /usr/lib/libm.so.6 (0x00007f5f070bc000)
> 	libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007f5f07097000)
> 	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f5f06f61000)
> 	libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0x00007f5f06f3e000)
> 	libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f5f06ec5000)



did you try the brew install reportlab route? It's nice to know that if we can always fall back on simple. I think brew 
requires xcode availability for compiling extensions so perhaps your pip command is just as easy.


> But I think running pip with the additional command is a feasible workaround for the moment.
> I guess things are getting more transparent when macOS 12 hits the build pipelines.
> 
> Thanks!
> Markus
...........
-- 
Robin Becker