Systemc-2.3.1 Installation problem on Windows 7 with Cygwin

[jcmel]

Hello everybody,

 

I followed the steps below  to install systemc-2.3.1 on Windows 7 (64bits) :

• I start a cygwin batch and create a objdir directory
• In this directory I configure the package with ../configure

And I have an error at ./config.status creation. ??

 

I have attached conf.lo and config.status file

 

$ ../configure
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to create a pax tar archive... gnutar
checking whether make supports nested variables... yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... g++
checking whether we are using the GNU C compiler... yes
checking whether g++ accepts -g... yes
checking for g++ option to accept ISO C89... unsupported
checking dependency style of g++... gcc3
checking dependency style of g++... gcc3
checking whether ln -s works... yes
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... no
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by g++... /usr/i686-pc-cygwin/bin/ld.exe
checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -config.status.txtconfig.log.txt interface... BSD nm
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i686-pc-cygwin file names to i686-pc-cygwin format... func_convert_file_noop
checking how to convert i686-pc-cygwin file names to toolchain format... func_convert_file_noop
checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for dlltool... dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from g++ object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... g++ -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if g++ supports -fno-rtti -fno-exceptions... yes
checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC
checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/i686-pc-cygwin/bin/ld.exe
checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC
checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking for SystemC install layout... ignored
checking for SystemC library arch suffix... default (TARGET_ARCH=cygwin)
checking whether to add debug symbols to the SystemC library... no
checking whether to enable compiler optimization... yes
checking whether to add support for asynchronous update requests... yes
checking whether to use POSIX threads for SystemC processes... no
checking whether to enable simulation phase callbacks (experimental)... no
checking for SC_DISABLE_VIRTUAL_BIND defined... no
checking for SC_ENABLE_IMMEDIATE_SELF_NOTIFICATION defined... no
checking for SC_ENABLE_EARLY_MAXTIME_CREATION defined... no
configure: creating ./config.status
./config.status: line 766: e-quote: command not found
./config.status: line 767: syntax error near unexpected token `do'
./config.status: line 767: `ds old_archive_from_new_cmds old_archive_from_expsyms_cmds archive_cmds archive_expsym_cmds module_cmds module_expsym_cmds export_symbols_cmds prelink_cmds postlink_cmds postinstall_cmds postuninstall_cmds finish_cmds sys_lib_search_path_spec sys_lib_dlsearch_path_spec reload_cmds_CXX old_archive_cmds_CXX old_archive_from_new_cmds_CXX old_archive_from_expsyms_cmds_CXX archive_cmds_CXX archive_expsym_cmds_CXX module_cmds_CXX module_expsym_cmds_CXX export_symbols_cmds_CXX prelink_cmds_CXX postlink_cmds_CXX; do'
 

 

Thanks in advance for your help.

 

Regards,

 

Jean-Claude

[Martin Barnasconi]

This could be caused by the famous CRLF incompatibility between Windows/Dos and Unix/Linux.

Please try to run dos2unix for all files in the entire systemc tree, and then try again.

[jcmel]

Hello,

I ran dos2unix to all systemc directory but the problem is the same.

Regards,

 

Jean-Claude

[maehne]

Hello Jean-Claude,

 

Maybe you could try to regenerate the configure script from inside your Cygwin shell. Cygwin tries its best to make Windows look like Unix, but sometimes it cannot hide all differences. Then, Unix programs require patches to work properly. This might be the case for GNU libtool, GNU automake, and GNU autoconf. Install all three packages through the Cygwin package manager and then go to your SystemC root directory. There execute the bootstrap script, which calls libtool, automake, and autoconf in the right order to regenerate configure:

.../systemc-2.3.1/> config/bootstrap

I hope this helps. It's been a while that I used Cygwin to compile SystemC... Nowadays, I prefer MSYS2 with the MinGW-w64 toolchains.

 

Regards,

 

Torsten Maehne

[ralph.goergen]

Hi Jean-Claude,

 

have you been able to run SystemC in the combination Win7 and Cygwin?

I just ask because I am facing poblems with it as well; and I am not sure id it is my configuration or a more general problem.

I am able to build and install SystemC but my threads (SC_THREAD) do not start.

 

Best

Ralph

[jcmel]

Hi Ralph,

Finally I decided to use SystemC with Microsoft Visual Studio 2010 (version 32bits) on Win7.

I made a Dynamic Link Library from systemc-2.3.1 source code and it works.

 

Regards,

Jean-Claude 

[AmeyaVS]

Hello Everyone,

 

I am able to build the SystemC library on cygwin(64-bit) with gcc 5.4.0.

 

I am currently using this command to configure the library for building:

 

../configure --prefix=$HOME/apps/sysc231a --enable-pthreads --enable-debug

 

Note: Kindly note that the --enable-pthreads option while configuration.

It seems the configure script by default uses the QuickThreads user space library for thread support in SystemC library.

 

With QuickThreads the SystemC library is not able to execute SC_THREAD's and quite a few of the regression tests also fails.

 

