31 Oct
2011
31 Oct
'11
5:57 p.m.
Hi,
I'm looking into my issue 569 about Javascript regexp breakage. I think
the problem is that libkjs isn't finding libpcre and hence only allows
non-perl-compatible regexes. ldd shows a big difference between libkjs
3.5.12:
ldd /opt/trinity/lib/libkjs.so.1.2.0 | sort
/lib/ld-linux.so.2 (0xb7844000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7520000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7502000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7666000)
libpcre.so.3 => /lib/libpcre.so.3 (0xb7782000)
libpcreposix.so.3 => /usr/lib/libpcreposix.so.3 (0xb77b5000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb768c000)
linux-gate.so.1 => (0xb7843000)
and 3.5.13:
(snip 40 lines of library linkages which doesn't show libpcre)
libpcre-dev is definitely installed by the Debian build system, but
apparently not being picked up by whatever is in place of ./configure
nowadays. I guess it might need a cmake expert's advice, so would
appreciate any help !
That would definitely be a good possibility! I know of one other
regression due to the CMake conversion, and that is the keyboard LED
indicators.
I would suggest going through the Autotools configure.in.in / Makefile.am
files until you find the original code that located libpcre, then look at
the equivalent CMakeLists.txt file in the same directory as the locate
Makefile.am. I would also verify that the top level
kdebase/ConfigureChecks.cmake file actually looks for libpcre.
Sometimes the original Autotools build files set C defines via compiler
flags. I would make sure that any such flags are also set in the
corresponding CMakeLists.txt file.
I am not a CMake expert by any stretch of the imagination, but maybe this
is enough to point you in the right direction?
Tim