I have a project where I first build gl3w.c with gcc and then my own OGLGraphics.cpp file with g++. Gcc successfully compiles gl3w.c but when g++ attempts to compile the file that includes gl3w.h I get these errors:
In file included from /mnt/hgfs/grace/src/grace-output/graphics/OGLGraphics.cpp:22:0:
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:69:8: error: ‘PFNGLDRAWARRAYSPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:70:8: error: ‘PFNGLDRAWELEMENTSPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:71:8: error: ‘PFNGLGETPOINTERVPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:72:8: error: ‘PFNGLPOLYGONOFFSETPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:73:8: error: ‘PFNGLCOPYTEXIMAGE1DPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:74:8: error: ‘PFNGLCOPYTEXIMAGE2DPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:75:8: error: ‘PFNGLCOPYTEXSUBIMAGE1DPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:76:8: error: ‘PFNGLCOPYTEXSUBIMAGE2DPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:77:8: error: ‘PFNGLTEXSUBIMAGE1DPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:78:8: error: ‘PFNGLTEXSUBIMAGE2DPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:79:8: error: ‘PFNGLBINDTEXTUREPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:80:8: error: ‘PFNGLDELETETEXTURESPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:81:8: error: ‘PFNGLGENTEXTURESPROC’ does not name a type
/mnt/hgfs/grace/src/grace-output/include/GL3/gl3w.h:82:8: error: ‘PFNGLISTEXTUREPROC’ does not name a type
I don't know why it works with a C file but not from C++?
Did you follow the procedure as outlined in GL3W's readme file? Specifically, the part about including gl3w.h first, before any OpenGL files.
Oh, and before window.h, which can include gl.h.
extern PFNGLDRAWARRAYSPROC gl3wDrawArrays; <—— unknown type name PFNGLDRAWARRAYSPROC
This error is caused by the inclusion of #include <OpenGL/gl.h> in your code such as GLTriangleBatch.h. If you substitute #include "GL/gl3w.h” instead, which is OpenGL 3/4 calls, then this will remove the error. I think that there is a conflict between different versions of OpenGL calls and this results in the unknown type error. I ran into this same problem myself when I was trying to port SuperBible 5 code into SB6.
Related
EDIT2: The problem was NOT a simple typographical error. I made a typo in the logs below, which I corrected, but the problem was still there.
EDIT: I mistakenly ran with gcc instead of g++, once, after attempting below. The problem was there before with g++ and it is there now.
I am currently on a MacOS High Sierra box. I recently moved a lot of files from a MacBook Air to this machine, including what I assume were all of Xcode's junk. Now, when I try to compile a very simple C++ program:
#include <iostream>
int main()
{
// VAR_DEC
int a = 4;
// VAR_MANIP
a = a*2;
// VAR_PRINT
std::cout << a << std::endl;
return 0;
}
I get the following ridiculous error:
jrfarah#Josephs-MBP: [config_file_script] $ g++ test.cpp -o test
In file included from test.cpp:1:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/iostream:38:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/ios:216:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/__locale:15:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/string:470:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/string_view:171:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/__string:56:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/algorithm:640:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/memory:629:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/typeinfo:61:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/exception:82:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/cstdlib:86:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/stdlib.h:94:
In file included from /usr/include/stdlib.h:65:
In file included from /usr/include/sys/wait.h:110:
/usr/include/sys/resource.h:196:2: error: unknown type name 'uint8_t'
uint8_t ri_uuid[16];
^
/usr/include/sys/resource.h:197:2: error: unknown type name 'uint64_t'
uint64_t ri_user_time;
^
/usr/include/sys/resource.h:198:2: error: unknown type name 'uint64_t'
uint64_t ri_system_time;
^
/usr/include/sys/resource.h:199:2: error: unknown type name 'uint64_t'
uint64_t ri_pkg_idle_wkups;
^
/usr/include/sys/resource.h:200:2: error: unknown type name 'uint64_t'
uint64_t ri_interrupt_wkups;
^
/usr/include/sys/resource.h:201:2: error: unknown type name 'uint64_t'
uint64_t ri_pageins;
^
/usr/include/sys/resource.h:202:2: error: unknown type name 'uint64_t'
uint64_t ri_wired_size;
^
/usr/include/sys/resource.h:203:2: error: unknown type name 'uint64_t'
uint64_t ri_resident_size;
^
/usr/include/sys/resource.h:204:2: error: unknown type name 'uint64_t'
uint64_t ri_phys_footprint;
^
/usr/include/sys/resource.h:205:2: error: unknown type name 'uint64_t'
uint64_t ri_proc_start_abstime;
^
/usr/include/sys/resource.h:206:2: error: unknown type name 'uint64_t'
uint64_t ri_proc_exit_abstime;
^
/usr/include/sys/resource.h:210:2: error: unknown type name 'uint8_t'
uint8_t ri_uuid[16];
^
/usr/include/sys/resource.h:211:2: error: unknown type name 'uint64_t'
uint64_t ri_user_time;
^
/usr/include/sys/resource.h:212:2: error: unknown type name 'uint64_t'
uint64_t ri_system_time;
^
/usr/include/sys/resource.h:213:2: error: unknown type name 'uint64_t'
uint64_t ri_pkg_idle_wkups;
^
/usr/include/sys/resource.h:214:2: error: unknown type name 'uint64_t'
uint64_t ri_interrupt_wkups;
^
/usr/include/sys/resource.h:215:2: error: unknown type name 'uint64_t'
uint64_t ri_pageins;
^
/usr/include/sys/resource.h:216:2: error: unknown type name 'uint64_t'
uint64_t ri_wired_size;
^
/usr/include/sys/resource.h:217:2: error: unknown type name 'uint64_t'
uint64_t ri_resident_size;
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
I've tried installing and reinstalling everything I could think of related to the problem, such as gcc, g++, cc, brew, Xcode, command-line-tools, etc. I've also tried all the suggestions on the following pages:
Unknown type name uint8_t?
Include search path on Mac OS X Yosemite 10.10.1
Cythonizing fails because of unknown type name 'uint64_t'
unknown type name 'uint8_t', MinGW
JT Bullitt's very comprehensive blog
and more, but those summarize it pretty well. None of the solutions have worked.
I think the last one has the most likely solution. (If you search for "unknown" on the page you'll see the fix.) According to the developer:
Fix: Remove /opt/local/include/** and /opt/local/lib/** from the "Header Search Paths" build settings. Replace them with much more specific paths to the desired include directories. In my particular case, this meant replacing them with /opt/local/include/glib-2.0 /opt/local/lib/glib-2.0/include /opt/local/include/. It's up and running again!
However, I didn't install Xcode, I only installed the command line developer tools. Therefore, I don't have an easy way to access the "Header Search Paths" build settings, and thus, I can't try out his solution.
I am looking for a solution to this problem, preferably one that doesn't require me installing the entire OS. Alternatively, if someone could kindly guide me through finding the build settings file, I would be very grateful.
Maybe you can try:
mv /usr/local/include /usr/local/include.old
then:
brew install llvm
It's fairly obvious that you borked your system GCC installation. Please note that GCC is a suite of compilers and that G++ is the C++ front-end. Package managers often have a separate package called gcc-g++, however, when compiling from source, you simply do --enable-languages=c,c++. Now if reinstalling XCode doesn't resolve the problem (you should've already done this, if "it takes up too much space" just remove it), then you can try compiling GCC from source. Adapted from the GNU wiki:
First, grab your desired GCC tar ball from here
Untar it with tar zxvf gcc*
cd gcc* then ./contrib/download_prerequisites
Do an out of source build: mkdir build && cd build
../gcc*/configure --prefix=$HOME/gcc-install --enable-languages=c,c++
make and make install
Now just add $HOME/gcc-install/bin to your path and you should be good to go.
I experienced this error during compilation of Perl-5.34.0 from source. An alternative solution that worked for me was setting the SDK environment variable:
export SDK=`xcrun --show-sdk-path`
Sometimes, you may need to set SDKROOT in the same way:
export SDKROOT=`xcrun --show-sdk-path`
Placing it into your ~/.profile file will (conveniently) make this setting permanent.
Something is wrong with my build setup. I'm getting this error:
Error: The module List is an alias for module ListLabels, which is missing
In the interactive top-level ListLabels exists, but not during compilation.
I tracked this error message to this line of code in the OCaml compiler:
https://github.com/ocaml/ocaml/blob/70d880a41a82aae1ebd428fd38100e8467f8535a/typing/typetexp.ml#L905
Turns out the reason is the following compiler flag:
-strict-deps Hide .cmi whose name is not explicitly referenced
I like to create a TUN/TAP interface out of a C++ program. I found a straight foward tutorial on the net at
http://backreference.org/2010/03/26/tuntap-interface-tutorial/.
The problem is, that I seem to have linking problems with with if.h and if_tun.h.
When I strip the tutorial to the minimal example below, only to open a slot, I get a number of errors.
Example:
#include <linux/if.h>
#include <linux/if_tun.h>
int main(void){
char *clonedev = "/dev/net/tun";
open(clonedev,O_RDWR);
return 0;
}
If think this should compile, yet I get the following errors:
/usr/include/linux/if.h:184:19: error: field 'ifru_addr' has incomplete type
/usr/include/linux/if.h:185:19: error: field 'ifru_dstaddr' has incomplete type
/usr/include/linux/if.h:186:19: error: field 'ifru_broadaddr' has incomplete type
/usr/include/linux/if.h:187:19: error: field 'ifru_netmask' has incomplete type
/usr/include/linux/if.h:188:20: error: field 'ifru_hwaddr' has incomplete type
tuntap.cpp: In function 'int main()':
tuntap.cpp:6:18: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
tuntap.cpp:7:15: error: 'O_RDWR' was not declared in this scope
tuntap.cpp:7:21: error: 'open' was not declared in this scope
I'm using GCC 4.7.2 (in this case, from the command line without any switches) on Fedora 18 with Linux 3.11.4.
What's wrong with my libraries?
Try a different include. Use ...
#include <net/if.h>
... instead of ...
#include <linux/if.h>
In addition, include another file.
#include <fcntl.h>
I am developing a program in C++ on Linux. The gcc version is 4.5.1 20100924. I want to use std::atomic_int in my program. I have included atomic header as below:
include <atomic>
When I compile the program I get below errors:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../include/c++/4.5.1/bits/atomic_base.h:87:0,
from /usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../include/c++/4.5.1/atomic:41,
from ../Source/Main.h:33:
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../include/c++/4.5.1/bits/atomicfwd_cxx.h:107:25: error: ‘char16_t’ was not declared in this scope
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../include/c++/4.5.1/bits/atomicfwd_cxx.h:107:33: error: template argument 1 is invalid
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../include/c++/4.5.1/bits/atomicfwd_cxx.h:107:53: error: invalid type in declaration before ‘;’ token
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../include/c++/4.5.1/bits/atomicfwd_cxx.h:110:25: error: ‘char32_t’ was not declared in this scope
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../include/c++/4.5.1/bits/atomicfwd_cxx.h:110:33: error: template argument 1 is invalid
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../include/c++/4.5.1/bits/atomicfwd_cxx.h:110:53: error: invalid type in declaration before ‘;’ token
If I include <cstdint>, I get the same errors. The headers uchar.h and cuchar.h are not there on my system. How can I resolve the compilation errors?
Thank you in advance.
EDITED:
I was wrong about that. just pass --std=c++0x to g++, and that would do it.
You seem to not have enabled C++11 support in your compiler or you use a compiler that has these new types not declared.
For char16_t and char32_t, you need no extra include.
g++ howto:
Type g++ --version. If it is at least 4.4, then it has support for new string literals. If not: You need a newer compiler version.
Then, make sure to pass --std=c++0x or --std=c++11 to the compiler.
I'm using a third party static library in my C++ project that has a dependency on libssl version 0.9.7a. Due to various reasons, the libssl version that my project used is 0.9.8e.
Everything was working fine, until the third party made a recent change to their static library. I wasn't able to successfully compile my application when it included this new version of the static library. The old version compiles fine.
I'm not very familiar with these library dependencies and their backwards compatibility. We were told that we must use the version suggested by the third party. I just want to know if that is really the reason. IMO, I guess it should be backwards compatible, shouldn't it?
Any direction with troubleshooting this issue is very much appreciated.
The following is the compilation error that I'm getting:
cc1plus: note: obsolete option -I- used, please use -iquote instead
In file included from /usr/include/openssl/e_os2.h:56,
from /usr/include/openssl/ssl.h:173,
from MyClass.cpp:28:
/usr/include/openssl/opensslconf.h:13:30: error: opensslconf-i386.h: No such file or directory
/usr/include/openssl/bn.h:288: error: expected ';' before '*' token
/usr/include/openssl/bn.h:304: error: 'BN_ULONG' does not name a type
/usr/include/openssl/bn.h:407: error: 'BN_ULONG' was not declared in this scope
/usr/include/openssl/bn.h:450: error: 'BN_ULONG' does not name a type
/usr/include/openssl/bn.h:451: error: 'BN_ULONG' does not name a type
/usr/include/openssl/bn.h:452: error: 'BN_ULONG' has not been declared
/usr/include/openssl/bn.h:453: error: 'BN_ULONG' has not been declared
/usr/include/openssl/bn.h:454: error: 'BN_ULONG' has not been declared
/usr/include/openssl/bn.h:455: error: 'BN_ULONG' has not been declared
/usr/include/openssl/bn.h:456: error: 'BN_ULONG' does not name a type
/usr/include/openssl/bn.h:471: error: 'BN_ULONG' has not been declared
/usr/include/openssl/bn.h:764: error: 'BN_ULONG' does not name a type
/usr/include/openssl/bn.h:765: error: 'BN_ULONG' does not name a type
/usr/include/openssl/bn.h:766: error: variable or field 'bn_sqr_words' declared void
/usr/include/openssl/bn.h:766: error: 'BN_ULONG' was not declared in this scope
/usr/include/openssl/bn.h:766: error: 'rp' was not declared in this scope
/usr/include/openssl/bn.h:766: error: expected primary-expression before 'const'
/usr/include/openssl/bn.h:766: error: expected primary-expression before 'int'
/usr/include/openssl/bn.h:767: error: 'BN_ULONG' does not name a type
/usr/include/openssl/bn.h:768: error: 'BN_ULONG' does not name a type
/usr/include/openssl/bn.h:769: error: 'BN_ULONG' does not name a type
/usr/include/openssl/ssl3.h:303: error: 'PQ_64BIT' does not name a type
/usr/include/openssl/pqueue.h:73: error: 'PQ_64BIT' does not name a type
/usr/include/openssl/pqueue.h:80: error: 'PQ_64BIT' was not declared in this scope
/usr/include/openssl/pqueue.h:80: error: expected primary-expression before 'void'
/usr/include/openssl/pqueue.h:89: error: 'PQ_64BIT' has not been declared
/usr/include/openssl/dtls1.h:92: error: 'PQ_64BIT' does not name a type
/usr/include/openssl/dtls1.h:94: error: 'PQ_64BIT' does not name a type
The error message says that there's no such file as opensslconf-i386.h, but it is indeed present.
Any idea what's going wrong?
Thanks for you time!
The C pre-processor is not finding the opensslconf-i386.h file - so you need to find out why that is failing. You've got a warning from the compiler about using an obsolete option (and it recommends a fix) - do it.
OK - you say the file is present: where is it, and what are the permissions on it? How is it included by opensslconf.h? How is that line different from any other OpenSSL headers that are included. What are the '-I' options you are using other than the deprecated '-I-'?
At this stage, I'd say you've got either a faulty installation or an odd-ball command line.
And the question title is ... not obviously related to the question body.
At the operational level, yes, the two interwork for most purposes.
At the compilation level, yes, the two are basically compatible (that which worked in 0.9.7a should work with 0.9.8e).
At the internals and configuration level, there will be small differences; there may be extra ciphers or modes supported by the more recent version, for example.