On 09.04.2022 10:57, Jan Rękorajski wrote:
> On Fri, 08 Apr 2022, Jan Palus wrote:
>
> > On 08.04.2022 09:53, Jan Palus wrote:
> > > On 08.04.2022 09:01, Jan Rękorajski wrote:
> > > >
> > > > Python 3.10.4 (main, Apr 1 2022, 09:00:14) [GCC 11.2.0 20220208
> > > > (release)] on linux
> > > > Type "help", "copyright", "credits" or "license" for more information.
> > > > >>> from PyQt5 import Qsci
> > > > Traceback (most recent call last):
> > > > File "<stdin>", line 1, in <module>
> > > > ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so:
> > > > undefined symbol: _ZTI11QsciPrinter
> > > >
> > > > As far as I can see the symbol is there, recompiling qscintilla2 does
> > > > not fix it.
> > > >
> > > > Could someone more versed in the linker(?) take a look at it?
> > >
> > > Unfortunately it has not much to do with linking, but rather with qmake.
> > >
> > > Above symbol is defined in libqscintilla2_qt5.so which is not linked to
> > > the
> > > module, that's the reason for undefined symbol:
> > >
> > > x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries
> > > -Wl,-z,relro -Wl,-z,combreloc -Wl,--version-script=Qsci.exp -Wl,-O1
> > > -shared -o libQsci.so sipQscipart0.o sipQscipart1.o sipQscipart2.o
> > > -L/tmp/B.ldcyigur/BUILD/QScintilla-2.11.6/build-qt5/Qt4Qt5
> > > /usr/lib64/libQt5PrintSupport.so /usr/lib64/libQt5Widgets.so
> > > /usr/lib64/libQt5Gui.so /usr/lib64/libQt5Core.so -lGL -lpthread
> > >
> > > I guess linking to libqscintilla2_qt5.so should come from:
> > >
> > > Python/configure.py:
> > > qmake = {'CONFIG': 'qscintilla2'...
> > >
> > > but perhaps due to the way we build python module it can't find newly
> > > built qscintilla2? No idea.
> > >
> > > A brute force workaround is to BR: qscintilla2-qt5-devel so it finds
> > > system config.
> >
> > Fixed in 2.11.6-2.
>
> Thanks, I wonder how that symbol was defined if our rpm post-checks didn't
> catch it's missing.
One reason for sure is that we don't consider files not matching *.so.*
glob:
printf "Searching for shared objects with unresolved symbols..."; \
for f in $(find $RPM_BUILD_ROOT -type f -name '*.so.*' -print);
and the other reason is likely related to why we don't consider *.so --
these are usually plugins which happen to have plenty of unresolved
symbols which are only resolved at runtime (provided by "loader"). Like
ie python binary extensions which are rarely linked to libpython and
hence would require special handling.
_______________________________________________
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
