> 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