First, the "STL" is not an official term, it is the name of the library proposed for inclusing in the C++ Standard Library when there was no containers. It provides essentially container and algorithms templates.
Now, these container and algorithms templates are...templates so they produce types as needed. They don't rely on inheritance from the point of view of the user.
However, the standard library specify essentially the interface of the library, not the implementation. A lot of STL implementations will use a bit of object orientation in their implementation but as a user you will not see it if you don't dive in your implementations source code (that have to be exposed as it is essentially template code).
I learned that virtual member function which justifys the OO is
contradict with template, is this correct?
No, they are orthogonal concepts that provide very different sets of advantages and cons. In fact in C++, one of the key advantage to use such a language is that you have both available and using one don't cancel using the other. It is even a very big advantage.
For example one of the most interesting idiom in C++ is CRTP that use both templates and inheritance. The idea is that the inheritance part allows you to extend several types with a common behaviour and data, as a base class; while the template part make sure to generate specific base classes for each child, making impossible to have a pointer to all the classes using the CRTP class as base. This is extremely useful and don't allow messing with inheritance where there shouldn't be.
I've also implemented very generic event dispatching systems that didn't know either event types or listener types but combined internally dynamic and static code that together allowed to generate the right internal types corresponding to the right runtime types.
And that's the point: you don't always need "object orientation". In fact, most of the time you don't need it at all, you need to define some types and use them directly as different part of some kind of abstract engine (composition).
You don't always need generic code, aka templates. You need it sometimes to generalize a function to apply to several unrelated types. When they are related you can use their base class instead and not need templates.
They have different advantages and completely different costs so they are good to combine to solve complex problems.
STL is a good example of a problem where most of it is about providding types (containers) and functions (algorithms) that are related to a given type instead of a hierarchy of runtime objects.
In the standard library, streams are made in a way that is typical to object orientation: it is a hierarchy of stream classes that does different things in a way that allow defining a sub stream class that combine different behaviours/capacities.
There, object orientation is useful, even if some people would prefer it to be more like the STL (I'm not a specialist on the subject).
So, just think of them as very different tools, as a screwdriver and a hammer. C++ don't let you think with only one tool in mind.