Cygwin support

[Bjarke_Hammersholt_R]

As I understand it TBB does not currently work on Cygwin with GCC and it isn't currently supposed to work there either. Are there any plans to add support for GCC on Cygwin to TBB and if so, is there a timeline for that?

[SergeyKostrov]

>>...Are there any plans to add support for GCC... TBB supports a generic GCC and as far as I remember TBB was sucessfully build by a couple of software developers using a MinGW C/C++ compiler ( GCC-based ). Did you attempt to build TBB on Cygwin? Why TBB will fail to work on Cygwin if it is successfully built?

[Bjarke_Hammersholt_R]

Yes, I tried to compile TBB on Cygwin. I used this incantation to get past the first few build system errors (based on a post here, which also states that Cygwin is not supported): make SHELL=/bin/sh compiler=gcc This still gives lots of errors. tbb/tbb_machine.h is supposed to include a suitable file that defines a lot of platform-dependent things. However, on Cygwin, it does not recognize the machine it is running on and instead of emitting an error it just doesn't include anything. I got past that by forcing it to do this: #include "machine/gcc_generic.h" extern "C" __declspec(dllimport) int __stdcall SwitchToThread( void ); #define __TBB_Yield() SwitchToThread() I then get a smaller number of errors. The first one is ../../src/tbb/dynamic_link.cpp: In member function ‘bool tbb::internal::_abs_path::prepare_full_path()’: ../../src/tbb/dynamic_link.cpp:159:13: error: ‘Dl_info’ was not declared in this scope I also tried linking to the TBB Windows pre-built DLLs. That first required the above tricks to get the headers to compile. I found a Cygwin page for how to link Cygwin executables with Windows DLLs. The linker accepted what I gave it but then gave unresolved symbols. Initially it was only a single missing error-handling function that I just implemented myself, but then I got many more linker errors after that. I saw a post stating that this is due to differences in name-mangling between MSVC and GCC.

[SergeyKostrov]

>>...../../src/tbb/dynamic_link.cpp:159:13: error: ‘Dl_info’ was not declared in this scope... Just verified and indeed I have Not found a declaration for 'Dl_info' type. I wonder if TBB developers could explain where 'Dl_info' comes from? Note: This is clearly not for a Windows platform.

[RafSchietekat]

Apparently "#if _WIN32||_WIN64" is not taken, but "#include <dlfcn.h>" does not declare Dl_info, the output type for dladdr() (and probably neither), which, according to the dlopen(3) man page, is one of "two functions not described by POSIX" added by glibc. The only member variable used is dli_fname, so the function seems to be used to find the shared library corresponding to an address in memory, although it's not immediately clear to me how that works out with "(void*)&dynamic_unlink" in the same file. Please first do some more research of your own about the situation with dladdr() in Cygwin and/or a workaround that finds the specific information in dli_fname (shouldn't be too difficult, I suppose), and report any results, or come back if you get stuck. "Not supported" isn't necessarily final, but you have to do at least some of your own lifting.

[Vladimir_P_1234567890]

Hello Bjarke, We can add a support for cygwin in case we will have a contribution with the patch and like we did for mingw support. Time to implement it depends on the patch and how it will actually works. Actually we played with cygwin a few years ago but there were some problems thread count more than 2. Details can be found there http://software.intel.com/en-us/forums/topic/302505 thanks --Vladimir

[SergeyKostrov]

>>make SHELL=/bin/sh compiler=gcc >> >>This still gives lots of errors... Could you post a complete compilation log(s) with as many as possible compilation errors? It should help to understand with what is going on in your development environment.

[Vladimir_P_1234567890]

deleted

[Bjarke_Hammersholt_R]

I got through the above error and many more errors like it by including Windows.h in some places and by changing #idef _WIN32||_WIN64 to also check for __CYGWIN__ in many places as indicated by compile errors. Just defining _WIN32 or _WIN64 did not work. I had to hack the build system to select pthreads. Since I don't actually know what TBB is doing in most of these places I doubt that this code works, but I got it to compile and link. I got the tests to compile but not link - there were missing errors for everything in tbbmalloc even though tbbmalloc.dll was correctly linked in. It seems the DLL file was not created in a format that GCC on Cygwin could deal with. I followed this link to deal with that: http://cygwin.com/cygwin-ug-net/dll.html The .def file that TBB built could not be read by nm and contained very few functions. The def file made with the scripts on that page did work, and then I replaced the .dll file with the generated .a file and that allowed more of the linking to proceed (though I have no idea if the results are correct). At this point I'm down to this linker error, that I get when the makefile tries to link tbbmalloc_proxy: $ g++ -o tbbmalloc_proxy.dll proxy.o tbb_function_replacement.o -lpsapi tbbmalloc.dll -shared ertr000001.o:(.rdata+0x0): undefined reference to `__pei386_runtime_relocator' collect2: ld returned 1 exit status From a Google search this seems to be related to linker options, but I haven't found a parameter that makes the error go away. I suspect this is just a symptom of a broken TBB build. TBB itself and some of the tests do link, so I could run some of the tests. I'm not sure how to tell if a test passed or not - they don't print out pass or fail. Here's what I got: $ ./test_aligned_space.exe ; echo $? done 0 $ ./test_assembly.exe ; echo $? done 0 $ ./test_assembly_compiler_builtins.exe ; echo $? done 0 $ ./test_atomic.exe ; echo $? (I stopped it after 8m cpu time) 0 $ ./test_atomic_pic.exe ; echo $? Known issue: PIC mode is not supported skip 0 $ ./test_atomic_compiler_builtins.exe ; echo $? (I stopped it after 1m cpu time) $ ./test_fast_random.exe ; echo $? (I stopped it after 1m cpu time) $ ./test_task_assertions.exe ; echo $? skip 0 $ ./test_task_leaks.exe ; echo $? skip 0 $ ./test_ScalableAllocator.exe ; echo $? 127

[SergeyKostrov]

>>$ g++ -o tbbmalloc_proxy.dll proxy.o tbb_function_replacement.o -lpsapi tbbmalloc.dll -shared >>ertr000001.o:(.rdata+0x0): undefined reference to `__pei386_runtime_relocator' >>collect2: ld returned 1 exit status >> >>From a Google search this seems to be related to linker options, but I haven't found a parameter that makes the error go away. I suspect >>this is just a symptom of a broken TBB build... `__pei386_runtime_relocator' looks like a system function of Linux / Cygwin. Does it belong to TBB? I don't think so. Just in case: PE stands for 'Portable Executable'

[Vladimir_P_1234567890]

Bjarke Hammersholt R. wrote:

At this point I'm down to this linker error, that I get when the makefile tries to link tbbmalloc_proxy:

$ g++ -o tbbmalloc_proxy.dll proxy.o tbb_function_replacement.o -lpsapi tbbmalloc.dll -shared
ertr000001.o:(.rdata+0x0): undefined reference to `__pei386_runtime_relocator'
collect2: ld returned 1 exit status

Just ignore malloc proxy error for now. Comment *MALLOCPROXY* variables in windows.inc file. Even you compile it it won't work for cygwin without changes.