At least on current libreoffice-3-6, on Linux x86, legacy C++ extensions that link against the STLport library will not find it at runtime, and will thus not work/will fail to install.  (This is only relevant for Linux x86; on Linux x86_64, we never included STLport for extensions in the first place, and on Windows the mechanism by which an extension finds STLport is sufficiently different from the Linux mechanism so that this specific issue is not relevant there.)

One example of this issue hitting in the wild is in comment 0 of bug 591707:  "Note, I remember that I had to install package libstlport4.6-dev to make Duden Korrektor 6.0 work with LibreOffice 3.5.4 provided by the distribution."

The reason is that the executables into which extensions are loaded (soffice.bin, ure.bin) need to link against the STLport library (and all the other libs making up the URE interface, so that they are already in process when extensions want to link against them without mentioning their locations on the RPATH).  In the old build system, this was taken care of e.g., with cpputools/source/unoexe/makefile.mk: "Include all relevant (see ure/source/README) dynamic libraries, so that C++ UNO components running in the uno executable have a defined environment (stlport, unxlngi6 libstdc++.so.6, and wntmsci10 uwinapi.dll are already included via APP1STDLIB, unxlngi6 libgcc_s.so.1 and wntmsci10 msvcr71.dll and msvcp71.dll are magic---TODO)"  This detail got lost when converting to the new gbuild system.