Traditionally, global variables are declared in a header, and defined in a source file. Other source files only need to know how it is declared to use it (i.e. its type and its name). As long as the variable is defined somewhere in a source file, the linker will be able to find it and appropriately link all the references in other source files to the definition.

Somewhere in your header, you would declare a global variable like this:

extern int GlobalInt;

The extern part tells the compiler that this is just a declaration that an object of type int identified by GlobalInt exists. It may be defined later or it may not (it is not the compiler's responsibility to ensure it exists, that is the linker's job). It is similar to a function prototype in this regard.

In one of your source files, you define the GlobalInt integer:

int GlobalInt = 4;

Now, each file that includes the header will have access to GlobalInt, because the header says it exists, so the compiler is happy, and the linker will see it in one of your source files, so it too will be happy. Just don't define it twice!

However

You should consider whether or not this approach is useful. Global variables get messy for a number of reasons (trying to find out exactly where it is defined or declared, threading issues), there is usually not a need for global variables. You should perhaps consider using a singleton approach.

We declare our globals as extern in a header file, in your case: global_obj.h, and the actual global variable in a source file: global_obj.cpp. In separate source files we #include "global_obj.h" to have access to them.

It should look like this:

global_obj.cpp

Class obj;

global_obj.h

extern Class obj;

main.cpp

#include "global_obj.h"

Try to declare the variable globally (outside of the function) use the function to change the global variable.

Variables declared inside of a function are only accessible in that function; they are called local variables as they are local to the function in which they are declared.

The main() function cannot access the local variables of another function.

Globally declared variables are visible everywhere.

Yes, you can declare a global variable of any type, class or not.

No, you can't then "call" the constructor again inside a function to initialize it. You can however use the copy assignment operator to do it:

Foo foo;

int main()
{
    foo = Foo(1, 3);
}

Or you can have a "setter" function that is used to set or reinitialize the object.

By the way, and depending on the data in the class, you might want to read about the rule of three.

Don't define the object instance within the header file. Provide a declaration there and define the object in a single cpp file. For instance,

CoreEnvironment.h

class CoreEnvironment
{
    NetHandler* m_NET;
    NetPoint* Server;
    PhysicsHandler* m_Physics;
    irr::IrrlichtDevice* Device;
    irr::ITimer* Timer;

public:
    CoreEnvironment();
    ~CoreEnvironment();

    bool RunDevice();
    void Update();
};

extern CoreEnvironment CoreEnv;

CoreEnvironment.cpp

#include "CoreEnvironment.h"

CoreEnvironment CoreEnv;

And if there are only two other classes that require access to the CoreEnv object, maybe you should rethink the need for the global instance. Instead something like this might suffice.

int main()
{
    CoreEnvirnment CoreEnv;
    ActorHandler actor(CoreEnv); 
    WorldHandler world(CoreEnv);

    // do stuff with actor and world
}

where the constructors of ActorHandler and WorldHandler take (maybe const) references to CoreEnvironment.

So, you have to decide between a singleton and a bunch of free functions in a namespace, with some dedicated global state either way?

First, why do you want a singleton?

If it is just to ensure they share the state, consider extracting it into namespace-level TU-internal variables, and make any functions you want static. No need to muck around with singletons, which are ill regarded due to blatant over- and mis-use, aside from mis-implementation.

Next, why a class at all?

This is not Java, you can have free functions and global state outside classes, perfectly hidden from the outside unless external linkage is requested. It has the advantage of easier extensibility, and unless you need to provide a specific interface (for static injection with templates or dynamic injection with inheritance), there is no downside.

This is actually the preferred way, absent reason to do otherwise.