GLM: Can't compile anymore - c++

Does anybody use this library anymore?
Worked great for me last year but now my code isn't compiling:
(on MinGW with GCC 4.6.1):
In file included from ../include/glm/./core/func_packing.hpp:190:0,
from ../include/glm/glm.hpp:103,
from SmoothRenderer.cpp:11:
../include/glm/./core/func_packing.inl: In function 'glm::detail::uint32 glm::packUnorm4x8(const glm::detail::tvec4<float>&)':
../include/glm/./core/func_packing.inl:84:17: error: expected primary-expression before '(' token
../include/glm/./core/func_packing.inl:84:17: error: expected primary-expression before ')' token
../include/glm/./core/func_packing.inl:84:17: error: expected ';' before 'round'
../include/glm/./core/func_packing.inl:85:26: error: 'D' was not declared in this scope
../include/glm/./core/func_packing.inl: In function 'glm::detail::tvec4<float> glm::unpackUnorm4x8(const uint32&)':
../include/glm/./core/func_packing.inl:94:38: warning: statement has no effect [-Wunused-value]
../include/glm/./core/func_packing.inl:99:4: error: 'D' was not declared in this scope
This is with newest version 0.9.4.3.
Similar problems on my Mac with latest clang:
In file included from SmoothRenderer.cpp:10:
In file included from ../include/glm/glm.hpp:103:
In file included from ../include/glm/./core/func_packing.hpp:190:
../include/glm/core/func_packing.inl:84:33: error: expected '(' for function-style cast or type construction
detail::uint8 D((detail::uint8)round(clamp(v.w, 0.0f, 1.0f) * 255.0f));
~~~~~~~~~~~~~^
./util.h:330:15: note: expanded from macro 'D'
# define D(x) x
^
In file included from SmoothRenderer.cpp:10:
In file included from ../include/glm/glm.hpp:103:
In file included from ../include/glm/./core/func_packing.hpp:190:
../include/glm/core/func_packing.inl:85:26: error: use of undeclared identifier 'D'
return detail::uint32((D << 24) | (C << 16) | (B << 8) | A);
^
../include/glm/core/func_packing.inl:99:4: error: use of undeclared identifier 'D'
D * 1.0f / 255.0f);
^
../include/glm/core/func_packing.inl:94:30: warning: expression result unused [-Wunused-value]
detail::uint32 D((p >> 24) & Mask8);
~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~
./util.h:330:15: note: expanded from macro 'D'
# define D(x) x
^
In file included from SmoothRenderer.cpp:10:
In file included from ../include/glm/glm.hpp:108:
In file included from ../include/glm/./core/func_noise.hpp:85:
../include/glm/core/func_noise.inl:125:33: error: too many arguments provided to function-like macro invocation
detail::tvec4<T> const D(0.0, 0.5, 1.0, 2.0);
^
../include/glm/core/func_noise.inl:125:27: error: expected ';' at end of declaration
detail::tvec4<T> const D(0.0, 0.5, 1.0, 2.0);
^
;
This is a header-only library. Things like this shouldn't be happening...
I am only using this for some 4x4 matrix multiplication and inversion. Since the rest of my app uses LAPACK extensively there is nothing i really need that glm does. But I hate when my code which I try to make very portable randomly breaks like this.

Yeah it turned out to be an issue with the D macro. Damn it, answering my question 4 minutes after asking it. That's the beauty of explaining a problem. Half the time that's enough.
This is one more reason to avoid using the preprocessor. Mad errors. Though, to its credit, clang was nice enough to not only mention that something seemed iffy with a macro defined elsewhere, it even copied it in there to show me.

Related

Using unordered_map on my g++ (5.1.0) compiler in command prompt shows error

