Alternatives to the singleton pattern

I have read different opinions about the singleton pattern.
Some maintain that it should be avoided at all costs and others
that it can be be useful in certain situations.

One situation in which I use singletons is when I need a factory
(let's say an object f of type F) to create objects of a certain class A.
The factory is created once using some configuration parameters and then
is used each time an object of type A is instantiated. So every part of
the code that wants to instantiate A fetches the singleton f and create
the new instance, e.g.

F& f                   = F::instance();
boost::shared_ptr<A> a = f.createA();

So the general my scenario is that

1. I need only one instance of a class either for optimization reasons (I do not need multiple factory objects) or for sharing common state (e.g. the factory knows how many instances of A it can still create)
2. I need a way to have access to this instance f of F in different places of the code.

I am not interested in the discussion whether this pattern is good or bad,
but assuming I want to avoid using a singleton, what other pattern can I use?

The ideas I had were (1) to get the factory object from a registry or
(2) to create the factory at some point during program start up and then
pass the factory around as a parameter.

In solution (1), the registry itself is a singleton, so I have just shifted
the problem of not using a singleton from the factory to the registry.

In case (2) I need some initial source (object) from which the factory object
comes so I am afraid that I would again fall back to another singleton
(the object that provides my factory instance).
By following back this chain of singletons I can maybe reduce the problem
to one singleton (the whole application) by which all other singletons
are directly or indirectly managed.

Would this last option (using one initial singleton that creates all other
unique objects and injects all other singletons at the right
places) be an acceptable solution?
Is this the solution that is implicitly suggested when one advises not to
use singletons, or what are other solutions, e.g. in
the example illustrated above?

EDIT

Since I think the point of my question has been misunderstood by some,
here is some more information. As explained e.g. here, the word
singleton can indicate (a) a class with a single instance object and
(b) a design pattern used to create and access such an object.

To make things clearer let us use the term unique object for (a) and
singleton pattern for (b). So, I know what the singleton pattern
and dependency injection are (BTW, lately I've been using DI heavily
to remove instances of the singleton pattern from some code I am working on).

My point is that unless the whole object graph is instantiated from
a single object living on the stack of the main method, there will always be
the need to access some unique objects through the singleton pattern.

My question is whether having the complete object graph creation and
wiring depend on the main method (e.g. through some powerful DI framework
that does not use the pattern itself) is the only
singleton-pattern free solution.