Currently the systemc library is statically built, and I am able to develop models in Cygwin environment.

 

Regards,

Ameya Vikram Singh

[ralph.goergen]

That's the same as my observations.

 

Works fine with pthreads, problems with QuickThreads (SC_THREADs do not start).

[Philipp A Hartmann]

I'm afraid, we need a more detailed analysis / debugging from someone, who has access to such a platform.  Otherwise, we can just disable QuickThreads on Cygwin again and select Pthreads consistently instead.

 

@Ralph: Can you try hunting this down in a debugger?

Thanks,

  Philipp

[ralph.goergen]

Unfortunately, I am currently a bit limited in my debugging facilities. I will try and report the results.

[ralph.goergen]

OK. Here some results:

 

Problem is in cygwin64 only, not in cygwin32.

 

Simulation runs into a seg fault when it tries to enter the thread at the following code location:

 

sc_simcontext.cpp:541
  m_cor_pkg->yield( thread->m_cor_p );

  sc_cor_qt.cpp:202
    QUICKTHREADS_BLOCK( sc_cor_qt_yieldhelp, old_cor, 0, new_cor->m_sp );
 
    iX86_64.s:50
      after executing 'pushq %rdx       /*  2 ... (arg) */'
      programm jumps to

      iX86_64.s:59
         call *%rax      /* call function to save stack pointer. */

Debugger reports:
Program received signal SIGSEGV, Segmentation fault.
qt_blocki () at qtmds.s:59
59        call *%rax      /* call function to save stack pointer. */
 

 

Furthermore, I observed that in the moment of the seg fault, the content of %rax is 0x8000 which seems to be an odd number for an address to be called. %rdi is 0x8000 when entering the ASM part. Maybe something bad happens with the arguments in the transition to ASM.

 

Maybe someone knowing a bit more about these things and what should happen here can help?

 

Greetings

Ralph

[isbelen]

I also have the same issue:

Debugger reports:
Program received signal SIGSEGV, Segmentation fault.
qt_blocki () ...

Somebody found a solution?

[AmeyaVS]

On 12/22/2016 at 7:28 PM, isbelen said:

I also have the same issue:

Debugger reports:
Program received signal SIGSEGV, Segmentation fault.
qt_blocki () ...

Somebody found a solution?

Hello isbelen,

Kindly look into the post I made earlier of enabling "--enable-pthreads" while configuring the SystemC library.

Currently the Cygwin 64-bit SystemC library build is non-functional with Quick Threads Library for user space threading.

Also, kindly refer the post discussing the same from Mr. @Philipp A Hartmann and Mr. @ralph.goergen.

Regards,

Ameya Vikram Singh

[mo_ayman]

So, what's the expected way to be used to enable SC_THREAD on Windows 64 bit?

 

I have ran into this issue which was crashing in the call *%rax. After some investigation, I knew that as opposed to Linux on Windows different registers are used for the parameters passed to functions.

On Linux 1st to 4th parameters are: rdi, rsi, rdx, rcx

On Windows 1st to 4th parameters are: rcx, rdx, r8, r9

 

So, I modified iX86_64.s according to the info above and the call *%rax was executed successfully.

I however faced another issue which was that the leave instruction did nothing (the stack wasn't actually unwound and 0x0 was what is left on the stack): 

So, after the ret instruction it crashed as it tried to execute 0x0 which is not possible.

[AmeyaVS]

Hello @mo_ayman,

Would it be possible to share the changes you have done on the official systemc github repository as a pull request?

That would be a better alternative to get the fixes in somewhat faster.

Regards,

Ameya Vikram Singh

[mo_ayman]

Hello @AmeyaVS,

Yes, for sure this is possible. I would be glad to do such thing. Point is what I have done hasn't 100% fixed the issue. So, that doesn't count as a fix.

If I reached a fix, I will gladly share it on the SystemC github.

 

On 5/7/2020 at 6:24 PM, mo_ayman said:

I however faced another issue which was that the leave instruction did nothing (the stack wasn't actually unwound and 0x0 was what is left on the stack): 

So, after the ret instruction it crashed as it tried to execute 0x0 which is not possible.

I was hoping someone would be able to help me with that part which is basically the second part of the issue.

 

Thanks

[AmeyaVS]

Hello @mo_ayman,

Well you could get it early for review comments from the people in SystemC LWG.

Plus people with similar setup to yours can also take a jab at it in getting it fixed.

Regards,

Ameya Vikram Singh 

[maehne]

I agree with @AmeyaVS that it would help if you could share the current state of your modifications in form of a .diff file in this forum or as a work-in-progress pull request on the public SystemC repository on GitHub. Then more people can have a look to maybe suggest a fix for the second half of the issue. It would be great if this long-standing issue regarding QuickThreads on Cygwin64 could be finally fixed.

[maehne]

For the record, @mo_ayman posted about the current state of his fixes to QuickThreads on Win64 in this separate thread.