There is no polymorphism achieved with overloading. Your second citation is a false statement (source, please!). First one is true.
This is not too hard to validate.
I would explain polymorphism on the level you would understand but it would take a couple of pages of text and may require your feedback and answering further questions.
Let's do the following: first, let's close an issue with overloading. It's quite simple. If you rename all your overloaded names to make them unique, it will not change your code at all. In other words, names do not matter as soon as a compiler can resolve methods by the way they are called without ambiguity. Sometimes it is not possible to say which overloaded method is implied, then compilation shows an error. There is nothing polymorphic about all that.
See also: http://en.wikipedia.org/wiki/Method_overloading
], pay attention: there is not mentions of polymorphism in this article (naturally).
For the next step. To understand polymorphism you need to understand 4 things:
1) Inheritance: http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)
2) Virtual methods: http://en.wikipedia.org/wiki/Virtual_method
], to have an idea of the internals (useful!) see also virtual method table: http://en.wikipedia.org/wiki/Virtual_method_table
3) Late binding: http://en.wikipedia.org/wiki/Late_binding
] (not detailed enough, see also references in this article)
4) Finally, polymorphism: http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
Please don't afraid of too many articles. They provide pretty short conceptual explanation and are good to read (and not to hard to understand). Also, good thing they explain ideas on several languages, so, if you familiar with some of them it may help.
Now, a short answer on "What is 'that' resolved at runtime ? (overriding)".
After some thinking: overriding itself is done during compile time as well: a virtual function in two different classes (relative throw inheritance) is called indirectly, through Virtual Method Table (VMT).
A caller may work with a variable which is known during compile time as a variable of some parent class, but during run time the actual class instance is one of derived class (which is fine due to inheritance). If not VMT (not virtual function), the called method would be the one of the compile-time class, but due to VMT a virtual method called during run-time will be the one of actual run-time reference.
So, while all the methods (virtual or not) are known during compile time, which exactly is called are known only run-time -- late binding
. For a final note: planning object-oriented classes needs understanding and planning. Formally making methods virtual per se may introduce no late binding or polymorphism. Again, I recommend reading; see the references below.