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