Plugin activation hook in an abstract class

The best way to get around this problem is not creating that abstract class.

Never combine object creation with business logic in the same class. This is called a statically linked dependency and usually a flawed design, because you cannot change it on runtime (for tests or per hooks, for example). Avoid inheritance.

Separation of concerns and dependency injection will solve that.

Example

interface Plugin_Setup_Interface
{
    public function activate( $network_wide );
    public function deactivate( $network_wide );
}

class Plugin_Setup implements Plugin_Setup_Interface
{

    public function activate( $network_wide ) {}

    public function deactivate( $network_wide ) {}
}

class Plugin_Starter
{
    private $plugin_file="";

    private $setup = NULL;

    public function __construct(
                               $plugin_file,
        Plugin_Setup_Interface $setup = NULL
    )
    {
        $this->plugin_file = $plugin_file;
        $this->setup       = $setup;
    }

    public function init()
    {
        if ( ! is_null( $this->setup ) )
        {
            register_activation_hook(
                $this->plugin_file,
                array ( $this->setup, 'activate' )
            );

            register_deactivation_hook(
                $this->plugin_file,
                array ( $this->setup, 'deactivate' )
            );
        }
    }
}

// call your auto-loader, then …

$start = new Plugin_Starter( __FILE__, new Plugin_Setup() );
$start->init();

Now you can create specialized de/activation routines for every plugin and still reuse the starter class.