Singletons pattern generally refers to a single global instance. I.e. a static property in c#. Most of the problems with this is related to the "global" part, or more specifically, the combination of "global" and "mutable".
This question goes into the problems with singleton pattern in more details
So when you want to use DI for singleton behavior you must use a container, right?
No, you may still design your application with only one instance of a class, simply create it in the main method and inject it to all who needs it. This avoids most of the problems with SP, but you still have only one object. This works just the same as using a DI container, except you need to manage the creation yourself.
Also note that "singleton" lifetime with regards to DI containers means that there is one instance of a class per container, and that this instance lives at most as long as the container. This is different from SP since there is nothing "global" about this.
So at the end the container is just managin the single stuff for you, right?
No, you can still use the container to create objects with shorter lifetimes than the container. I might for example have a logging object registered as a singleton, but resolve multiple instances of a class that depends on this logger.
So DI is not something we should oppose to SP. DI with container is something I can oppose to SP.
This seem opinion based, but from my point of view they are quite opposite. SP hides dependencies, DI makes them clearer. SP makes it more difficult to replace or mock dependencies, DI makes it trivial.
So at the end why I should not use SP by myself but trust a library to do it?
As previously mentioned, you do not need a library to use DI, even if it makes it easier. I would personally trust a library used by thousands more then I trust my own code.
What is the difference between DI using container with single scope and SP?
You avoid most of the issues with SP for a start.
As an example, consider a application that connects to a database, where the database connection is in a global singleton. This might work fine, but consider if the requirements change so that it should be possible to connect to multiple databases, each with a separate window or view. SP makes such a change almost impossible since every class that uses the database must now know which database to use.
If a DI container is used, this can be almost trivial, simply create another container object in the same way you created the first one, but with a different connection string. Only the code that directly deals with loading or selecting databases need to know there are several of them. Other objects do not need to change, because in the context of the DI container they live in, there is still only one database.