I installed frama-c Magnesium version using instruction provided here. I didn't get any error during installation and executing command frama-c -versionin Cygwin printed Frama-c version as: Magnesium-20151002. But when I executed -wp plugin on a very small example, for the goals which used alt-ergo, I get following errors:
1 [main] frama-c 8168 child_info_fork::abort: unable to map C:\cygwin\usr\local\lib\frama-c\plugins\Users.cmxs, Win32 error 998
1 [main] frama-c 7956 child_info_fork::abort: unable to map C:\cygwin\usr\local\lib\frama-c\plugins\Value.cmxs, Win32 error 998
0 [main] frama-c 300 child_info_fork::abort: unable to map C:\cygwin\usr\local\lib\frama-c\plugins\Value.cmxs, Win32 error 998 [wp] [Alt-Ergo] Goal typed_changeCase_assert_rte_signed_overflow_2 : Failed
Error: Resource temporarily unavailable
Value plugin executes successfully. I searched the error and found this post. So I also executed rebaseall -v command, but that too didn't help. To confirm that my Cygwin is not corrupted I installed Frama-c Sodium version again and was able to execute WP plugin successfully.
Can anyone help me fix this issue, we want to be able to use Frama-c Magnesium version on Windows?
Edit: Machine details:
I tried it on my computer and also on a VM. On VM, I executed commands ./configure && make and make install to install frama-c Magnesium.
I have 32 bit Cygwin on both machine. Both Windows are 64-bit.
Ocaml version on my machine: 4.02.3, Ocaml version on VM: 4.01.0
Cygwin version on my machine and on VM: CYGWIN_NT-6.1-WOW64 1.7.27(0.271/5/3) 2013-12-09 11:57 i686 Cygwin
At the time Frama-C Magnesium was released, alt-ergo 1.01 did not exist yet. So when the WP manual for Magnesium mentioned compatibility with alt-ergo 0.99.1+, it could not foresee that there would be an incompatibility with the then future release of alt-ergo.
Fortunately, the next release (Aluminium) will be compatible with alt-ergo 1.01, so this should not be a problem in the future.
Meanwhile, you should be able to use alt-ergo 0.99.1.
Edit: Based on the error message and further details, it could be related to your Cygwin version, which seems relatively old, from 2013; yours is 1.7.27, while I'm using 2.4.1.
Related
On new HP tower G4 workstation with Xeon E2224G processor, Windows 10 pro for wokstations OS build 19042.746.
install netbeans 8.2
Install msys2_64 and mingw64
set path e:\msys64\usr\bin; e:\msys64\mingw64\bin; %PATH%
Verify that make,sh,bash,rm and more are in e:\msys64\usr\bin
configure netbeans for C project and try to clean and build and get this error:
'No shell found. Cannot proceed. Please install either CYGWIN or Msys.'
OK then, install cygwin.
Now get this error:
'1 [main] rm (7980) E:\cygwin64\bin\rm.exe: *** fatal error - cygheap base mismatch detected - 0x180345408/0x180347408.'
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
cygcheck -c gives
base-cygwin 3.8-1 OK
base-files 4.3-2 OK
cygwin 3.1.7-1 OK
I have searched and there is only one cygwin1.dll
frank#FRANK_NEW ~
$ which cygwin1.dll
/usr/bin/cygwin1.dll
I have restarted the machine several times to no avail.
I have been using netbeans and mingw then msys/mingw for about 10 years and
have the combination working on other desktop and laptop machines, but have
not had this problem.
Thanks for the replies above. The problem here is the different ways that PATH is handled by Windows 10 Pro and Windows 10 Pro for Workstations.
For Win10 Pro
define a user variable 'MSYS_HOME' give it a value of 'E:\msys64\usr\bin'
now put that in the system path i.e.
some system path;%MSYS_HOME%;more system path
Netbeans will find the tools rm, sh, make, etc and complete the clean and build of the project.
for Win10 Pro for Worksations
the above did not work. Netbeans would not build the project and give the error
'No shell found. Cannot proceed. Please install either CYGWIN or Msys.'
the path has to be set in the system path directly i.e.
some system path;E:\msys64\usr\bin;more system path
this made Netbeans work correctly to perform clean and build.
So I've upgraded to a newer version of Linux kernel using Yocto. The new kernel version is for 4.1.15 and runs on an iMX6 chip. I've also included openssh-server, tools-sdk, and tools-debug for development recipes. The problem is that when I connect to build I get the following error:
loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof
(_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))'
failed
Now if I type into the command prompt sh -c "LANG=en_US" I get the same error as above. If I type in sh -c "LANG=/usr/lib/locale/en_US" then I do not get an error. When I type locale everything is listed as POSIX and when I type locale -a I get:
C
POSIX
en_GB
en_US
The last two are stored under /usr/lib/locale. My version of gcc is 5.2 and my glibc is v2.22. I've looked all over the internet for other solutions but they are either for Ubuntu where the package manager comes in handy or it's some really specific fix like editing a file that I don't have in my Yocto build.
Edit:
The machine is for a SMARC-FiMX6 SoM and the instructions are here. I'm not sure what branch of Yocto is being pulled down.
After troubleshooting the problem is from the glibc library. A patch, #114739, is on the openembedded website which details what to do to fix this issue. Just patch the file, rebuild, and the issue is fixed. See here for details, the patch is at the bottom of the page.
I am a newbie working with Cygwin and CUnit. I have to develop some Unit Tests using CUnit and Netbeans and I have followed the next tutorial:
https://netbeans.org/kb/docs/cnd/c-unit-test.html?print=yes#project
At the end, when I was trying to run the first example test I got stocked by an error:
0 [main] make 4380 C:\cygwin\bin\make.exe: *** fatal error - error while loading shared libraries: /cygdrive/C/Program Files/NetBeans 8.0.2/ide/bin/nativeexecution/Windows-x86_64/unbuffer.dll: cannot open shared object file: Exec format error
448 [main] make 4380 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
I don't know if this has relation to the Cygwin version I have, I have a computer running Windows 7 Enterprise 64bits edition. I have configured my C project to use Cygwin 64bits edition...
Could you please share any idea about how I can solve this?
Thanks!
I had a similar issue, but in my case I was trying to run CppUnit tests in Netbeans. I was using make provided by MSYS2 and it was failing to load unbuffer.dll, but error was "No such file or directory". I switched the make from MSYS2 for the one found in MSYS and the error went away. You could try this as a workaround.
I found sole here:
https://bz.apache.org/netbeans/attachment.cgi?id=164026&action=edit
Need download new version of unbuffer.dll.
Yar
Here is an issue I've worked around by simply not using Eclipse for debugging, but it's getting out-of-hand.
I've used Eclipse Helios, Juno and Kepler over the last year and they all display exactly the same problem when I try to debug a local C/C++ application.
When I try to debug, it simply reports the error "Error while launching gdb --version".
gdb is in my path, but to be sure, I change the Debug settings to list the path explicitly. If I do that, I simply get "Error while launching /usr/bin/gdb --version", which is no better.
I'm using Scientific Linux version 6.4 (as required by my customers) and currently, I'm trying to use Eclipse Kepler. Running from the command line, gdb has no problem reporting it's version:
# gdb --version
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
[... licensing info]
Please, please let me know how to fix this as I have spent weeks working at only a fraction of the rate I would expect because I'm not utilizing an integrated development environment, but using separate tools.
I've seen other similar posts, but they are either
(a) about Windows / MingW - although I've tried their ideas anyway, just in case they work.
(b) don't have any answer provided.
As Scientific Linux is a RedHat derivative, I expect RHEL or CentOS information would be as relevant for me.
I've compiled a C program under Ubuntu 12.04, built a Debian package out of it, and want to install it on a server running Debian Lenny.
Last time I did that (about two months ago) it worked: I could install the package and run the binary. But now I get the following error message:
(binary's name): /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by (binary's name))
Other than upgrading my machine to Ubuntu 12.4, the only significant change we've brought to the code is a call to strdup(), for which I had to enable the _POSIX_C_SOURCE=200809L feature test macro.
Upgrading the server to the latest Debian version is not my preferred option as it is not under my direct control.
How do I fix this problem?
I think the critical bit of info here is 'upgrading my machine'. So when this worked before, you were building and packaging on something earlier than 12.04? If so, then the issue is that 12.04 now ships with a newer version of libc (apparently 2.14), and your binary now records a dependency on that version of libc. When you try to run on Lenny, which likely uses an older version of libc, the linker detects that the Lenny version does not support the 2.14 API, and fails.
I think the best way forward is probably to do your development and testing on 12.04, and then when you want to create packages for a specific Debian release, use pbuilder or similar to create debs. This will ensure that the libraries used for the packaging build match the target platform.