I'm a bit new to MATLAB but am currently trying to build MEX files using G++ (version 6.3) as the compiler. I got this error
MEX completed successfully.
Building with 'g++'.
Error using mex
/disks/local/sceneflow2/./external/libtrws/trwsMex.cpp:14:13: error: conflicting declaration ‘typedef
int mwSize’
In file included from /usr/local/MATLAB/R2016a/extern/include/matrix.h:25:0,
from /usr/local/MATLAB/R2016a/extern/include/mex.h:51,
from /disks/local/sceneflow2/./external/libtrws/trwsMex.cpp:9:
/usr/local/MATLAB/R2016a/extern/include/tmwtypes.h:795:19: error: ‘mwSize’ has a previous
declaration as ‘typedef size_t mwSize’
/disks/local/sceneflow2/./external/libtrws/trwsMex.cpp:15:13: error: conflicting declaration ‘typedef
int mwIndex’
In file included from /usr/local/MATLAB/R2016a/extern/include/matrix.h:25:0,
from /usr/local/MATLAB/R2016a/extern/include/mex.h:51,
from /disks/local/sceneflow2/./external/libtrws/trwsMex.cpp:9:
/usr/local/MATLAB/R2016a/extern/include/tmwtypes.h:796:19: error: ‘mwIndex’ has a previous
declaration as ‘typedef size_t mwIndex’
Error in make_mex (line 20)
mex ./external/libtrws/trwsMex.cpp -largeArrayDims CXXFLAGS="\$CXXFLAGS -std=c++0x -fpermissive"
-outdir build
I don't get it. Why is /usr/local/MATLAB/R2016a/extern/include/tmwtypes.h definition of mwSize conflicting with /usr/local/MATLAB/R2016a/extern/include/mex.h? Aren't they predefined libraries included with MATLAB (meaning they should work fine?)
By the way, /disks/local/sceneflow2/./external/libtrws/trwsMex.cpp has a line which includes the aforementioned mex.h.
The error message has to blocks (for two different errors), let's look at the first one only. I've split it out into three "lines":
/disks/local/sceneflow2/./external/libtrws/trwsMex.cpp:14:13: error: conflicting declaration
‘typedef int mwSize’
In file included from /usr/local/MATLAB/R2016a/extern/include/matrix.h:25:0,
from /usr/local/MATLAB/R2016a/extern/include/mex.h:51,
from /disks/local/sceneflow2/./external/libtrws/trwsMex.cpp:9:
/usr/local/MATLAB/R2016a/extern/include/tmwtypes.h:795:19: error: ‘mwSize’ has a previous
declaration as ‘typedef size_t mwSize’
The first line says that the compiler found a declaration for mwSize on line 14 of your trwsMex.cpp file, where it says typedef int mwSize.
The last line says that this mwSize was already defined in the tmwtypes.h header that comes with MATLAB.
The second line says that this header file was included by matrix.h, which is included by mex.h, which is included by your trwsMex.cpp on line 9.
So, to fix the error, don't define mwSize and mwIndex in your MEX-file source code, these are defined by MATLAB's headers.
Related
I am trying to compile a program that I have had no issues compiling with Ubuntu 18.04 and Windows 10. However, when I try to compile it on OSX High Sierra I am given errors and they are only related to boost.
This is an example:
#include <boost/process.hpp>
#include <iostream>
int main()
{
std::cout << "This is a test." << std::endl;
}
I have then tried to compile the program with both g++ and clang like this:
g++ -std=c++11 test.cpp -lpthread
I then get this massive error:
In file included from test.cpp:1:
In file included from /usr/local/include/boost/process.hpp:24:
In file included from /usr/local/include/boost/process/async_system.hpp:22:
In file included from /usr/local/include/boost/process/child.hpp:21:
In file included from /usr/local/include/boost/process/detail/child_decl.hpp:30:
/usr/local/include/boost/process/detail/posix/wait_for_exit.hpp:60:7: error: expected unqualified-id
::sigemptyset(&sigset);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:125:26: note: expanded from macro 'sigemptyset'
#define sigemptyset(set) (*(set) = 0, 0)
^
In file included from test.cpp:1:
In file included from /usr/local/include/boost/process.hpp:24:
In file included from /usr/local/include/boost/process/async_system.hpp:22:
In file included from /usr/local/include/boost/process/child.hpp:21:
In file included from /usr/local/include/boost/process/detail/child_decl.hpp:30:
/usr/local/include/boost/process/detail/posix/wait_for_exit.hpp:61:7: error: expected unqualified-id
::sigaddset(&sigset, SIGCHLD);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:122:31: note: expanded from macro 'sigaddset'
#define sigaddset(set, signo) (*(set) |= __sigbits(signo), 0)
^
In file included from test.cpp:1:
In file included from /usr/local/include/boost/process.hpp:24:
In file included from /usr/local/include/boost/process/async_system.hpp:22:
In file included from /usr/local/include/boost/process/child.hpp:21:
In file included from /usr/local/include/boost/process/detail/child_decl.hpp:30:
/usr/local/include/boost/process/detail/posix/wait_for_exit.hpp:87:26: error: no member named 'sigtimedwait' in the global namespace
auto ret_sig = ::sigtimedwait(&sigset, nullptr, &ts);
~~^
In file included from test.cpp:1:
In file included from /usr/local/include/boost/process.hpp:25:
In file included from /usr/local/include/boost/process/group.hpp:32:
/usr/local/include/boost/process/detail/posix/wait_group.hpp:64:7: error: expected unqualified-id
::sigemptyset(&sigset);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:125:26: note: expanded from macro 'sigemptyset'
#define sigemptyset(set) (*(set) = 0, 0)
^
In file included from test.cpp:1:
In file included from /usr/local/include/boost/process.hpp:25:
In file included from /usr/local/include/boost/process/group.hpp:32:
/usr/local/include/boost/process/detail/posix/wait_group.hpp:65:7: error: expected unqualified-id
::sigaddset(&sigset, SIGCHLD);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:122:31: note: expanded from macro 'sigaddset'
#define sigaddset(set, signo) (*(set) |= __sigbits(signo), 0)
^
In file included from test.cpp:1:
In file included from /usr/local/include/boost/process.hpp:25:
In file included from /usr/local/include/boost/process/group.hpp:32:
/usr/local/include/boost/process/detail/posix/wait_group.hpp:90:17: error: no member named 'sigtimedwait' in the global namespace
ret = ::sigtimedwait(&sigset, nullptr, &ts);
~~^
6 errors generated.
I could be missing a compiler flag, I have tried -lboost_system but that gave the same exact errors. If this specific library is not compatible with OSX then I will try and find a work around, but this library is already embedded in the code that I am currently working with.
Are there any known fixes for this?
You are correct. As of 1.69.0 Boost.Process is broken on MacOS. For the gritty details, follow the link to the bug report.
There is a workaround given in the bug report to get it compiling on MacOS:
Turns out that MacOS isn't the only platform that defines sigemptyset, sigaddset. That is an easy fix since all you need to do is drop the :: qualifier. As for the sigtimedwait, that too isn't common on all platforms. Strangely, stripping the :: qualifier from that one gets the code to compile. I am guessing that template is never instantiated so the fact the method does not exits isn't causing us problems.
I can supply a patch but it is nothing more than stripping :: from those 3 identifiers.
A comprehensive patch is included in the Flint project. Note that Flint is MIT licensed if you choose to include their patch in your code
I recently bought a new MacBook on which I transferred my old session. Since then, and after i upgraded to 10.13, i can't get clang to compile anything including only iostream.
Given this program :
#include <iostream>
int main(void)
{
std::cout << "Hello world !" << std::endl;
return 0;
}
gives my this output when g++ main.cpp :
In file included from main.cpp:1:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/iostream:38:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ios:216:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__locale:15:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string:470:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string_view:171:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__string:56:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:640:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:629:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/typeinfo:61:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/exception:82:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cstdlib:86:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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:
In file included from /usr/include/sys/resource.h:72:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/stdint.h:119:
In file included from /usr/local/include/stdint.h:82:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/inttypes.h:247:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/inttypes.h:30:
/usr/include/inttypes.h:235:8: error: unknown type name 'intmax_t'
extern intmax_t
^
/usr/include/inttypes.h:236:9: error: unknown type name 'intmax_t'
imaxabs(intmax_t j);
^
/usr/include/inttypes.h:240:2: error: unknown type name 'intmax_t'
intmax_t quot;
^
/usr/include/inttypes.h:241:2: error: unknown type name 'intmax_t'
intmax_t rem;
^
/usr/include/inttypes.h:246:9: error: unknown type name 'intmax_t'
imaxdiv(intmax_t __numer, intmax_t __denom);
^
/usr/include/inttypes.h:246:27: error: unknown type name 'intmax_t'
imaxdiv(intmax_t __numer, intmax_t __denom);
^
/usr/include/inttypes.h:250:8: error: unknown type name 'intmax_t'
extern intmax_t
^
/usr/include/inttypes.h:256:8: error: unknown type name 'uintmax_t'; did you
mean 'uintptr_t'?
extern uintmax_t
^
/usr/include/sys/_types/_uintptr_t.h:30:24: note: 'uintptr_t' declared here
typedef unsigned long uintptr_t;
^
In file included from main.cpp:1:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/iostream:38:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ios:216:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__locale:15:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string:470:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string_view:171:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__string:56:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:640:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:629:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/typeinfo:61:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/exception:82:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cstdlib:86:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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:
In file included from /usr/include/sys/resource.h:72:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/stdint.h:119:
In file included from /usr/local/include/stdint.h:82:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/inttypes.h:247:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/inttypes.h:30:
/usr/include/inttypes.h:263:8: error: unknown type name 'intmax_t'
extern intmax_t
^
/usr/include/inttypes.h:269:8: error: unknown type name 'uintmax_t'; did you
mean 'uintptr_t'?
extern uintmax_t
^
/usr/include/sys/_types/_uintptr_t.h:30:24: note: 'uintptr_t' declared here
typedef unsigned long uintptr_t;
^
In file included from main.cpp:1:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/iostream:38:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ios:216:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__locale:15:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string:470:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string_view:171:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__string:56:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:640:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:629:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/typeinfo:61:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/exception:82:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cstdlib:86:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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: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;
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
I tried the following :
Reset CLT with Xcode-select --reset
Reinstall CLT
Reinstall Xcode
None of these solution worked and this starting to drive me crazy. Does somebody has the same problem and found a solution ?
EDIT : Xcode C++ Projects are successfully compiling, still don't understand why it would not in a terminal.
I had exactly the same problem after transferring to macOS High Sierra (though, errors were not the same, but similar).
I found a workaround by renaming /usr/local/include to /usr/local/include_old (well, name does not really matter, just the fact that g++/clang will not search for headers in this folder anymore).
I had exactly the same problem today and after executing xcode-select --install, everything works fine!
I had the same issue after upgrading to MacOS Mojave 10.14.4 and Xcode 10.2
The issue got resolved, after installing the package
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
Same error I encountered on golang recently.
This was my solution: rm -rf /usr/local/include
I'm guessing the higher version of MacOS (I'm currently on BigSur) doesn't need that folder anymore so you might save a little bit of storage space if the folder is going to be deleted.
Check that you don't include "/usr/local/include" into headers search path of your project.
I had a similar issue that after upgrading to high sierra (and Xcode 9.1) that my standard make reported unfamiliar warnings.
It drew .h files from /usr/local/include instead from the (as I thought) standard /usr/include. For example, there was no zlib.h available.
Reinstalling Xcode (who claims to install the commandline version too) did not help.
There was no /usr/include at all but the C++ system include were available through the links reported in clang --version, but none of the C-includes.
After xcode-select --install and actually "install" of the commandline material the /usr/include was populated with the necessary C libraries, and make started to compile without warnings again.
The heavily upvoted answer here is to rename /usr/local/include to something else, which essentially removes it. This is not a great idea.
The source of this error is old header files in /usr/local/include that are no longer needed and create errors like the one OP describes.
Instead of removing this folder, clean it out.
Move (not copy) all of the files in /usr/local/include into a backup location.
(Optional) Reinstall any libraries you need on the system. In my case, I needed to reinstall GLFM and GLM because I'm doing some graphics programming.
Try building again.
Found the solution here, following #Sudheer's suggestion:
sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /
from https://donatstudios.com/MojaveMissingHeaderFiles
After renaming the /usr/local/include to /usr/local/include_old. Not sure if that was necessary, but renaming alone did not help (though it changed the kind of error I was getting).
I have prepared a llvm-clang compiler targeting 32bit Windows. I used 3.7.1 and applied this patch. I get to something that almost works, apart that I have errors with boost.
If I compile my project (that normally works with mingw-gcc) using my usual boost 1.53 headers I have troubles including boost/interprocess components
In file included from [...]/Boost/include-WINDOWS/boost-1_53\boost/interprocess/sync/interprocess_semaphore.hpp:24:
In file included from [...]/Boost/include-WINDOWS/boost-1_53\boost/interprocess/exceptions.hpp:20:
In file included from [...]/Boost/include-WINDOWS/boost-1_53\boost/interprocess/errors.hpp:37:
[...]/Boost/include-WINDOWS/boost-1_53\boost/interprocess/detail/win32_api.hpp:878:48: error: conflicting types for 'VirtualProtect'
If I then try to recompile boost with:
bootstrap.bat mingw
b2 toolset=clang --with-thread --with-filesystem --with-signals --with-test --with-system --with-regex --with-program_options --with-serialization variant=release link=shared threading=multi
Depending on the various version of boost I get a lot of warnings that I could try to ignore, but also some errors:
For 1.56 and 1.57 just these: (is not much, but I don't know how to get rid of it)
In file included from libs\serialization\src\xml_wiarchive.cpp:35:
.\boost/archive/impl/archive_serializer_map.ipp:41:34: error: redeclaration of 'boost::archive::detail::archive_serializer_map::insert' cannot add 'dllexport' attribute
archive_serializer_map<Archive>::insert(const basic_serializer * bs){
^
.\boost/archive/detail/archive_serializer_map.hpp:42:17: note: previous declaration is here
static bool insert(const basic_serializer * bs);
^
In file included from libs\serialization\src\xml_wiarchive.cpp:35:
.\boost/archive/impl/archive_serializer_map.ipp:49:34: error: redeclaration of 'boost::archive::detail::archive_serializer_map::erase' cannot add 'dllexport' attribute
archive_serializer_map<Archive>::erase(const basic_serializer * bs){
^
.\boost/archive/detail/archive_serializer_map.hpp:43:17: note: previous declaration is here
static void erase(const basic_serializer * bs);
^
In file included from libs\serialization\src\xml_wiarchive.cpp:35:
.\boost/archive/impl/archive_serializer_map.ipp:61:34: error: redeclaration of 'boost::archive::detail::archive_serializer_map::find' cannot add 'dllexport' attribute
archive_serializer_map<Archive>::find(
^
.\boost/archive/detail/archive_serializer_map.hpp:44:37: note: previous declaration is here
static const basic_serializer * find(
^
For 1.59 and 1.60 a bunch of MMX related error, which is, as far as I can see, not a feature that I can control when preparing my llvm-clang:
clang-linux.compile.c++.without-pth bin.v2\libs\thread\build\clang-linux-3.7.1\debug\threading-multi\win32\thread.obj
In file included from libs\thread\src\win32\thread.cpp:17:
In file included from .\boost/thread/thread_only.hpp:15:
In file included from .\boost/thread/win32/thread_data.hpp:11:
In file included from .\boost/thread/win32/thread_primitives.hpp:18:
In file included from .\boost/detail/interlocked.hpp:154:
In file included from C:\Programs\LLVM\bin\..\lib\clang\3.7.1\include\intrin.h:26:
In file included from C:\Programs\MinGW\i686-w64-mingw32\include\Intrin.h:154:
In file included from C:\Programs\LLVM\bin\..\lib\clang\3.7.1\include\mm3dnow.h:27:
C:\Programs\LLVM\bin\..\lib\clang\3.7.1\include\mmintrin.h:28:2: error: "MMX instruction set not enabled"
#error "MMX instruction set not enabled"
^
In file included from libs\thread\src\win32\thread.cpp:17:
In file included from .\boost/thread/thread_only.hpp:15:
In file included from .\boost/thread/win32/thread_data.hpp:11:
In file included from .\boost/thread/win32/thread_primitives.hpp:18:
In file included from .\boost/detail/interlocked.hpp:154:
In file included from C:\Programs\LLVM\bin\..\lib\clang\3.7.1\include\intrin.h:26:
In file included from C:\Programs\MinGW\i686-w64-mingw32\include\Intrin.h:154:
C:\Programs\LLVM\bin\..\lib\clang\3.7.1\include\mm3dnow.h:42:41: error: use of undeclared identifier '__v8qi'
return (__m64)__builtin_ia32_pavgusb((__v8qi)__m1, (__v8qi)__m2);
^
C:\Programs\LLVM\bin\..\lib\clang\3.7.1\include\mm3dnow.h:42:55: error: use of undeclared identifier '__v8qi'
return (__m64)__builtin_ia32_pavgusb((__v8qi)__m1, (__v8qi)__m2);
^
C:\Programs\LLVM\bin\..\lib\clang\3.7.1\include\mm3dnow.h:47:38: error: cannot convert '__m64' to '__v2sf' (vector of 2 'float' values) without a conversion operator
return (__m64)__builtin_ia32_pf2id((__v2sf)__m);
^~~~~~~~~~~
C:\Programs\LLVM\bin\..\lib\clang\3.7.1\include\mm3dnow.h:52:38: error: cannot convert '__m64' to '__v2sf' (vector of 2 'float' values) without a conversion operator
return (__m64)__builtin_ia32_pfacc((__v2sf)__m1, (__v2sf)__m2);
^~~~~~~~~~~~
C:\Programs\LLVM\bin\..\lib\clang\3.7.1\include\mm3dnow.h:52:52: error: cannot convert '__m64' to '__v2sf' (vector of 2 'float' values) without a conversion operator
return (__m64)__builtin_ia32_pfacc((__v2sf)__m1, (__v2sf)__m2);
^~~~~~~~~~~~
Is there a way to get any version of boost to work with clang 32bit under Windows in a MinGW set up?
I have also tried llvm 3.8.0, but I cannot prepare it because my MinGW toolchain doesn't support some part of C++11 (and so other versions that I have tried, see here).
As to boost.thread:
After adding -msse (or whatever) (that resolves MMX instruction set not enabled error) just add -DBOOST_USE_WINDOWS_H to cxxflags to resolve different declarations of many system functions at Windows headers and at boost.date_time.
Eg:
cxxflags="-msse -DBOOST_USE_WINDOWS_H"
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.
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.