I have this project that I've been doing. On WSL, when I compile, there seem to be no issues. Everything works well and good.
However, I need the compiled code in a .exe format so I can run it on windows and call it within a Python code.
I have installed flex, bison and MinGW (from mysys2) and all of them have been added to my path/environment variables.
I have ran command prompt as Admin as well to avoid any permissions issues that may have come up.
In this image, flex command works without hitches and produces the lex.yy.c file as expected. However, g++/gcc command does not show any error. Neither does it produce the .exe file
Over here, I have compiled with -ll appended to the statement, and once again the same result.
Note: It took significantly longer to compiler with -ll appended than without. Not sure if this is significant information.
I found a thread(g++ does not make any file or give any output) where someone addressed the same problem but there was no proper solution that has worked.
Does anyone know a solution or what the problem could be? Any help would be appreciated.
Related
For some time I didn't compile/run my programs using g++ in cmd and I only used CodeBlocks where I didn't have any problems so I don't know when this started.
So I tried to run a program that I compiled with 'g++ main.cpp' and it either wouldn't run at all, like nothing happened, or this would pop out.
From a not so related answer in google I found that adding the -static-libstdc++ flag would fix this but I don't want to do this every time and the OCD in me wants to know why this is happening.
P.s. As mentioned in the title this only happens when the program has the string type in it. I also tried reinstalling Mingw but no luck.
As #n. 'pronouns' m instructed in the comments, I checked my %PATH% and found LyX, a Latex document processor which I don't even remember using, which for some reason also had the libstdc++-6.dll file. I uninstalled it and that fixed it.
I am trying to use EXECUTE_COMMAND_LINE (Fortran) in Code::Blocks to start a program through a shortcut with the Windows command prompt. I have checked the path and the syntax several times, and everything is correct, however whenever I compile and run the code, when the script reaches this command I get an error saying that "The specified path does not exist. Check the path and then try again.".
Even more peculiar is the fact that, using the exact same command within the EXECUTE_COMMAND_LINE directly in the command prompt successfully launches the application with no problems whatsoever.
The command I use is the following:
CALL EXECUTE_COMMAND_LINE("start C:\Users\dimpa\Desktop\Giannako\Optimization\VBA\SLDA.lnk")
I run Windows 10, Code::Blocks 20.03 and have the MinGW compiler for Fortran.
Have also used SYSTEM with exactly the same results. Also, if it is to any use helping me figure out what is going on, this command works just fine:
CALL EXECUTE_COMMAND_LINE("start C:\Users\dimpa\Desktop\Giannako\Optimization\VBA")
Opening the folder VBA to my File Explorer. The problem seems to be related with opening the shortcut of the application. Further more, opening files located in dimpa\Appdata folder (original .exe, not the shortcut) seems to be working even through the IDE, where anything in Program files is inaccessible.
Thanks in advance.
Cheers, after endless experimentation, I seem to have found a workaround.
The problem was revolving around spaces being included in the path of the original program of the shortcut in use. Apparently the compiler isn't fond of executing shortcuts, which might initially not contain spaces in the initial path, but when redirected to the original program can run into all sorts of things.
The shortcut that I was trying to execute contained a path leading into Program Files and opened an additional addon to be executed in the aforementioned program ("/m"). After realizing that trying to run a shortcut with a 150 string length target could complicate things, I directly entered the target of the shortcut into the Windows cmd, which worked perfectly fine and was much more easier to dissect and be examined in order to properly write the code:
CALL SYSTEM(""Full Path to Program" "/m" "Full Path to Addon"")
Hope this helps someone facing similar issues!
I'm working on a project for my cryptography course, and I've been using the Windows Subsystem for Linux. Up until recently I was able to use make -j to build my entire project quickly.
Recently, I started getting compilation errors like the one below. Strangely enough, I have no issues compiling with just make (no -j)
Because this used to work fine, I do not believe the issue has anything to do with dependencies specified in my makefiles. (Most of my code is in header files anyway because templates)
In file included from /usr/include/stdlib.h:314:0,
from /usr/include/c++/5/cstdlib:72,
from /usr/include/c++/5/ext/string_conversions.h:41,
from /usr/include/c++/5/bits/basic_string.h:5249,
from /usr/include/c++/5/string:52,
from tests/cryptomath/../../catch.hpp:207,
from tests/cryptomath/test_extgcd.cpp:2:
/usr/include/x86_64-linux-gnu/sys/types.h:219:25: fatal error: /home/ipiano/[student id]/Documents/Code/Homework/512/project/modules/module_crypto/unittests/../libclassiccrypto/affine/headers/sys/select.h: Invalid argument
It looks to me like the compiler is trying to find c++ source files (sys/select.h in this specific error) in my project directory, which implies maybe a path issue?
The only thing that I can think of that changed recently is that IT approved the Creator's Update and I installed that, but I don't know if it's relevant or not.
If anyone has seen this behavior or errors like this and knows how to resolve it, help would be appreciated.
---------EDIT---------
Was able to narrow down to a specific makefile that my main makefile was including. It was defining part of it's targets, but not all of them. Still not sure why the -j flag brought this to light, but at least it's working now
I had the same problem: my compilation failed when using "make -jN", for N>1. After some research I found the same issue described here.
The problem is likely caused by a bug introduced in DrvFs, the Windows filesystem plugin for WSL, and it happens at least in Windows builds 16273.1000, 16299.19 and 16299.64 (mine). It doesn't happen in build 16251.
According to this, the bug was fixed on Windows Build 16299.98.
Since I cannot update my Windows due the company policies and I couldn't execute this workaround, I moved my files from /mnt/c to /home/<username> and they compiled without further problems.
I've done some googling and everything already but none of the solutions online exactly match my situation. So I have one project which has the files
Main.cpp
BankAccount.hpp
BanckAccount.cpp
GoCardAccount.hpp
GoCardAccount.cpp
And when I compile it, it is completely fine. But running it gives me the following image:
The things I have tried:
Reinstalling MinGW
Putting the libstdc++6.dll in System32
(The only thing that works) putting the libstdc++6.dll in the project directory.
I feel like this is not the best option. Especially since if I write a small "Hello World" program, then the error does not appear.
Is there any way of actually fixing this?
I'm currently running a variant of Eclipse known as WindRiver, which is designed for embedded systems programming using C++ (specifically, I'm part of my high school's FIRST Robotics team).
I'm able to successfully compile and build the project from within Eclipse (Project > Build Project) but I'm looking for ways to automate this process by compiling by using the command line.
The project already contains a makefile and everything, so ideally I want to be able to just run that without making any manual changes. I pastebin'd the makefile in case its relevant.
Does anybody know where I can find more information on compiling C++ programs from the command line for either Eclipse or WindRiver or on running makefiles on Windows? I tried looking at "How to run a makefile in Windows?" but following the first answer didn't work (it gave a syntax error for the makefile).
I'm currently using a Windows 8 laptop. As best as I can tell, the current varient of WindRiver I'm using is based on Eclipse version 3.3.1.
You will need a make utility, I believe your WindRiver / Eclipse setup would come with "gnumake" (probably called either make or gmake). You'd nee dto set up the command line path to lead to the compiler and the make executable. Unfortunately, this is not a great answer, as I can't give you exact links to the make and compiler locations (it would of course also depend on where you installed things). I just thought I'd lead you somewhat on the right path, since the question has been up for a little while and no one jumped at it.
Thanks to Mat Petersson's answer, I was able to identify everything I needed and create a batch file that could compile the file for me:
#echo off
setlocal
set PATH=%PATH%;C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\bin;C:\WindRiver\utilities-1.0\x86-win32\bin;C:\WindRiver\setup\x86-win32\bin
set WIND_BASE=C:\WindRiver\vxworks-6.3
cd My_Project\PPC603gnu
make --no-print-directory BUILD_SPEC=PPC603gnu DEBUG_MODE=1 TRACE=1