I have recently downloaded MinGW into my computer but on using certain containers and iterators like unordered_map and auto it shows an unexpected error.
my code is as follows :
#include <bits/stdc++.h>
#include<unordered_map>
using namespace std;
int main()
{
unordered_map<string, int> umap;
umap["GeeksforGeeks"] = 10;
umap["Practice"] = 20;
umap["Contribute"] = 30;
for (auto x : umap)
cout << x.first << " " << x.second << endl;
return 0;
}
it gives the following error :
C:\Users\naima\Documents\cpp>g++ -o try2 try2.cpp
In file included from C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/unordered_map:35:0,
from try2.cpp:2:
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
try2.cpp: In function 'int main()':
try2.cpp:9:5: error: 'unordered_map' was not declared in this scope
unordered_map<string, int> umap;
^
try2.cpp:9:25: error: expected primary-expression before ',' token
unordered_map<string, int> umap;
^
try2.cpp:9:27: error: expected primary-expression before 'int'
unordered_map<string, int> umap;
^
try2.cpp:11:5: error: 'umap' was not declared in this scope
umap["GeeksforGeeks"] = 10;
^
try2.cpp:15:15: error: 'x' does not name a type
for (auto x : umap)
^
try2.cpp:19:5: error: expected ';' before 'return'
return 0;
^
try2.cpp:19:5: error: expected primary-expression before 'return'
try2.cpp:19:5: error: expected ';' before 'return'
try2.cpp:19:5: error: expected primary-expression before 'return'
try2.cpp:19:5: error: expected ')' before 'return'
The compiler told you exactly what was wrong. It usually will.
This file requires compiler and library support for the ISO C++ 2011 standard. This
support is currently experimental, and must be enabled with the -std=c++11 or
-std=gnu++11 compiler options.
You just have to compile with the proper flag, -std=c++11. I don't know if you are version-matching against what graders use or what, but there are very few good reasons to be on a minGW compiler where support for an 8 year old standard is still considered experimental.
You can see that it works as expected here: https://godbolt.org/z/JQxL00
If you remove the -std=c++11 flag, it will fail to compile and give you the same error message.
You might also notice that I altered the includes to only include what I use. This results in a much faster compile time, smaller executable, and an easier to understand piece of code (Since it is plain to see what standard features are being used). You also avoid polluting your namespace.

Veins 4.7 Omnet++ 5.3 build error in windows 7

