I'm fairly new to programming in AS7, I've only programmed a few things in assembler but wanted to see if the mplab snap could program the MCU in C, but I just haven't found a way around it (this pops up when I start debbuging). Whenever I try to build an error "recipe for target '...' failed" shows up, be it in an XC8 or a GCC project.
#include <avr/io.h>
int main(void)
{
/* Replace with your application code */
while (1)
{
}
}
Even if the code does absolutely nothing, so I take it it's not because of the code, I suppose.
------ Build started: Project: GccApplication3, Configuration: Debug AVR ------
Build started.
Project "GccApplication3.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in the file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from the project "C:\Users\Julio\Documents\Atmel Studio\7.0\GccApplication3\GccApplication3\GccApplication3.cproj" (target "Build" depends on it):
Using "RunCompilerTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
Task "RunCompilerTask"
Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 4 --output-sync
C:\Users\Julio\Documents\Atmel Studio\7.0\GccApplication3\GccApplication3\Debug\Makefile(106,1): error: recipe for target 'GccApplication3.elf' failed
make: *** [GccApplication3.elf] Error 1
Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "GccApplication3.cproj" -- FAILED.
Done building project "GccApplication3.cproj" -- FAILED.
Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
that's the output I usually get from it, and the line of the makefile which it makes reference to (106,1) is
#echo Building target: $#
that I personally don't know what it means or if it should allude to that line in general.
I've attempted to fix it by making a clean reinstall and tried a couple of older versions to see if it might work but it always comes down to the same error. The only files that are inside the Debug folder are the 'main.d' 'main.o' 'makedep.mk' and the 'makefile'. I probably didn't set something that was important right from the beginning so if anybody knows something I'd be pleased.
(I don't even know how to read a makefile yet so there's that)
Related
I download iasl 20190509 version in Ubunt18.04.5 LTS.
When I use "make iasl" command to build the package, I get this error:
$ make iasl
make[1]: Entering directory 'acpica-unix2-20190509/generate/unix/iasl'
- bison obj/aslcompiler.y
acpica-unix2-20190509/generate/unix/iasl/obj/aslcompiler.y:1.1: error: syntax error, unexpected end of file
mv: cannot stat 'obj/AslCompiler.LLW4kB/y.tab.h': No such file or directory
Makefile:322: recipe for target 'obj/aslcompiler.y.h' failed
make[1]: *** [obj/aslcompiler.y.h] Error 1
make[1]: Leaving directory 'acpica-unix2-20190509/generate/unix/iasl'
generate/unix/Makefile.common:7: recipe for target 'iasl' failed
make: *** [iasl] Error 2
Please help me fix this error.
Please help me build iasl.
The solution was to retry the make but making sure that the build directory is clean first:
$ make clean && make
Here's my best guess as to what happened:
An attempt was made to build the software package.
That attempt failed because the m4 tool had not previously been installed.
OP installed m4, and reran the build with make.
Because of an inadequacy in the provided Makefile, make did not attempt to run m4 again. (See below.) Consequently, processing of the file supposedly generated by m4 failed.
This software package relies on m4 to create the source for bison by interpolating various component files. (Yacc/Bison doesn't have an include feature, so m4 is the usual solution.) However, the command to run m4 is roughly (with paths simplified):
$ m4 aslparser.y > aslcompiler.y
When the shell executes this command, it creates or truncates aslcompiler.y
before even attempting to invoke m4. If it turns out that m4 can't be found, or if m4 produces some sort of error, you end up with an empty or partial output file.
The make target aslcompiler.y is satisfied by this artefact, since make only cares that the target was created later than its dependencies. So the next invocation of make goes on to the next step (bison aslcompiler.y), which fails because aslcompiler.y is empty.
The Makefile would have been better written to use a command like:
$ m4 aslparser.y > /tmp/aslcompiler.y && mv /tmp/aslcompiler.y aslcompiler.y
in order to avoid creating the target if m4 failed. Of course, that's not your responsibility. It could be reported as a bug to the iASL project. (The Makefile already uses this strategy to safely handle the files generated by Bison, so it's not really anything new.)
I have this project on a subject 'Languages and Compilers' Where we write parsers in Haskell. At the moment I'm working on this 2-Arrow project where we use the 'alex' and 'happy' libraries to create a parser.hs and lexer.hs file from a lexer.x and parser.y file. While trying to build my framework (cabal build in the project directory) I get the following error message:
C:\\ ... \2-Arrow\dist-newstyle\build\x86_64-windows\ghc-9.2.4\assignment-arrow-0.1.0.0\x\arrow\build\arrow\arrow-tmp\Lexer.hs:1:1: error:
`gcc.exe' failed in phase `C pre-processor'. (Exit code: 1)
|
1| {-# OPTIONS_GHC -fno-warn-unused-binds -fno-warn-missing-signatures #-}
| ^
C:\\ ... \2-Arrow\dist-newstyle\build\x86_64-windows\ghc-9.2.4\assignment-arrow-0.1.0.0\x\arrow\build\arrow\arrow-tmp\Parser.hs:1:1: error:
`gcc.exe' failed in phase `C pre-processor'. (Exit code: 1)
|
1 | {-# OPTIONS_GHC -w #-}
| ^
If they were error messages originating from the code I wrote I would at least have a direction to look for solutions, but these errors come from the /dist-newstyle/ folder. Which, in my understanding, is a folder for intermediate files used in building the program. So I'm kind of at a dead end at the moment, since reinstalling 'happy' and 'alex', and updating cabal to latest version all did not change anything. Does anyone have any advice for resolving this error? Any help is greatly appreciated!!
(project framework from uni: https://www.cs.uu.nl/docs/vakken/b3tc/downloads-2018/2-Arrow.zip (depends on 'happy' and 'alex' packages). At first I thought the problem could lay in the framework, but I checked with the professor, he stated that others had no issues, so I don't think that's the problem)
I wasn't able to duplicate the problem with a fresh GHCup installation on Windows 10, but the error message suggests there might be an issue with an installed version of the GNU C Compiler (GCC) which the Glasgow Haskell Compiler (GHC) invokes to apply the C pre-processor to certain Haskell source files, including the Lexer.hs source file that's being generated by Alex from the Lexer.x file, and the Parser.hs source file that's being generated by Happy from the Parser.y file.
Try creating a simple test.hs program that invokes the C pre-processor:
{-# LANGUAGE CPP #-}
#define HELLO "Hello, world!"
main = putStrLn HELLO
and try compiling with ghc test.hs. Assuming that fails with the same error as above, try ghc -v test.hs, and you should find lines in the output starting with:
*** C pre-processor
"C:\...\gcc.exe" "-E" "-undef" ...blah blah blah...
An excerpt from my successful compilation follows. Maybe you can spot what's going wrong with your installation. Note that mine invokes the GHCup-installed version of GCC and directs the output to a temporary file area where it's then compiled by GHC. If the wrong GCC is invoked or the temporary file area isn't writable for some reason, that might lead to the problem you're seeing.
*** C pre-processor:
"C:\ghcup\ghc\9.2.5\lib\../mingw/bin/gcc.exe" "-E" "-undef" "-traditional" "-IC:\ghcup\ghc\9.2.5\lib\x86_64-windows-ghc-9.2.5\base-4.16.4.0\include" "-IC:\ghcup\ghc\9.2.5\lib\x86_64-windows-ghc-9.2.5\ghc-bignum-1.2\include" "-IC:\ghcup\ghc\9.2.5\lib\x86_64-windows-ghc-9.2.5\rts-1.0.2\include" "-include" "C:\ghcup\ghc\9.2.5\lib\x86_64-windows-ghc-9.2.5\rts-1.0.2\include\ghcversion.h" "-Dmingw32_BUILD_OS" "-Dx86_64_BUILD_ARCH" "-Dmingw32_HOST_OS" "-Dx86_64_HOST_ARCH" "-D__GLASGOW_HASKELL_TH__" "-D__SSE__" "-D__SSE2__" "-D__IO_MANAGER_WINIO__=1" "-D__IO_MANAGER_MIO__=1" "-includeC:\Users\buhr\AppData\Local\Temp\ghc7128_0\ghc_2.h" "-x" "assembler-with-cpp" "test.hs" "-o" "C:\Users\buhr\AppData\Local\Temp\ghc7128_0\ghc_1.hscpp"
!!! systool:cpp: finished in 31.25 milliseconds, allocated 0.311 megabytes
!!! Chasing dependencies: finished in 46.88 milliseconds, allocated 2.719 megabytes
Stable obj: {}
Stable BCO: {}
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2022-12-18 20:54:57.2679991 UTC
ms_mod = Main,
ms_textual_imps = [(Nothing, Prelude)]
ms_srcimps = []
} []]
*** Deleting temp files:
Deleting: C:\Users\buhr\AppData\Local\Temp\ghc7128_0\ghc_2.h
compile: input file C:\Users\buhr\AppData\Local\Temp\ghc7128_0\ghc_1.hscpp
*** Checking old interface for Main (use -ddump-hi-diffs for more details):
[1 of 1] Compiling Main ( test.hs, test.o )
I went to my seminar and asked the TA for help. After some time he proposed that maybe the folder location was the problem. Lo and behold, after moving the folder from my OneDrive folder (which is also saved locally) to my C:\\ directory, the project finally compiled! I have no idea why this would be the case, so I have posted another question here Folder location makes Haskell project incompileable.
I have never used Codelite and am attempting to use it as apart of a requirement for "C Programming for Beginners" course on UDEMY.
I am using a Macbook PRO OS version 10.14.5 and Codelite version 14.0.0.
I have created a workspace called SampleApp and within lies a project called Sample with a src file and a main.c file.
The main. c file contains the following code:
#include <stdio.h>
int main()
{
printf("Hello, my name is Link\n");
return 0;
}
When I build the code I get the following output:
/bin/sh -c '/usr/bin/make -j8 -e -f Makefile'
====0 errors, 0 warnings====
Working directory is set to: /Users/link/Desktop/c_code/build-Debug/lib
Executing: open -n -a Terminal /tmp/codelite-exec.sh
Program exited
Unfortunately though, when my terminal pops up I get the following error message:
22:37:07-link#links-MacBook-Pro:~$ /tmp/codelite-exec.sh ; exit;
/tmp/codelite-exec.sh: line 3: cd: /Users/link/Desktop/c_code/build-Debug/lib: No such file or directory
Hit any key to continue...
I am unsure of how to debug this or get this program to run as it appears the target and or the executing directory is not set properly. Kindly advise, thank you.
** UPDATE **
There is no lib folder within /Users/link/Desktop/c_code/build-Debug/lib .. perhaps that's why the code in /tmp/codelite-exec.sh is not working.. Below shows /tmp/codelite-exec.sh - line 2 attempts to change directories to the lib folder and execute the Sample workspace but the lib file doesn't exist..
#!/bin/bash
command="/Users/link/Desktop/c_code/build-Debug/bin/Sample"
cd /Users/link/Desktop/c_code/build-Debug/lib && ${command}
echo Hit any key to continue...```
I've just run into the same problem trying to build a simple wxWidgets HelloWorld with CodeLite before I do anything serious with it. It turns out that this is caused by a default project setting. Open the settings (by right-clicking on your project and selecting settings at the bottom, in case you haven't found this yet). In the General page, find the Execution group and look for Working Directory. It defaults to "$(WorkspacePath)/build-$(WorkspaceConfiguration)/lib", which is pretty silly since that won't be created by default. I changed "/lib" to "/bin" and that error went away.
This is my first question, so I'll try to explain everything about my problem. So, I had downloaded Clion to code my first C programs for my university degree. So, when I create a simple Hello World on C, I can run normally, but if I create a new program or a new hello world, the program fails with the following error on Clion:
> ====================[ Build | MeusCodigosC_2_0 | Debug ]======================== "C:\Program Files\JetBrains\CLion
> 2020.2.1\bin\cmake\win\bin\cmake.exe" --build "C:\Users\salom\CLionProjects\MeusCodigosC 2.0\cmake-build-debug"
> --target MeusCodigosC_2_0 -- -j 12 Scanning dependencies of target MeusCodigosC_2_0 [ 33%] Building C object
> CMakeFiles/MeusCodigosC_2_0.dir/AtividadeProducaoLabU2.c.obj [ 66%]
> Building C object CMakeFiles/MeusCodigosC_2_0.dir/HelloWorld.c.obj
> [100%] Linking C executable MeusCodigosC_2_0.exe
> c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe:
> CMakeFiles\MeusCodigosC_2_0.dir/objects.a(HelloWorld.c.obj): na
> função "main": C:/Users/salom/CLionProjects/MeusCodigosC
> 2.0/HelloWorld.c:7: múltiplas definições de "main"; CMakeFiles\MeusCodigosC_2_0.dir/objects.a(AtividadeProducaoLabU2.c.obj):C:/Users/salom/CLionProjects/MeusCodigosC
> 2.0/AtividadeProducaoLabU2.c:32: definido primeiro aqui collect2.exe: error: ld returned 1 exit status mingw32-make.exe[3]: ***
> [MeusCodigosC_2_0.exe] Error 1 mingw32-make.exe[2]: ***
> [CMakeFiles/MeusCodigosC_2_0.dir/all] Error 2 mingw32-make.exe[1]: ***
> [CMakeFiles/MeusCodigosC_2_0.dir/rule] Error 2 mingw32-make.exe: ***
> [MeusCodigosC_2_0] Error 2
> CMakeFiles\MeusCodigosC_2_0.dir\build.make:119: recipe for target
> 'MeusCodigosC_2_0.exe' failed CMakeFiles\Makefile2:94: recipe for
> target 'CMakeFiles/MeusCodigosC_2_0.dir/all' failed
> CMakeFiles\Makefile2:101: recipe for target
> 'CMakeFiles/MeusCodigosC_2_0.dir/rule' failed Makefile:137: recipe for
> target 'MeusCodigosC_2_0' failed
I checked my CMakeLists.txt which I read that it's the file that makes your codes run, and the new code was already added to the target, but I still can't run it. The only workaround I had found is to delete the old code that I'm not using, and leave it only the code I want to use in that specific moment, only then I can run my C codes on Clion. Anyone had already face an issue like this? Thank you!
The error message says (if I understand Portuguese correctly) that the compiled files have several main functions defined in them.
main() is the function that runs when your program is executed. Several functions with the same name mean that the compiler doesn't know which one you want to run.
If you are writing several different programs, just keep them in separate folders, or make sure your CMakeLists.txt includes only one of them.
UPD: It looks like CLion supports one project creating multiple executable files. See documentation.
In your case, CMakeFile.txt should probably contain two lines (file names might need to be corrected):
add_executable(hello_world HelloWorld.c)
add_executable(MeusCodigosC_2_0 AtividadeProducaoLabU2.c)
If HelloWorld and Lab2 should share some code, you may extract it to a separate file, e.g. common.c, then update the project to say
add_executable(hello_world HelloWorld.c common.c)
add_executable(MeusCodigosC_2_0 AtividadeProducaoLabU2.c common.c)
I had this problem in clion and i fixed that. I Just opened new project and ta damm it worked.
it seems so easy to fix but my first time to using this so it was hard little bit for me :)
I'm using gyp to generate Visual Studio projects, make files, and Xcode projects.
I would like to have a pre-build step that calls a command line tool which generates some code that I later compile in, is this possible?
Incidentally, in cmake I do it using a post build step on a project that I depend on as a kind of workaround for there being no pre build there, so a post build step would also be fine.
I can see that I can call arbitrary commands at generation time using <!() syntax but I'd really prefer to generate the projects once and then on compile have the code generation step occur.
I got somewhere using actions...
I have this little application:
main.c
#include <stdio.h>
int main() {
#include "some_output"
return 0;
}
And this input file
some_input
printf("Hello World!\n");
And so I can fake up some, albeit Windows specific, code generation in my .gyp file like so (i.e. printing the file to standard out and redirecting back into a file, yes, silly but it illustrates the point hopefully):
gypping.gyp
{
'targets': [
{
'target_name': 'gypping',
'type': 'executable',
'sources': [
'main.c',
'<(INTERMEDIATE_DIR)/some_output',
],
'actions': [{
'action_name': 'create_something_generated',
'inputs': [
'some_input'
],
'outputs': [
'<(INTERMEDIATE_DIR)/some_output',
],
'action': ['type', '<#(_inputs)', '>', '<#(_outputs)'],
},
],
},
],
}
This seems to nearly work in so much as when I build in Visual Studio (having run gyp --depth=.) I get the following error:
1>------ Build started: Project: gypping, Configuration: Default Win32 ------
1> create_something_generated
1> '"C:\dev\code\Sandpit\gypping\.\setup_env.bat"' is not recognized as an internal or external command,
1> operable program or batch file.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 1.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I can't find setup_env.bat in my path.
I created an empty setup_env.bat file and I simplified the action by removing the > (I guess the escaping goes wrong with this). Now I get this:
'bash' is not recognized as an internal or external command,
I do not have bash as I'm on Windows.
I think Gyp is finished for me then, I guess I'll stick to cmake.
actions are exactly what you want. They are run pre-compile and the Git docs show them being used to generate files to be used during the compile step.
I have Git for Windows installed and use that, not cygwin, for running the generated actions via Visual Studio. Here is my setenv.bat:
REM Set up to use Git Bash for running "cygwin" actions.
REM CD to where this file lives to avoid path relativization problems.
cd %~dp0
set PATH=%PATH%;C:\Program Files\Git\bin
I have also seen Git for Windows installed in
%USERPROFILE%\AppData\Local\Programs\Git. I have no idea what causes the differing locations. Change the above PATH as necessary.
I am looking for the answer to how to generate a post build step