I've been trying to figure out an issue I've been having with cross-compiling C++ code on Linux for Windows. The code I'm trying to compile is:
#include <iostream>
int main(int argc, char** argv){
std::cout<<"Hello World!\n";
return 0;
}
I'm trying to compile for a 64 bit windows installation, and so I run:
x86_64-w64-mingw32-g++ main.cpp
but it produces the following errors:
In file included from /usr/include/sched.h:34:0,
from /usr/include/pthread.h:23,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/x86_64-w64-mingw32/bits/gthr-default.h:35,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/x86_64-w64-mingw32/bits/gthr.h:148,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/ext/atomicity.h:35,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/bits/ios_base.h:39,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/ios:42,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/ostream:38,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/iostream:39,
from main.cpp:1:
/usr/include/time.h:75:18: error: conflicting declaration ‘typedef __time_t time_t’
typedef __time_t time_t;
^
In file included from /usr/x86_64-w64-mingw32/include/stddef.h:7:0,
from /usr/lib/gcc/x86_64-w64-mingw32/4.9.2/include/stddef.h:1,
from /usr/include/wchar.h:51,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/cwchar:44,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/bits/postypes.h:40,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/iosfwd:40,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/ios:38,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/ostream:38,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/iostream:39,
from main.cpp:1:
/usr/x86_64-w64-mingw32/include/crtdefs.h:138:20: note: previous declaration as ‘typedef __time64_t time_t’
typedef __time64_t time_t;
^
In file included from /usr/x86_64-w64-mingw32/include/c++/4.9.2/cwctype:50:0,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/bits/locale_facets.h:39,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/bits/basic_ios.h:37,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/ios:44,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/ostream:38,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/iostream:39,
from main.cpp:1:
/usr/include/wctype.h:52:27: error: conflicting declaration ‘typedef long unsigned int wctype_t’
typedef unsigned long int wctype_t;
^
In file included from /usr/x86_64-w64-mingw32/include/stddef.h:7:0,
from /usr/lib/gcc/x86_64-w64-mingw32/4.9.2/include/stddef.h:1,
from /usr/include/wchar.h:51,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/cwchar:44,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/bits/postypes.h:40,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/iosfwd:40,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/ios:38,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/ostream:38,
from /usr/x86_64-w64-mingw32/include/c++/4.9.2/iostream:39,
from main.cpp:1:
/usr/x86_64-w64-mingw32/include/crtdefs.h:107:24: note: previous declaration as ‘typedef short unsigned int wctype_t’
typedef unsigned short wctype_t;
^
The error line:
/usr/include/time.h:75:18: error: conflicting declaration ‘typedef __time_t time_t’
typedef __time_t time_t;
suggests to me that mingw-w64 is using the linux libraries instead of the ones compiled for windows, but upon searching I cannot seem to figure out how to resolve this. I'm using Archlinux and the mingw-w64 package group from the official repository. I've tried reinstalling the mingw-w64 package group thinking that maybe the libraries were not compiled correctly but I'm still receiving the same errors.
To be clear, I am able to compile this code with:
g++ main.cpp
Any help or anything to point me in the right direction will be greatly appreciated. Thank you.
You appear to be allowing your mingw-w64 compiler to search the native linux-gnu compiler's header file tree. This is completely wrong. Those headers are for use exclusively when compiling native code; you must never allow a cross-compiler to see them. Each individual compiler, both native and cross, will have its own specific set of system headers; each should be allowed to see only those which belong to itself.
You also seem to be confused about the respective roles of libraries and headers. Libraries come into play only at link time; they play no part in the compiling process. Headers describe the features provided by the libraries; it is these descriptions which are used by the compiler. It is the linker which uses the libraries; the linker is a separate program, which is normally invoked by the compiler driver, after completion of the compilation process itself.
The issue was that there was an environment variable set that mingw-w64 was using to find the linux header files. Specifically, I had set CPLUS_INCLUDE_PATH in my .bashrc a while ago and had forgotten about it. This variable does not generally need to be set unless there is some special circumstance that requires it. I do not personally rely on it. I commented out the export and the compiler seems to be finding all the headers it needs now.
Related
I have strange situation here:
I am a working code base in Mac Os X Qt. I tried to compile on ubuntu same code with same libraries (opencv + dlib ) it give a buch of errors ?
drove me crazy all day :( any solution?
/usr/local/include/opencv2/dnn/dnn.hpp:314:17: error: reference to ‘int64’ is ambiguous
virtual int64 getFLOPS(const std::vector<MatShape> &inputs,
^~~~~
In file included from /usr/local/include/opencv2/core/cvdef.h:91:0,
from /usr/local/include/opencv2/core.hpp:52,
from /usr/local/include/opencv2/highgui.hpp:46,
from ../SFT-V2/worker.h:18,
from ../SFT-V2/widget.h:5,
from ../SFT-V2/main.cpp:1:
/usr/local/include/opencv2/core/hal/interface.h:61:20: note: candidates are: typedef int64_t int64
typedef int64_t int64;
typedef int64_t int64;
Most probably your definition of int64 is clashing with another definition of this type.
Sometimes in ubuntu, the compiler does not allow you to typedef the same thing twice even if the C++ standard allows you.
Reordering includes should solve the problem.
I removed first :
using namespace dlib from the cpp file which is alreayd its header not the error is gone.
But why its working on mac (clang) and not working on ubuntu (g++) ? drove me vrazy all the day to find the solution.
I'am working on a group project with ROS and C++ on Ubuntu 16.04. Everything is working fine until two weeks ago I got this error
message out of the blue:
In file included from /usr/include/c++/5/cstring:42:0,
from /usr/include/boost/math/special_functions/detail/fp_traits.hpp:23,
from /usr/include/boost/math/special_functions/fpclassify.hpp:20,
from /usr/include/boost/math/special_functions/round.hpp:16,
from /opt/ros/kinetic/include/ros/time.h:58,
from /opt/ros/kinetic/include/ros/ros.h:38,
from /home/benjamin/Documents/bob_ws/src/tutorial/hello_world/src/hello_world.cpp:1:
/usr/include/string.h: In function ‘size_t strlen(const char*)’:
/usr/include/string.h:395:6: error: ‘cout’ was not declared in this scope
cout << *__s;
^
/usr/include/string.h:395:6: note: suggested alternative:
In file included from /opt/ros/kinetic/include/ros/time.h:54:0,
from /opt/ros/kinetic/include/ros/ros.h:38,
from /home/benjamin/Documents/bob_ws/src/tutorial/hello_world/src/hello_world.cpp:1:
/usr/include/c++/5/iostream:61:18: note: ‘std::cout’
extern ostream cout; /// Linked to standard output
^
In file included from /usr/include/features.h:367:0,
from /usr/include/stdlib.h:24,
from /opt/ros/kinetic/include/ros/platform.h:53,
from /opt/ros/kinetic/include/ros/time.h:53,
from /opt/ros/kinetic/include/ros/ros.h:38,
from /home/benjamin/Documents/bob_ws/src/tutorial/hello_world/src/hello_world.cpp:1:
/usr/include/string.h:396:6: error: expected primary-expression before ‘)’ token
__THROW __attribute_pure__ __nonnull ((1));
As a newbie to C++ and ROS my first thought was that I messed up by installing / removing some packages. So I tried reinstalling the whole ros framework. Didn't work, so I wrote a little programs
which (I think) shows what my problem is. I cannot include <cstring>:
#include <cstring>
int main(int argc, char** argv)
{
return 0;
}
When compiling that with g++ -Wall a.cpp -o atest I got a 2500 row error message.
Now I think there could be a little problem with cstring, but I have sadly no idea how to solve it.
My googling suggests that locate cstring | grep include might be of interest:
/usr/include/boost/compatibility/cpp_c_headers/cstring
/usr/include/boost/python/docstring_options.hpp
/usr/include/boost/test/utils/basic_cstring
/usr/include/boost/test/utils/basic_cstring/basic_cstring.hpp
/usr/include/boost/test/utils/basic_cstring/basic_cstring_fwd.hpp
/usr/include/boost/test/utils/basic_cstring/bcs_char_traits.hpp
/usr/include/boost/test/utils/basic_cstring/compare.hpp
/usr/include/boost/test/utils/basic_cstring/io.hpp
/usr/include/c++/4.8/cstring
/usr/include/c++/5/cstring
/usr/include/qt4/Qt/q3cstring.h
/usr/include/qt4/Qt3Support/q3cstring.h
Maybe it is a problem that there are two versions of C++ installed?
I'am pretty close to setting my system up
from scratch so you guys are my last hope.
Thanks to #molbdnilo and #Konrad Rudolph I figured that somehow my /usr/include/string.h (which is a C Header file) tried to import /usr/include/c++/5/iostream (which is a c++ lib).
After a vim diff with a working string.h I deleted the divergent lines wich was only the include statement for iostream.
As #digitalarbeiter recommended it is in general a bad idea to manualy change some code in this kind of files so I reinstalled libc6-dev with
sudo apt-get install libc6-dev --reinstall
and it still works.
I still have no idea how this could happen. The file was edited in april and the error occured in october. Anyway thanks to all the helpers!
So I am looking to compile this project https://github.com/MMquant/bfx-cpp-api using the example code. I have included the cryptopp file that was suggested in the read me. It is found here: https://github.com/weidai11/cryptopp.
I am using Ubutnu version 17.10 and the GNU compiler.
Here's how I am compiling:
g++ example.cpp BitfinexAPI.cpp BitfinexAPI.hpp -Icryptopp -I. -o a -w -std=c++17
It seems strange that BitFinex would support broken code so I am fairly sure that the issue must be something that I am doing.
The errors I am getting are related to line 936 where the datatype 'byte' is not declared. My prediction is that I am missing a header file somewhere but any help would be appreciated.
$ g++ example.cpp BitfinexAPI.cpp BitfinexAPI.hpp -Icryptopp -I. -o a -w -std=c++17
BitfinexAPI.cpp: In static member function ‘static int BitfinexAPI::getBase64(const string&, std::__cxx11::string&)’:
BitfinexAPI.cpp:936:5: error: ‘byte’ was not declared in this scope
byte buffer[1024] = {};
^~~~
BitfinexAPI.cpp:936:5: note: suggested alternative:
In file included from ../cryptopp/seckey.h:9:0,
from ../cryptopp/hmac.h:9,
from BitfinexAPI.cpp:37:
../cryptopp/config.h:222:23: note: ‘CryptoPP::byte’
typedef unsigned char byte;
^~~~
BitfinexAPI.cpp:940:9: error: ‘buffer’ was not declared in this scope
buffer[i] = content[i];
^~~~~~
BitfinexAPI.cpp:940:9: note: suggested alternative: ‘setbuffer’
buffer[i] = content[i];
^~~~~~
setbuffer
BitfinexAPI.cpp:943:21: error: ‘buffer’ was not declared in this scope
StringSource ss(buffer, content.length(), true, new Base64Encoder( new StringSink(encoded), false));
^~~~~~
BitfinexAPI.cpp:943:21: note: suggested alternative: ‘setbuffer’
StringSource ss(buffer, content.length(), true, new Base64Encoder( new StringSink(encoded), false));
^~~~~~
setbuffer
BitfinexAPI.cpp: In static member function ‘static int BitfinexAPI::getHmacSha384(const string&, const string&, std::__cxx11::string&)’:
BitfinexAPI.cpp:963:33: error: ISO C++ forbids declaration of ‘type name’ with no type [-fpermissive]
SecByteBlock byteKey((const byte*)key.data(), key.size());
^~~~
BitfinexAPI.cpp:963:27: error: expected primary-expression before ‘const’
SecByteBlock byteKey((const byte*)key.data(), key.size());
^~~~~
BitfinexAPI.cpp:963:27: error: expected ‘)’ before ‘const’
Here's how I am compiling:
g++ example.cpp BitfinexAPI.cpp BitfinexAPI.hpp -Icryptopp -I. -o a -w -std=c++17
It seems strange that BitFinex would support broken code so I am
fairly sure that the issue must be something that I am doing.
The errors I am getting are related to line 936 where the datatype
'byte' is not declared. My prediction is that I am missing a header
file somewhere but any help would be appreciated.
#kabanus identified the problem.
Crypto++ used to provide a byte in the global C++ namespace. It was there for two reasons. First, it was a convenience item on Linux. You could use byte instead of CryptoPP::byte. Second, it avoided compiler errors on Windows. Microsoft SDK's provide a byte in the global namespace, and if we put a byte at CryptoPP::byte then compile errors resulted from ambiguous definitions.
C++17 came along and offered a std::byte; see P0298R0, A byte type definition. The global Crypto++ byte broke Linux when folks used a using namespace std. And it completely broke Microsoft because Microsoft SDK's provides a global byte. Ironically, the authors of P0298R0 work for Microsoft.
Crypto++ placing a byte in the global namespace was a C++ No-No. We got away with it for years, but it jumped up and bit us in C++17. We moved it into our namespace where it belongs. The check-in occurred at Commit 00f9818b5d8e, which happened after 5.6.5 was released and prior to 6.0 release.
Looking at the source for BitfinexAPI.cpp, this is probably the solution... open BitfinexAPI.cpp, and add the following at the top of the file:
// CRYPTOPP_NO_GLOBAL_BYTE signals byte is at CryptoPP::byte
#if defined(CRYPTOPP_NO_GLOBAL_BYTE)
using CryptoPP::byte;
#endif
Also see std::byte on the Crypto++ wiki. We took the time to document it because of all the problems std::byte, Microsoft's global byte and our byte definitions are going to cause.
Related, you don't need to specify the C++ header on the command line. The compile error is due to the changes detailed above. All you need is:
g++ -std=c++17 example.cpp BitfinexAPI.cpp -I. ./cryptopp/libcryptopp.a -o example.exe
This assumes a directory structure of:
- bfx-api/
|
+- cryptopp/
The cryptopp/libcryptopp.a is a convenient way to sidestep those stupid Linux path problems that have existed for years. You link against the static archive which means you don't need a library at runtime.
Now open in the BFX issue tracker: Crypto++ byte change at Crypto++ 6.0. It should help the project engineer around the changes.
A bit tricky but I (think?) found it. byte is defined in the cryptopp code at:
https://github.com/weidai11/cryptopp/blob/master/config.h
line 222. So I'm guessing the config.h on your system is non-existent, probably because you didn't properly install the header. A common problem is having the library
sudo apt-get install libcrypto++
but missing the developer files (specifically the headers)
sudo apt-get install libcrypto++-dev
I'm not 100% about the package names (Debian user), should be close though.
Good catch from JTejedor:
Seems like the crypto guys placed a namespace around their definitions so as to not conflict with std::byte. You may want to add a CryptoPP:: to the byte definition in bfx (line 936), and if that works open a bug to the guys over there (or request a pull).
I am trying work with FingerPrinter SDK, it shows an example to runs it on linux, i run it on linux cuz its more customizable than windows, well i followed all instructions included to build and compile, but i get this error. These SDK uses libusb library and some usb rules, both are perfectly installed and allowed. Hope get some help.
this is the complete pack where you can find all codes and readmes.
Dowload code!
In file included from /usr/include/x86_64-linux-gnu/bits/waitstatus.h:64:0,
from /usr/include/stdlib.h:42,
from /usr/include/usb.h:15,
from ../lnx/usbl.c:10:
../endian.h:44:10: error: #error Header <endian.h> should define macro __BYTE_ORDER.
#error Header <endian.h> should define macro __BYTE_ORDER.
^
In file included from /usr/include/stdlib.h:42:0,
from /usr/include/usb.h:15,
from ../lnx/usbl.c:10:
/usr/include/x86_64-linux-gnu/bits/waitstatus.h:79:15: error: duplicate member ‘__w_retcode’
unsigned int __w_retcode:8;
^
/usr/include/x86_64-linux-gnu/bits/waitstatus.h:80:15: error: duplicate member ‘__w_coredump’
unsigned int __w_coredump:1;
^
/usr/include/x86_64-linux-gnu/bits/waitstatus.h:81:15: error: duplicate member ‘__w_termsig’
unsigned int __w_termsig:7;
^
/usr/include/x86_64-linux-gnu/bits/waitstatus.h:93:15: error: duplicate member ‘__w_stopsig’
unsigned int __w_stopsig:8; /* Stopping signal. */
^
/usr/include/x86_64-linux-gnu/bits/waitstatus.h:94:15: error: duplicate member ‘__w_stopval’
unsigned int __w_stopval:8; /* W_STOPPED if stopped. */
^
The stdlib.h is including the endian.h from your (or the SDK's) source code instead of the one from the standard include files, thus __BYTE_ORDER is never defined. Find the conflicting endian.h file and rename it. Or remove -I compilation flag from your tool chain.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598600
Welcome to tool chain configuration hell.
This has happened before to me, but I can't remember how I fixed it.
I can't compile some programs here on a new Ubuntu install... Something is awry with my headers.
I have tried g++-4.1 and 4.3 to no avail.
g++ -g -frepo -DIZ_LINUX -I/usr/include/linux -I/usr/include -I/include -c qlisttest.cpp
/usr/include/libio.h:332: error: ‘size_t’ does not name a type
/usr/include/libio.h:336: error: ‘size_t’ was not declared in this scope
/usr/include/libio.h:364: error: ‘size_t’ has not been declared
/usr/include/libio.h:373: error: ‘size_t’ has not been declared
/usr/include/libio.h:493: error: ‘size_t’ does not name a type
/usr/include/stdio.h:294: error: ‘size_t’ has not been declared
...
the file...
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
...
#ubuntu:~/work/zpk/src$ cat /usr/include/linux/types.h | grep size_t
typedef __kernel_size_t size_t;
typedef __kernel_ssize_t ssize_t;
types.h is definitely in the path, and is getting picked up. I verified by changing the file name and get an error its missing...
Does anyone have any ideas...? I would really appreciate the help...
Start by removing -I/usr/include/linux and -I/usr/include. Adding system directories to include paths manually either has no effect, or breaks things. Also, remove -frepo for extra safety.
Generally, you shouldn't be using C .h files for C++. While you may find an easy way to get away with it, and while a lot of this was allowed in previous versions of g++ and in other compilers, the C++ standard defines size_t to be in cstddef (see section 18.2/table 17). g++ has been only getting more strict.
Remove all the includes paths you've added to your command (they are redundant), and add to the top of your source code if not included:
#include <cstddef>
using namespace std;
It's hard to say what the issue is without seeing your complete source. The best way to debug issues like this is to use g++'s "-E" parameter to produce pre-processor output, and then look at that to figure out what's going on in your includes. Here's what the g++ info page says about "-E":
-E Stop after the preprocessing stage; do not run the compiler proper.
The output is in the form of preprocessed source code, which is
sent to the standard output.
Also, why not just include sys/types.h at the top of the file?
Addendum:
On my system, I've created a short file called foo.cc that contains only:
#include <time.h>
And then I've run:
g++ -E /tmp/foo.cc > /tmp/foo.pp
Looking at this output in much detail is very important. For example, I learned that /usr/include/bits/types.h has a typedef for __time_t, and that /usr/include/types.h then uses that typedef to say "typedef __time_t time_t". But, there are interesting other macros surrounding that definiton. Pay special attention to things like the macro "__BEGIN_NAMESPACE_STD" in /usr/include/time.h, which on my system seems to be an empty define. But, I can imagine that some other systems may have a different value for this macro, forcing the definition of time_t into some other namespace.
Read the Cpp info page, section "9 Preprocessor Output" that defines the format of the lines of the file. Of particular note is the section on:
Source file name and line number information is conveyed by lines of the form
# LINENUM FILENAME FLAGS
And then goes on to describe "FLAGS" which are of interest for this level of debugging.
Have you installed the build-essential package?
sudo apt-get install build-essential
Forgot to follow up on this. It turns out that /usr/include cannot be included with /usr/include/linux on this particular distro. size_t seems to be get wiped out by the second includes.
My includes are now merely /usr/include and it works great.
-I/usr/include -I/usr/include/ace -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0...
Pulling out all the includes and playing with them fixed it.
It should be in stddef.h or cstddef. types.h is not a standard library, and I believe it refers to types the OS needs.