I am new to vein and omnet++. I followed this tutorial http://veins.car2x.org/tutorial/ everything works up to step 3, for some reason veins 4.7 doesn't build in omnet++ 5 (IDE) and generates the following errors.
veins/modules/utility/TimerManager.cc
In file included from veins/modules/utility/TimerManager.cc:20:
.\veins/modules/utility/TimerManager.h:137:26: error: expected identifier
enum class StartMode { RELATIVE, ABSOLUTE, IMMEDIATE };
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1434:18: note: expanded from macro 'RELATIVE'
#define RELATIVE 2
^
In file included from veins/modules/utility/TimerManager.cc:20:
.\veins/modules/utility/TimerManager.h:137:36: error: expected identifier
enum class StartMode { RELATIVE, ABSOLUTE, IMMEDIATE };
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1433:18: note: expanded from macro 'ABSOLUTE'
#define ABSOLUTE 1
^
In file included from veins/modules/utility/TimerManager.cc:20:
.\veins/modules/utility/TimerManager.h:138:24: error: expected identifier
enum class EndMode { RELATIVE, ABSOLUTE, REPITITION, OPEN };
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1434:18: note: expanded from macro 'RELATIVE'
#define RELATIVE 2
^
In file included from veins/modules/utility/TimerManager.cc:20:
.\veins/modules/utility/TimerManager.h:138:34: error: expected identifier
enum class EndMode { RELATIVE, ABSOLUTE, REPITITION, OPEN };
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1433:18: note: expanded from macro 'ABSOLUTE'
#define ABSOLUTE 1
^
veins/modules/utility/TimerManager.cc:42:28: error: expected unqualified-id
start_mode_ = StartMode::RELATIVE;
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1434:18: note: expanded from macro 'RELATIVE'
#define RELATIVE 2
^
veins/modules/utility/TimerManager.cc:48:28: error: expected unqualified-id
start_mode_ = StartMode::ABSOLUTE;
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1433:18: note: expanded from macro 'ABSOLUTE'
#define ABSOLUTE 1
^
veins/modules/utility/TimerManager.cc:54:24: error: expected unqualified-id
end_mode_ = EndMode::RELATIVE;
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1434:18: note: expanded from macro 'RELATIVE'
#define RELATIVE 2
^
veins/modules/utility/TimerManager.cc:60:24: error: expected unqualified-id
end_mode_ = EndMode::ABSOLUTE;
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1433:18: note: expanded from macro 'ABSOLUTE'
#define ABSOLUTE 1
^
veins/modules/utility/TimerManager.cc:86:19: error: expected unqualified-id
case StartMode::RELATIVE:
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1434:18: note: expanded from macro 'RELATIVE'
#define RELATIVE 2
^
veins/modules/utility/TimerManager.cc:88:30: error: expected unqualified-id
start_mode_ = StartMode::ABSOLUTE;
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1433:18: note: expanded from macro 'ABSOLUTE'
#define ABSOLUTE 1
^
veins/modules/utility/TimerManager.cc:90:19: error: expected unqualified-id
case StartMode::ABSOLUTE:
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1433:18: note: expanded from macro 'ABSOLUTE'
#define ABSOLUTE 1
^
veins/modules/utility/TimerManager.cc:98:17: error: expected unqualified-id
case EndMode::RELATIVE:
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1434:18: note: expanded from macro 'RELATIVE'
#define RELATIVE 2
^
veins/modules/utility/TimerManager.cc:100:26: error: expected unqualified-id
end_mode_ = EndMode::ABSOLUTE;
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1433:18: note: expanded from macro 'ABSOLUTE'
#define ABSOLUTE 1
^
veins/modules/utility/TimerManager.cc:102:17: error: expected unqualified-id
case EndMode::ABSOLUTE:
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1433:18: note: expanded from macro 'ABSOLUTE'
#define ABSOLUTE 1
^
veins/modules/utility/TimerManager.cc:106:26: error: expected unqualified-id
end_mode_ = EndMode::ABSOLUTE;
^
C:\Users\Abu\src\omnetpp-5.3\tools\win64\mingw64\x86_64-w64-mingw32\include\wingdi.h:1433:18: note: expanded from macro 'ABSOLUTE'
#define ABSOLUTE 1
^
15 errors generated.
make[1]: *** [Makefile:205: ../out/clang-debug/src/veins/modules/utility/TimerManager.o] Error 1
make[1]: Leaving directory '/c/Users/Abu/src/veins-4.7/src'
make: *** [Makefile:12: all] Error 2
I am also using sumo_win64_0.32.0. I am not sure what causes these errors.
Any help is greatly appreciated.
The issue has been fixed in this pull request and a new minor revision of Veins (i.e. Veins 4.7.1) has been released. Please download the new version to get the fix and also some additional improvements.
I just encountered that error as well and here is what happens:
The compiler cannot resolve the enum class definitions in TimerManager.h as there is a name ambiguity with the macros RELATIVE and ABSOLUTE within wingdi.h
enum class StartMode { RELATIVE, ABSOLUTE, IMMEDIATE };
enum class EndMode { RELATIVE, ABSOLUTE, REPITITION, OPEN };
Quick fix is to rename the occurrences in TimerManager.h and TimerManager.cc to something else. E.g. Replace all occurrences of RELATIVE with RELATIVEINS and ABSOLUTE with ABSOLUTEVEINS etc... (or whatever you like). Worked fine for me with 4.7 and OMNet++ 5.2.1.
A patch is required to make Veins 4.7 compile with OMNeT++ 5.3 for Windows. The cleanest way may be something like on https://pastebin.com/ymzqMpEF
- enum class StartMode { RELATIVE, ABSOLUTE, IMMEDIATE }
+ enum class StartMode { relative, absolute, immediate }
that is, renaming the all-uppercase enum class constants to lower case ones (something recommended by many coding styles as well).

