6

Normally I can google my way around and find solutions, but not this time.

I'm using 64 bit Linux Ubuntu 11.04 to compile a 32 bit windows application. I'm using i586-mingw32msvc-gcc to compile my C++ files.

test.cpp:

#include <boost/asio.hpp>

makefile:

i586-mingw32msvc-gcc -c -m32 -mthreads -o test.o test.cpp

Error:

boost/asio/detail/socket_types.hpp:
# include <sys/ioctl.h>
doesn't exist.

Added to makefile: -DBOOST_WINDOWS

Error:
#   warning Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately

Ok, added to makefile: -D_WIN32_WINNT=0x0501

Error:
#   error "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)"

Yet I did specify -mthreads.

Cédric Julien
  • 78,516
  • 15
  • 127
  • 132
Mike
  • 2,393
  • 3
  • 25
  • 37

3 Answers3

3

Adding -DBOOST_HAS_THREADS might be sufficient (see # elif defined __GNUC__ from the offending header). But it's likely/possible that your boost installation has been crafted to support your build environment and not your target. Try building it yourself with your cross-compiling toolchain.

Brian Cain
  • 14,403
  • 3
  • 50
  • 88
  • -DBOOST_HAS_THREADS result in an error in one of the header files, where an #define tries to redefine it causing an error. – Mike Nov 08 '11 at 22:04
  • Was building boost for your target effective? – Brian Cain Nov 08 '11 at 23:32
  • Hi Brian, I used the instructions on this page: http://www.vle-project.org/wiki/Cross_compilation_Win32 to compile boost using mingw on my 64 bit ubuntu 11.04, which works and produced all the dlls in the stage/lib directory. But to compile anything that uses the boost header files that accesses threading, I'm always getting this error and no matter with what flags I tinker, I can't found a way around it. I'm flabbergasted how I can not find a solution through a quick 2 minute googling around. Am I the only one that's trying to use mingw on linux to make a windows program that uses threading? – Mike Nov 10 '11 at 19:37
  • "But to compile anything that uses the boost header files that accesses threading" -- the header files should be an output of the boost build as well. Are you sure your include path excludes the build host's copy of boost's include files? Try getting the preprocessed output to be sure (replace "-c" with "-E" and perhaps change the "foo.o" to "foo.txt", review the foo.txt) – Brian Cain Nov 11 '11 at 18:14
  • Brian, thanks for the top on examining the preprocessed output. However, this was the culprit: #undef __GLIBC__ #define __GLIBC__ 2 #undef __GLIBC_MINOR__ #define __GLIBC_MINOR__ 4 which threw Boost off. I needed that for an earlier Linux version of the product... – Mike Nov 11 '11 at 21:16
  • I'd like to say that you found the answer, but it was not the pre-processor output that led to this. I found the glibc defs in my code and I don't know what I even tried commenting those out, but I did and made this nasty problem go away. I think while I was tracing up and down some of the conditional macros in the boost code, I ended up with a hunch how not force feeding glibc versions would make boost follow a different path... For a while I thought that I needed specific BOOST related definitions that weren't documented very well, needed for cross compiled threading support... – Mike Nov 15 '11 at 21:03
  • Well, regardless of which answer was the right one, if your question has been answered then it'd be best for you to accept an answer (if you need to add your own answer, then please go right ahead). – Brian Cain Nov 17 '11 at 02:47
  • 1
    Brian, I just figured out how the bounty system works. To me it seems to work like an advertising fee. I feel that noone actually found the answer, and I found the answer myself, but given that the "bounty" can not get returned, and that you participated in a positive manner, I wish the bounty to get assigned to you. I'm therefore marking your entry as the answer, even though it wasn't actually the answer. Stackoverflow needs to work on their bounty system, obviously, but that's another matter. Anyway, thank you for trying. You did contribute useful things for me to keep in mind. – Mike Nov 17 '11 at 02:56
  • I didn't know that bounties couldn't be returned. But why not try to copy your comment regarding `GLIBC` to a new answer and accept that one? – Brian Cain Nov 17 '11 at 02:58
  • Ok, I did that. I answered my own question. We'll see what happens. – Mike Nov 17 '11 at 03:44
1

It turned out that I had a set of #undef and #defines to force the GLIBC version to something that allowed me to compile for Linux (not cross compile) RHEL5, which otherwise would give me all kinds of other errors. Turns out that when cross compiling for windows using mingw, that force feeding the GLIBC version causes boost to take a strange path leaving various aspects undefined, including the bahavior or availability of threading. I surrounded it with an #ifndef _WIN32 which made the problem go away.

Mike
  • 2,393
  • 3
  • 25
  • 37
0

Maybe that -mthreads argument needs to come last.

Rob Latham
  • 5,085
  • 3
  • 27
  • 44
  • Just tried that, no difference. "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)" – Mike Nov 07 '11 at 21:29