While there are certainly cases where doing dependency injection for a logger make sense, most frameworks and utilities I've worked with do not do this.
I probably boils down to one aspect of a "global logger": It is NOT a variable.
Take, for example, the lowliest and simplest form of logging: Dumping info on stdout. (e.g., see Console.WriteLine in C#, or printfin C, or say in perl).
Here, you are clearly using a global "resource" (the output stream), but in the context you are using it, it is not really a variable. You might just interact with it using a global/static function call.
This often stays true, no matter what your logging "framework" is.
So, what you should not do, is just define a logging object as a "classic" global variable, that can be changed and/or configured from anywhere in your program.
What you can do, is define (or use something that defines) a clear interface on how to access one or more (global, or "global") logging resources in a way to log to them.