namespace std and LLVM PassManagerInternal.h file

I'm exploring compiler writing with Flex, Bison and LLVM (latest versions of all) using this example: http://gnuu.org/2009/09/18/writing-your-own-toy-compiler/
Github source is on the last page of that link. I can't get it to compile and any help would be appreciated.
Unfortunately for me, the solution is non-obvious.
Here are the errors:
In file included from codegen.cpp:2:
In file included from ./codegen.h:8:
In file included from /usr/local/Cellar/llvm/3.8.1/include/llvm/IR/PassManager.h:46:
/usr/local/Cellar/llvm/3.8.1/include/llvm/IR/PassManagerInternal.h:298:12: error: use of undeclared identifier 'make_unique'
return make_unique<ResultModelT>(Pass.run(IR, AM));
^
/usr/local/Cellar/llvm/3.8.1/include/llvm/IR/PassManagerInternal.h:298:24: error: unexpected type name 'ResultModelT': expected expression
return make_unique<ResultModelT>(Pass.run(IR, AM));
^
/usr/local/Cellar/llvm/3.8.1/include/llvm/IR/PassManagerInternal.h:336:12: error: use of undeclared identifier 'make_unique'
return make_unique<ResultModelT>(Pass.run(IR));
^
/usr/local/Cellar/llvm/3.8.1/include/llvm/IR/PassManagerInternal.h:336:24: error: unexpected type name 'ResultModelT': expected expression
return make_unique<ResultModelT>(Pass.run(IR));
^
codegen.cpp:36:24: error: no matching conversion for functional-style cast from 'unique_ptr<llvm::Module>' to 'llvm::EngineBuilder'
ExecutionEngine *ee = EngineBuilder( unique_ptr<Module>(module) ).create();
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/anaconda/include/llvm/ExecutionEngine/ExecutionEngine.h:493:7: note: candidate constructor (the implicit move constructor) not viable: no known conversion
from 'unique_ptr<llvm::Module>' to 'llvm::EngineBuilder' for 1st argument
class EngineBuilder {
^
/anaconda/include/llvm/ExecutionEngine/ExecutionEngine.h:493:7: note: candidate constructor (the implicit copy constructor) not viable: no known conversion
from 'unique_ptr<llvm::Module>' to 'const llvm::EngineBuilder' for 1st argument
/anaconda/include/llvm/ExecutionEngine/ExecutionEngine.h:525:3: note: candidate constructor not viable: no known conversion from 'unique_ptr<llvm::Module>'
to 'llvm::Module *' for 1st argument
EngineBuilder(Module *m) : M(m) {
^
codegen.cpp:131:49: warning: expression with side effects will be evaluated despite being used as an operand to 'typeid'
[-Wpotentially-evaluated-expression]
std::cout << "Generating code for " << typeid(**it).name() << endl;
^
In file included from codegen.cpp:2:
In file included from ./codegen.h:8:
/usr/local/Cellar/llvm/3.8.1/include/llvm/IR/PassManager.h:207:22: error: no member named 'getName' in 'llvm::Module'
<< IR.getName() << "\n";
~~ ^
codegen.cpp:30:5: note: in instantiation of member function 'llvm::PassManager<llvm::Module>::run' requested here
pm.run(*module);
^
In file included from codegen.cpp:2:
In file included from ./codegen.h:8:
/usr/local/Cellar/llvm/3.8.1/include/llvm/IR/PassManager.h:517:20: error: no member named 'getName' in 'llvm::Module'
<< IR.getName() << "\n";
~~ ^
/usr/local/Cellar/llvm/3.8.1/include/llvm/IR/PassManager.h:372:28: note: in instantiation of member function
'llvm::AnalysisManager<llvm::Module>::invalidateImpl' requested here
return derived_this()->invalidateImpl(IR, std::move(PA));
^
/usr/local/Cellar/llvm/3.8.1/include/llvm/IR/PassManager.h:217:22: note: in instantiation of member function
'llvm::detail::AnalysisManagerBase<llvm::AnalysisManager<llvm::Module>, llvm::Module>::invalidate' requested here
PassPA = AM->invalidate(IR, std::move(PassPA));
^
codegen.cpp:30:5: note: in instantiation of member function 'llvm::PassManager<llvm::Module>::run' requested here
pm.run(*module);
^
Well, there is llvm::make_unique in include/llvm/ADT/STLExtras.h. You have not stated if you are writing your own code based on llvm source or compiling llvm or what but I assume llvm::make_unique is there exactly for that reason to fill the missing pieces of C++11.
Moreover, looking at the tutorials it seems that llvm::make_unique is explicitly used everywhere.
Update
So I successfully build the given example against LLVM 3.9.0 from svn. I had to change and fix all the calls to getGlobalContext() since that is gone in LLVM 3.9.0, but I did not encounter any make_unique related issues. However the example itself is a bit broken. codegen.h is missing an include guard, codegen.cpp is missing an include to #include "llvm/IR/LLVMContext.h", even if it wants to use the old getGlobalContext() method. I did this on Windows with MSVC 2015, can you specify your environment and compiler so that I can try the same?

#define causes an "expected primary-expression" error

#define N 10;
int main()
{
int x;
for (int i=0; i<N; i++)
x = i;
return 0;
}
Result of compiling this in g++:
test-define.cpp: In function ‘int main()’:
test-define.cpp:7:22: error: expected primary-expression before ‘;’ token
test-define.cpp:7:22: error: expected ‘)’ before ‘;’ token
test-define.cpp:7:24: error: name lookup of ‘i’ changed for ISO ‘for’ scoping [-fpermissive]
test-define.cpp:7:24: note: (if you use ‘-fpermissive’ G++ will accept your code)
test-define.cpp:7:27: error: expected ‘;’ before ‘)’ token
But it compiles fine when I change line 7 to for (int i=0; i<10; i++).
Why is this and how can I use the #define directive to accomplish what I want?
Remove the semicolon - you will be good - the semicolon is included in the substitution
Sometimes it is useful to get the compiler to run the preprocessor only. With gcc/g++ you can do something like
gcc -E file.c > result.txt
This will show you how the macro expanded (hint start at the end of the file and work up)
I recommend replacing the macro with a constant:
const int N = 10;
It's best to avoid macros when you can. Macros don't have any scope. They are a global text substitution. The compiler never sees them, so if you use a debugger it won't know about them. There are probably other reasons not to use them that I'm forgetting.

