marginasa Posted March 8, 2017 Report Share Posted March 8, 2017 Hi, I'm trying to build the systemc library using clang within MSYS $ clang -v clang version 3.9.1 (tags/RELEASE_391/final) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: D:\Install\Msys2\mingw64\bin The configure options look as follows: ../configure --prefix=$SYSTEMC_LLVM --with-unix-layout CC=clang.exe CXX=clang++.exe CPP=`clang++.exe -E` CFLAGS=-stdlib=libstdc++ CXXFLAGS=-stdlib=libstdc++ CXXFLAGS=-std=c++11 LDFLAGS="-stdlib=libstdc++" --enable-pthreads --enable-debug The error I get is during compilation of sc_simcontext.cpp ... CXX sc_reset.lo CXX sc_sensitive.lo CXX sc_simcontext.lo In file included from ../../../../src/sysc/kernel/sc_simcontext.cpp:36: ../../../../src\sysc/kernel/sc_cor_pthread.h:43:28: error: typedef redefinition with different types ('sc_core::sc_cor_pkg_pthread' vs 'sc_core::sc_cor_pkg_fiber') typedef sc_cor_pkg_pthread sc_cor_pkg_t; ^ ../../../../src\sysc/kernel/sc_cor_fiber.h:48:26: note: previous definition is here typedef sc_cor_pkg_fiber sc_cor_pkg_t; I assume that I might be missing some defines to exclude the above seen redefinition but I cannot figure out which.. as with Visual Studio compiler (not clang) I have built the library. There are 3 defines across source code in 3 header files.. typedef sc_cor_pkg_fiber sc_cor_pkg_t; typedef sc_cor_pkg_qt sc_cor_pkg_t; typedef sc_cor_pkg_pthread sc_cor_pkg_t; Any hint is appretiated. Thanks. Quote Link to comment Share on other sites More sharing options...
AmeyaVS Posted March 9, 2017 Report Share Posted March 9, 2017 Hello, Can you post the result of your configure step? I am able to build and use SystemC library under cygwin clang 3.9.1 with following steps: $ export CC=clang $ export CXX=clang++ $ ../configure --prefix=$HOME/apps/systemc-2.3.1a-clang --enable-debug --enable-pthreads $ make -j4 $ make check $ make install You can try to remove the "CFLAGS, CXXFLAGS and LDFLAGS" from your configure script parameters. 9 hours ago, marginasa said: ../configure --prefix=$SYSTEMC_LLVM --with-unix-layout CC=clang.exe CXX=clang++.exe CPP=`clang++.exe -E` CFLAGS=-stdlib=libstdc++ CXXFLAGS=-stdlib=libstdc++ CXXFLAGS=-std=c++11 LDFLAGS="-stdlib=libstdc++" --enable-pthreads --enable-debug Regards, Ameya Vikram Singh Quote Link to comment Share on other sites More sharing options...
marginasa Posted March 9, 2017 Author Report Share Posted March 9, 2017 Hi Ameya, Thank you for reply. I get the same error with using your configure options, when I execute make -j4 config.log and config.status are attached. Regards, Andrei config.log config.status Quote Link to comment Share on other sites More sharing options...
AmeyaVS Posted March 9, 2017 Report Share Posted March 9, 2017 Hi Andrei, It seems you are trying to give windows absolute path to the configure script. Try running like this: $ ../configure --prefix=/d/Install/Libraries/systemc-2.3.1_llvm/systemc-2.3.1a --enable-pthreads --enable-debug If you are using the msys inbuilt bash shell then above command might be valid. You can verify the path mapping in msys bash shell with something like this: $ mount See if you are getting something like this instead of "C:" look for any entry showing "D:" and refer the path mapping (here it is on "/c" for you it might be "/d"): C: on /c type ntfs (binary,noacl,posix=0,user,noumount,auto) Also from the provided logs I am seeing that the pthread library is not installed. Kindly refer the msys setup for installing pthread threading library. Note: Look into the config.log file I am seeing many dependent packages are not installed: autoconf, automake etc. Regards, Ameya Vikram Singh Quote Link to comment Share on other sites More sharing options...
marginasa Posted March 10, 2017 Author Report Share Posted March 10, 2017 Hi Ameya, The path given to configure was indeed the Windows absolute path. I fixed that. Regarding MSYS2 setup I added some packages(that you mentioned autoconf, automake) and everything containing pthread that I could find but I see no meaningful difference in the way config.log looks like. However, this initial compiler error is independent in my opinion of the availability of the pthread lib. I attach the latest config.log and a list of my installed packages. Appreciate your help. Andrei config.log installed.packages Quote Link to comment Share on other sites More sharing options...
AmeyaVS Posted March 10, 2017 Report Share Posted March 10, 2017 Hello Andrei, I actually checked my SystemC config.log and observe similar behavior from the configure script. For now try building the library and see if the build is progressing or not. In case you are getting similar issue, then if possible try to use a Linux VM in a VirtualBox. If you are not able to use a Linux VM then as a last resort you can try installing cygwin but the performance will not be as good. In the mean time I'll try to find a system where MSYS2 is installed with similar package layout as yours to debug the build issue. Regards, Ameya Vikram Singh Quote Link to comment Share on other sites More sharing options...
marginasa Posted March 10, 2017 Author Report Share Posted March 10, 2017 Hi Ameya, Actually with cygwin I get even earlier to a stop, as during the configure process it fails compile a C++ program. (but that may be related again to how complete is my cygwin environment). However within cygwin I manage to build the systemc library with the GCC chain which I'm able to use it, so I still have question marks regarding the reason for this cygwin:clang:configure:failToBuildC++ situation. see attachement. For Virtual Box solution I need more time to evaluate but I'll consider it. Thank you, Andrei config.log Quote Link to comment Share on other sites More sharing options...
AmeyaVS Posted March 10, 2017 Report Share Posted March 10, 2017 Hello Andrei, From the provided logs I see you have a lot of clang and llvm defined in the path: PATH: /cygdrive/d/_Install/LLVM/bin PATH: /cygdrive/d/Install/CMake/bin PATH: /cygdrive/d/Install/gnuplot/bin PATH: /cygdrive/d/_Install/LLVM012017/LLVM/bin PATH: /cygdrive/c/_Program Files/LLVM/bin PATH: /cygdrive/d/Install/GnuWin32/getGnuWin/GetGnuWin32/gnuwin32/bin PATH: /cygdrive/d/Install/winhex PATH: /cygdrive/d/_Install/MinGW64_2/mingw64/bin PATH: /cygdrive/d/_Install/MinGW64/mingw32/bin PATH: /cygdrive/d/_Install/Msys2/mingw64/bin PATH: /cygdrive/d/_Install/SCBuilder/mingw32/bin PATH: /cygdrive/d/_Install/MinGW/msys/1.0/bin PATH: /cygdrive/c/Windows PATH: /cygdrive/d/Install/Vim PATH: /cygdrive/c/Program Files (x86)/Synopsys/QUASAR3-1.1.1-beta1/libso-msvc-10.0 PATH: /cygdrive/d/Install/Make PATH: /cygdrive/d/Install/GnuWin32/bin PATH: /cygdrive/d/Install/Vim PATH: /cygdrive/d/Install/GNU PATH: /cygdrive/d/Install/LLVM_vs2013/LLVM/bin Try to remove some of them. But first see if you are able to build a simple C++ application using Cygwin clang++. I suspect the clang++ executable is picking up libraries incompatible for it to execute properly. Note: Try to keep all the PATH/other environment variable as clean as possible. I usually have a central location batch/shell scripts from where I will source the environment variables required for the development environment. Windows is much harder development environment to work with and too slow for my preference. Regards, Ameya Vikram Singh Quote Link to comment Share on other sites More sharing options...
marginasa Posted March 11, 2017 Author Report Share Posted March 11, 2017 Hi, After a debug session with Ameya (whom I thank), the build using clang was successful on cygwin but it still fails on MSYS2. Actually the build is failing with both GCC and clang compilers under MSYS2, each of them generating the same compiler error as mentioned in the first post. If anyone has a working MSYS environment in which it was able to build the systemc library, I'd like to have some confirmation. Regards, Andrei Quote Link to comment Share on other sites More sharing options...
ralph.goergen Posted March 13, 2017 Report Share Posted March 13, 2017 Hi. There seems to be a problem with the '#if defined' expressions. MSYS gcc and clang define _WIN32, and in combination with using pthreads, SC_USE_PTHREADS is defined as well. Could you please evaluate possible fixes? E.g. adding '!defined(SC_USE_PTHREADS)' in line 33 of sc_cor_fiber.h? And could you please try with the public review version of SystemC 2.3.2 as well (http://www.accellera.org/downloads/drafts-review)? If this works, I can try to forward the issue to the SystemC developer working group. Greetings Ralph AmeyaVS and maehne 2 Quote Link to comment Share on other sites More sharing options...
marginasa Posted March 13, 2017 Author Report Share Posted March 13, 2017 Hi, For 2.3.1a revision: I modified line 33 of sc_cor_fiber.h as follows #if (defined(_WIN32) || defined(WIN32) || defined(WIN64)) && !defined(SC_USE_PTHREADS) The build process of the SystemC library succeeds. However there are issues when using the library during the link phase. -> make check fails. see attachment. make_check.log Note: I tried with this modification of the header file in the past also with GCC and it behaved the same as now. For 2.3.2 revision: the behavior is similar with 2.3.1a, that is, the compilation fails with the same compiler error message as seen in the first post. see attachment make.log I did not modified again the headers for 2.3.2. I used configure method, not cmake for 2.3.2 Regards, Andrei Quote Link to comment Share on other sites More sharing options...
ralph.goergen Posted March 14, 2017 Report Share Posted March 14, 2017 OK. Thanks. I now saw that there is a comparable guard expression in the sc_cor_pthread.cpp file. But I think changing this needs some more care and investigation. I forward this to the developer community. Greetings Ralph Quote Link to comment Share on other sites More sharing options...
Philipp A Hartmann Posted March 21, 2017 Report Share Posted March 21, 2017 Can you explain, why you try to use Pthreads on the Msys/MinGW platform? This environment doesn't come with a Pthreads library by default, you would need to install a separate one. And Pthreads will certainly be less efficient than the WinFiber-based process implementation. Thanks, Philipp Quote Link to comment Share on other sites More sharing options...
marginasa Posted March 22, 2017 Author Report Share Posted March 22, 2017 Hi Phillip, Actually I did not give a proper thought to this aspect, now that you mention it might make sense. I just followed the "general configure procedure" from linux.. But maybe for the sake of proper closure to this topic, is this a matter of efficiency of choosing between fibers and pthreads, because if there is, then the build process with pthreads should still work. I will check if it works without pthreads and post the result. Regards, Andrei Quote Link to comment Share on other sites More sharing options...
Philipp A Hartmann Posted March 23, 2017 Report Share Posted March 23, 2017 Maybe we can just reject "--enable-pthreads" on this platform explicitly. Generally speaking, you usually want to avoid pthreads, also on Linux, unless you have specific requirements. Greetings from Duisburg, Philipp Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.