It's not ok for LGPLv2.1, but it's ok for LGPLv3.
Terms under Section 5 of LGPLv2.1, will cause applications using LGPLv2.1-licensed C++ template header libraries to themselves be licensed under LGPLv2.1, if those template functions are more than ten lines of code each. This effectively turns it into a strong copyleft license, pretty much like GPLv2.
If such an object file uses only numerical parameters, data structure
layouts and accessors, and small macros and small inline functions
(ten lines or less in length), then the use of the object file is
unrestricted, regardless of whether it is legally a derivative work.
(Executables containing this object code plus portions of the Library
will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
Meanwhile, LGPLv3 fixed this problem by introducing Section 3:
- Object Code Incorporating Material from Library Header Files.
The object code form of an Application may incorporate material from a
header file that is part of the Library. You may convey such object
code under terms of your choice, provided that, if the incorporated
material is not limited to numerical parameters, data structure
layouts and accessors, or small macros, inline functions and templates
(ten or fewer lines in length), you do both of the following:
a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered
by this License.
b) Accompany the object code with a copy of the GNU GPL and this license document.
However, please note that Section 3 of LGPLv3 does not free the application author from the obligations of Sections 4d and 4e, which requires the application author to provide a way for the recipient of the combined software to modify the LGPLv3-licensed library, relink it with the application and install it.
For a LGPLv3-licensed C++ template-only header library, this makes it really hard for the application author, as he would have to make the minimum application source code, that uses the library, available to the recipient of the combined software, so that the recipient may recompile and relink the application with his modified version of the library.
Also, please note that application source code, and not object code, is required to recompile and link application software to its template source code.
This may cause proprietary application authors to avoid using LGPL-licensed C++ template header libraries, as they may not wish to expose any source code of their proprietary application.
This is explained in the libstd++ FAQ:
The LGPL requires that users be able to replace the LGPL code with a
modified version; this is trivial if the library in question is a C
shared library. But there's no way to make that work with C++, where
much of the library consists of inline functions and templates, which
are expanded inside the code that uses the library. So to allow people
to replace the library code, someone using the library would have to
distribute their own source, rendering the LGPL equivalent to the GPL.
This issue can be circumvented by using the LGPL-3.0-linking-exception. Please see this answer for details.
Another alternative, is to use the Mozilla Public License 2.0 (MPL2) license, instead of LGPLv3, as the better alternative for C++ template header libraries. It's also compatible with LGPLv2.1 and GPLv2. This too is explained in this answer.
Meanwhile, libstd++ solved this by using the GCC Runtime Library Exception, as linking exception to GPLv3.