MYSQL headers conflict with STL <algorithm> in C++

// File test.cpp
#include <my_global.h>
#include <algorithm>
int main()
{
return 0;
}
Compiled with: g++ -c -I /usr/local/mysql/include/mysql/ test.cpp, where /usr/local/mysql is the mysql install directory.Then the compiler report the following errors:
In file included from /usr/include/c++/4.4/algorithm:61,
from test.cpp:3:
/usr/include/c++/4.4/bits/stl_algobase.h:232:56: error: macro "min" passed 3 arguments, but takes just 2
/usr/include/c++/4.4/bits/stl_algobase.h:253:56: error: macro "max" passed 3 arguments, but takes just 2
In file included from /usr/include/c++/4.4/bits/stl_algo.h:61,
from /usr/include/c++/4.4/algorithm:62,
from test.cpp:3:
/usr/include/c++/4.4/bits/algorithmfwd.h:353:41: error: macro "max" passed 3 arguments, but takes just 2
/usr/include/c++/4.4/bits/algorithmfwd.h:364:41: error: macro "min" passed 3 arguments, but takes just 2
In file included from /usr/include/c++/4.4/algorithm:61,
from test.cpp:3:
/usr/include/c++/4.4/bits/stl_algobase.h:186: error: expected unqualified-id before ‘const’
/usr/include/c++/4.4/bits/stl_algobase.h:186: error: expected ‘)’ before ‘const’
/usr/include/c++/4.4/bits/stl_algobase.h:186: error: expected ‘)’ before ‘const’
/usr/include/c++/4.4/bits/stl_algobase.h:186: error: expected initializer before ‘const’
/usr/include/c++/4.4/bits/stl_algobase.h:209: error: expected unqualified-id before ‘const’
/usr/include/c++/4.4/bits/stl_algobase.h:209: error: expected ‘)’ before ‘const’
/usr/include/c++/4.4/bits/stl_algobase.h:209: error: expected ‘)’ before ‘const’
/usr/include/c++/4.4/bits/stl_algobase.h:209: error: expected initializer before ‘const’
/usr/include/c++/4.4/bits/stl_algobase.h:232: error: ‘std::min’ declared as an ‘inline’ variable
/usr/include/c++/4.4/bits/stl_algobase.h:232: error: template declaration of ‘const _Tp& std::min’
/usr/include/c++/4.4/bits/stl_algobase.h:235: error: expected primary-expression before ‘if’
/usr/include/c++/4.4/bits/stl_algobase.h:235: error: expected ‘}’ before ‘if’
/usr/include/c++/4.4/bits/stl_algobase.h:237: error: expected unqualified-id before ‘return’
/usr/include/c++/4.4/bits/stl_algobase.h:253: error: ‘max’ declared as an ‘inline’ variable
/usr/include/c++/4.4/bits/stl_algobase.h:253: error: template declaration of ‘const _Tp& max’
/usr/include/c++/4.4/bits/stl_algobase.h:256: error: expected primary-expression before ‘if’
/usr/include/c++/4.4/bits/stl_algobase.h:256: error: expected ‘}’ before ‘if’
/usr/include/c++/4.4/bits/stl_algobase.h:258: error: expected unqualified-id before ‘return’
/usr/include/c++/4.4/bits/stl_algobase.h:259: error: expected declaration before ‘}’ token
I think that there's some name conflict between my_global.h and algorithm, so I wrap my_global.h in a namespace:
// File test.cpp
namespace MYSQL_NAMESPACE {
#include <my_global.h>
}
#include <algorithm>
int main()
{
return 0;
}
But it doesn't help, the compiler still report the same errors. Then I change the include order as following:
// File test.cpp
#include <algorithm>
#include <my_global.h>
int main()
{
return 0;
}
Every thing goes well now.
Does Anybody Really Know What The Problem It Is?
TKS!
It seems that the mysql header defines a macro min.
#if !defined(max)
#define max(a, b) ((a) > (b) ? (a) : (b))
#define min(a, b) ((a) < (b) ? (a) : (b))
#endif
This has been reported to MySQL as bug 28184. The bug is marked as closed, so try updating to the newest version. According to the bug page it should be fixed in version 5.1.23, version 6.0.4 and newer versions.
Apparently the namespace trick does not work because min/max are macros and the preprocessor does not look at namespace scope.
This might fix the problem:
#include <my_global.h>
#undef min
#undef max
#include <algorithm>
The whole thing looks horrible though :)
It looks like my_global.h defines some name used by algorithm as a preprocessor macro, causing compilation to fail. With the ordering that works, you won't be able to use whatever it is that my_global.h clobbers, but your code will at least compile unless you need that feature. Since preprocessor macros are not namespaced, the namespace wrapping will not help, as you have observed.
Therefore, it sounds like my_global.h is broken, but if everything works just use the include order that works and go with it. That's my preferred include order anyway - standard library headers first, followed by external library headers, followed by internal headers.