Q:

static declaration of m follows non-static declaration

I am trying a small example to know about the static external variable and its uses. The static variable is of local scope and the external variable is of global scope.
static5.c
#include<stdio.h>
#include "static5.h"
static int m = 25;
int main(){
 func(10);
 return 0;
}

static5.h
#include<stdio.h>
int func(val){
 extern int m;
 m = m + val;
 printf("\n value is : %d \n",m);
}

gcc static5.c static5.h
o/p :
static5.c:3: error: static declaration of m follows non-static declaration
static5.h:3: note: previous declaration of m was here

EDITED 
The correct program :
a.c:
#include<stdio.h>
#include "a1_1.h"
int main(){
 func(20);
 return 0;
}

a1.h:
static int i = 20;

a1_1.h:
#include "a1.h"
int func(val){
 extern int i;
 i = i + val;
 printf("\n i : %d \n",i);
}

This works fine perfectly fine. But this is compiled into a single compilation unit. Hence could able to access the static variable . Across the compilation unit we cannot use the static variable by using the extern variable.

A:

static has a very simple logic to it. If a variable is static, it means that it is a global variable, but it's scope is limited to where it is defined (i.e. only visible there). For example:

Outside a function: global variable but visible only within the file (actually, the compilation unit)
Inside a function: global variable but visible only within the function
(C++) Inside a class: global variable but visible only to the class

Now let's see what the C11 standard says regarding static and extern (emphasis mine):

6.2.2.3
If the declaration of a file scope identifier for an object or a function contains the storage-class specifier static, the identifier has internal linkage.
6.2.2.4
For an identifier declared with the storage-class specifier extern in a scope in which a prior declaration of that identifier is visible, if the prior declaration specifies internal or external linkage, the linkage of the identifier at the later declaration is the same as the linkage specified at the prior declaration. If no prior declaration is visible, or if the prior declaration specifies no linkage, then the identifier has external linkage.
6.2.2.7
If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined.

So the standard says that first, if you have:
static int m;
extern int m;

then the second declaration (with extern) would regard the first one and in the end m would still be static.
However, in any other case, if there are declarations with both internal and external linkage, the behavior is undefined. This actually leaves us with only one option:
extern int m;
static int m;

i.e., extern declaration before static declaration. gcc was nice enough to give you error in this case of undefined behavior.

A:

Remember this (quoting Eli Bendersky):

A static variable inside a function keeps its value between
  invocations. 
A static global variable or a function is "seen" only in
  the file it's declared in

In your code, static int m = 25; means that m's scope is limited only to that file, that is, it is only visible inside static5.c and nowhere else.
If you would like to make use of m outside of static5.c make sure to remove the keyword static from the declaration of the variable.
For a more canonical explanation, along with an example, see this answer by Eli Bendersky
EDIT: (according to Klas' recommendation) **The actual scope is a compilation unit, not the source file. The compilation unit is the way the file looks after the preprocessor step

A:

The problem is exactly as stated in the error message. m is declared a normal int but is later defined as a static int.
extern tells the compiler/linker to look for the variable in the global table of variables.
static (outside a functon) tells the compiler to exclude the variable from the global table of variables.
Do you see the conflict?
To fix the problem, either remove the static keyword from the definition or move the definition above the inclusion of static5.h.
It should be noted that the way you have designed your files is not considered best practice. Include files don't usually contain functions.

