I am getting the below error when using the gdb command run group3.
I installed gdb on Windows Bash as well as an Ubuntu VM on Virtualbox and am getting the same error.
Some important notes:
This program worked at my school using Cent OS 7
I tried changing the file to have a .exe file extension but that didn't work. It should not require a file extension because it worked at my Uni without one.
This program worked at my school using Cent OS 7
Did you use ftp to copy this program into VM?
Chances are you did the transfer in ASCII mode, corrupting the binary in the process.
You can verify this has happened by running md5sum group3 on both systems. If my guess is correct, the checksum will be different.
Use binary mode FTP instead, or use scp.
I ended up corrupting my 64 bit Ubuntu VM when running out of space when trying to install the i386 packages. I ended up installing a new 32-bit Ubuntu VM and the program ran on that successfully.
Related
Everytime i try to run a program it says launch program does not exist here is my json file
I thought it will run but it doesnt I even followed some solutions but they didnt work i have homebrew installed and all the neccesary extensions in vscode.
I'm porting a c++ program from Unix to Win7. The program only does some background computing tasks, it's a command line program. So I use build the program on cygwin with g++ on a 32bit win7 VM.
My target system is a 64bit win7 physical PC. After I copied my program to the target PC, it always fails at a system() call. I need to use system() to run a curl command. This works on my 32bit win7 VM, but always fails on the target 64bit win7 PC.
You may guess if curl command has problem. I would say no. Because I can manually run the curl command from a cmd window. I also tried to system("dir"), it also fails with same error.
On 64bit win7 PC, system() always return 127, error is "Permission denied". Does anybody have idea what the problem is.
Two points. 1) Use a 64-bit VM to build a program for a 64-bit physical machine. You must have a 32-bit or 64-bit cygwin installed on the physical machine to provide the cygwin1.dll with the bitness required by the exe. Use the mingw32 or mingw64 version of the g++ compiler if you don't want to install cygwin on the physical machine. Use the cygwin file command to check the bitness of the exe and to check if it is a cygwin or mingw exe.
2) The windows API provides for a 8-bit return code from a child process to its parent. Using 0 to 127 avoids specifying if the code is signed or unsigned. BTW, there is not dir.exe, it is part of command processor, e.g cmd.exe.
I have a system that has a set of Self-encrypting drives (SEDs) with OS (Ubuntu on one and CentOS on the another and rest blank) installed on each of them. I'm trying to write an application that allows me to 'lock/unlock' the drives using TCG security commands. So when I'm in ubuntu, I lock all the other drives; and when I am in CentOS I lock the Ubuntu OS disk.
My problem right now is, from Ubuntu how do I figure out which disk (sda /sdb/ sdc ???) the current running kernel is sourced. It needs to be a generic logic so that the technique works for a ubuntu / ubuntu installation pair, hence just detecting the centOS partitions will not help.
Any help will be appreciated.
I have written a simple C++ program that I am compiling using g++ in command prompt and also running it through command prompt. The code of my program is as follows:
#include<iostream>
int main()
{
std::cout<<"Hello world"<<std::endl;
return 0;
}
When I run this code. I get a "hello_world.exe has stopped working" kind of error on my office machine. But when I run the same portion of code at home it works fine. Any idea why this is happening? Also, if I remove std::endl it works fine.
I am using Notepad++ to code.
UPDATE: I am not running the same binary on both machines. I compile on both the machines separately. I am using windows 7 32-bit at both the locations. I am using mingw. For compiling I type "g++ hello_world.cpp -o hello_world.exe". For running I typed "hello_world.exe". I downloaded mingw from the site mingw.org and used the "mingw-get-setup.exe" to install. And I installed g++ and gcc through the command prompt using the command "mingw-get install gcc g++".
When you return from main(), your program stops working. In a gui-based environment, I wouldn't be surprised to see a pop-up message warning about a terminal-based application reaching completion where the user has to click "dismiss" before the terminal spawned to support the application is terminated as well. Windows 9x used to have such checkboxes in launcher preferences for MS-DOS programs.
Questions you should use to find out the issue are:
- Is it showing the same error message if you launch the shell yourself ?
- Do you use the very same binary on both machine, and if so, are your machines both capable of running it (e.g. not trying to launch a 64-bit binary on a 32-bit OS as one of the case)
It would help to see the exact text of the error message.
Your program depends on C and C++ runtime libraries. I suspect you have the libraries installed on the machine where it works and don't where it doesn't, probably because you installed Visual Studio on the machine where you wrote the code but not on the machine where you're trying to run it.
You can install the runtime libraries on the second machine by search Microsoft Download for vcredist for the version of Visual Studio that you compiled the program with.
Works fine for me on Windows 7 32-bit using MinGW. I suspect that you've not installed all the components you need to run the program. I would re-install MinGW and Msys and be sure you install all the necessary C and C++ components.
g++ --version
g++.exe (GCC) 4.6.2
a.exe
Hello World
I have used MinGW and Msys on Windows for many years (several different versions) and have never had issues compiling, linking or executing standard C and C++ programs.
I am trying to compile Vowpal Wabbit on a Windows 7 machine and after trying Netbeans, Cygwin, and MinGW I'm starting to wonder if I'm trying something that's even feasible.
Each of the above has required **.h files that aren't designed for windows such as sys/socket.h.
Anyone that has actually done this, I would appreciate any suggestions.
Run cygwin's setup.exe, type "boost", click on "Default" several times until it changes to "Install", proceed with installing boost library from cygwin.
Download latest Vowpal Wabbit and extract to you vw directory.
Open cygwin and go to that vw directory, where Makefile is(cd .. (see #home) cd vw_dir)
In cygwin command prompt type "make"
After that you can close cygwin, and use cmd to run vowpal.
I took this from a kaggle forum:
"
I managed to compile VW under Windows 7 64 bit without Professional Visual Studio 2010.
You can do it by using Cygwin ( http://www.cygwin.com/ ).
first of all install Cygwin on your computer: just choose the standard configuration
run Cygwin shell and enter : git clone git://github.com/JohnLangford/vowpal_wabbit.git
after the download have completed write: cd vowpal_wabbit
at this point you can run the command: configure
the configure procedure will point out all the libraries which are missing from your system and that you should install by running again the Cygwin setup
after some iterations of point 5 you will have finally provided all the necessary libraries to Cygwin, and you can run the command: make
7 after the compiler will finish the make of vw.exe, run: make test in order to check if everything is all right with your build.
Now you can start using VW under Windows, just open a shell and try it.
"
Another update, binary releases for Windows is now available since 21 June 2016. The latest link as of today is: https://github.com/eisber/vowpal_wabbit/releases/tag/v8.2.0.6
It's available in MSI installer file.
(In case you encounter dead link in the future, please find most recent version from the eisber's github repo.)
John Langford recently made a post to the VW mailing list saying a Windows port was in progress, but still broken in certain respects. I would suspect that it currently is not possible to get VW running on windows (but I haven't actually tried)
From this thread:
Chris Quirk created a windows port for VW, which is now in the
distribution. It's still incomplete: networking and threads are
problem points.
I managed to build on 64bit win without cygwin, native windows. Took a long time to set up env for the build so I wrote a blog about it. I know that self promotion is frowned upon but this link has the binary I built on my machine, guaranteed to work on only my machine but anyone is free to try it out.
An update for curious googlers: the VW Windows instructions have recently been updated, and if you get the most recent source you should be able to compile on Visual Studio without major hurdles (I have tried successfully): https://github.com/JohnLangford/vowpal_wabbit/blob/master/README.windows.txt