Have you tried the generic *nix build instructions in the README?

As far as I know the latest version can do solo mining just fine. If you wish to file a bug report, please include enough information about what you want to do and how you're trying to do it.

"Stratum requested work restart" is totally normal, and should happen every time a new block appears on the network.
"Stratum connection interrupted", on the other hand, is not normal. It indicates a network failure, which could be due to your Internet connection or to the remote server.

As I've already said, this could indeed be useful, but the changes required to implement it properly are nontrivial (cpuminer does not currently keep track of submitted shares). I don't have much free time in this period, but I will put this on my to-do list.

There was a Qt GUI that interfaced with cpuminer, and it worked quite well. The project is now abandoned, but its source code is still available under the MIT license for anybody to fork.
https://bitcointalk.org/index.php?topic=62414.0

OpenSSL is referenced nowhere in the source code of cpuminer. You must be trying to compile something else, probably a fork of it.

No.

Because xnonce2 is not an integer, but an array of bytes.

As stated in the comment, that line increments the extranonce2 field so that every time that new work is generated it is different. See the Stratum protocol specifications.

Please read the FAQ in the first post.

Google.

It is actually pretty easy to produce a collision if the difficulty is low enough: just start two miners of about the same speed and try to keep the getblocktemplate calls synchronized. That way the two miners will be working on the exact same headers (same timestamp, same merkle root hash).
Out of curiosity, I tried this just now on the Litecoin testnet, and I was able to obtain a double submission (one accepted, one rejected) within a few minutes.

The server implementation you are using is faulty. According to the specs, submitblock should never return a result of "true".
The result must be "null" when a submitted block is accepted, and that's why cpuminer considers any other result as a rejection. ("accepted: 0/1" means that you submitted 1 blocks, and 0 of them got accepted.)

It is certainly possible, but it would be a bit pointless in my opinion. If a server provides a getblocktemplate method but no submitblock method, then it is violating the official specifications.

Apparently your daemon does not implement the submitblock method, even though it is part of the non-optional sections of BIP 22.

As a matter of fact, I've mined several blocks on the Litecoin testnet, so I know that the GBT implementation of 2.4 is not (entirely) broken.

If that's all you need then you could simply grep the output stream or the file where you store the log.

I think the main problem with adding an API is that it would greatly complicate the code base. Luckily cpuminer starts up very quickly, so a wrapper script can usually do the job pretty well.

That's what tee is for. Or you could tail -f the file where the output is stored.

This could indeed be useful. I will think about it, but keep in mind that the changes required to implement this properly are nontrivial (cpuminer does not currently keep track of submitted shares).

Personally, I think cpuminer was never designed to be interactive... and I actually like it the way it is, because I value simplicity. But then again, this is probably a matter of personal taste, just like the old vi-vs-Emacs debate.

(By the way, I just learned that there's a name for the kind of user interface that cgminer sports: TUI, i.e. Textual User Interface.)

I see no difference between the log you just posted above and the one you posted before. The message "Stratum detected new block" was changed to "Stratum requested work restart" in version 2.4, as that's a more correct description of what is happening.
Neither of the two logs you've posted so far shows any accepted share.

Because your pool's server sent you new work and asked you to start working on it immediately.
This is usually normal and completely harmless. If you think that a work restart means that your past hashing is now "lost" then you are committing a fallacy, as there is no "progress" when you mine.

The hashing code hasn't changed since version 2.3.2, as you can see for yourself from the commit history. Any hash rate variation you might see is purely accidental.

I'm not sure what you mean by "logging", given that cpuminer has always produced a log.
Regarding APIs and integrated graphical interfaces, they will probably never happen, as I don't think they conform to the KISS philosophy.

No particular signature is included in the coinbase if you don't specify one. Just the block height as per BIP 34.

No, it is not possible.

This is not "ballast". It is something necessary, and actually very small when you consider the size of a block.
The same mechanism is used by poolservers to distribute different work to miners, and even by the old getwork method to ensure that every requested work be unique. And all the extra nonces have always ended up in the block chain.

The truth is, if your signature is short, your coinbases will be smaller than those produced by getwork. Thus, if you are concerned about block size, using a single-byte signature is definitely the best solution (assuming you don't have more than 256 miners).