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.)
Related
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)
I'm new to emscripten; several days ago I've downloaded it just to try to make a port of a game to JS.
Anyway, after some steps, I'm having this issue now (on Ubuntu 16.04 STL).
By following build steps here, first of all, I've set environment variables with
source ./emsdk_env.sh and then I've tried to configure the project with emconfigure ./configure in the project directory. When checking for tools emscripten needs, I've got this error:
checking for SDL... no
configure: error: Package requirements (sdl2 >= 2.0.1) were not met:
No package 'sdl2' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables SDL_CFLAGS
and SDL_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
ERROR:root:Configure step failed with non-zero return code 1! Command line: ['./configure'] at ...
So I've tried to set that variable with the following command:
export PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig/
This is where actually sdl2.pc is located on my machine, but it didn't help.
So then I've set the following variables that emconfigure needed:
export SDL_PATH=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDL_LIBS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDL_CFLAGS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDLNET_LIBS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDLNET_CFLAGS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDLMIXER_LIBS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDLMIXER_CFLAGS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
and relaunched emconfigure ./configure which has completed well.
So the next step is emmake make that gives me the following error:
make all-recursive
make[1]: Entering directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0'
Making all in textscreen
make[2]: Entering directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen'
Making all in fonts
make[3]: Entering directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen/fonts'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen/fonts'
Making all in .
make[3]: Entering directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen'
CC txt_conditional.o
Traceback (most recent call last):
File "/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/emcc", line 11, in <module>
python_selector.run(__file__)
File "/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/tools/python_selector.py", line 38, in run
sys.exit(run_by_import(filename, main) if on_allowed_version() else run_by_subprocess(filename))
File "/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/tools/python_selector.py", line 13, in run_by_import
return getattr(importlib.import_module(os.path.basename(filename)), main)()
File "/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/emcc.py", line 1345, in run
assert header.endswith(HEADER_ENDINGS), 'if you have one header input, we assume you want to precompile headers, and cannot have source files or other inputs as well: ' + str(headers) + ' : ' + header
AssertionError: if you have one header input, we assume you want to precompile headers, and cannot have source files or other inputs as well: ['/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h', 'txt_conditional.c'] : txt_conditional.c
Makefile:447: recipe for target 'txt_conditional.o' failed
make[3]: *** [txt_conditional.o] Error 1
make[3]: Leaving directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen'
Makefile:467: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen'
Makefile:585: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0'
Makefile:438: recipe for target 'all' failed
make: *** [all] Error 2
that means, I assume, that SDL_PATH, SDL_LIBS, SDL_CFLAGS... variables weren't set correctly. Or maybe I just need to precompile that headers in the SDL directory.
One last thing: if I skip setting SDL variables and the configuration step and just launch emmake make, the compilation goes well, but then, emcc command gives me
WARNING:root: .o is not valid LLVM bitcode
for all generated .o files. And that actually makes sense.
So I'm pretty stuck here. Somebody can tell me how to set correctly PKG_CONFIG_PATH for emscripten or if i really need to precompile those headers in the SDL directory? Thanks!
First of all, setting PKG_CONFIG_PATH, include or, even worse, library directories (-I and -L) to host libraries' ones looks like awful idea to me: Emscripten object files contain LLVM bitcode (and not host machine code), its .so files AFAIK contain bitcode as well. It is that bitcode that gets translated to JS, not host machine code. So you need to build your program's dependencies with Emscripten by yourself (and should most probably not install them to the host system). Fortunately, there are some official Emscripten ports (see here) for details.
Emscripten has its own implementation of SDL v1 (that you probably tried to use manually), but your program seems to require SDL2. Good news: you probably just need to pass -s USE_SDL=2 to CFLAGS and LDFLAGS when configureing (see later on the link above for information on SDL2 port). Bad news: something may not be fully ported. But I successfully used it to some extent.
When you have configured on host and make with emmake you probably had compiler paths among other parameters adjusted by emconfigure and emmake already baked into generated Makefile by ./configure not controlled by emconfigure, so host gcc/clang just generated machine code.
I'm trying to automatically label my application sign-on line with a build number. This application is a plain vanilla C one without graphic UI; it is intended for command line, therefore it is a "simple" one.
The sign-on id is located in a "template" source file which is customized by CMake with a configure_file() command. Recently, I fancied to include a build number in this sign-on id. Consequently, the customization can no longer be statically done at CMake time, but everytime make is invoked.
To achieve that, there are two possibilities in CMake:
add_custom_target(), but it is triggered even when nothing else changes in the source tree which does not reflect the state of the tree;
add_custom_command(), which can be triggered only when the application (target) needs to be linked again.
I opted for the second solution and did not succeed.
Here is an extract of my CMakeLists.txt, the sign-on id being in file ErrAux.c (template in PROJECT_SOURCE_DIR, configured in PROJECT_BINARY_DIR):
add_executable(anathem ... ${PROJECT_BINARY_DIR}/ErrAux.c ...)
add_custom_command(TARGET anathem PRE_LINK
COMMAND "${CMAKE_COMMAND}" "-DVERS=${PROJECT_VERSION}"
"-DSRC=${PROJECT_SOURCE_DIR}"
"-DDST=${PROJECT_BINARY_DIR}"
-P "${CMAKE_HOME_DIRECTORY}/BuildNumber.cmake"
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
COMMENT "Numbering build"
VERBATIM
)
This launches script BuildNumber.cmake just before the link step. It computes the next build number and customizes ErrAux.c with configure_file().
It works fine, except ...
It happens late in the make sequence and the update to ErrAux.c goes unnoticed. The sign-on id in the executable contains the previous build number.
Next time I run make, make notices the generated ErrAux.c is younger than its object module and causes it to be compiled again, which in turn causes a link which triggers a build number update. This happens even if no other file has changed and this loop can't be broken. This is clearly shown in the compiling log:
Scanning dependencies of target anathem
[ 13%] Building C object AnaThem/CMakeFiles/anathem.dir/ErrAux.c.o
[ 14%] Linking C executable anathem
Numbering build
3.0.0-45
[ 36%] Built target anathem
The crux seems to be that add_custom_command(TARGET ...) can't specify an output file like add_custom_command(OUTPUT ...) does. But this latter form can't be triggered in PRE_LINK mode.
As a workaround, I forced a compilation to "refresh" the object module with:
add_custom_command(TARGET anathem PRE_LINK
COMMAND "${CMAKE_COMMAND}" "-DVERS=${PROJECT_VERSION}"
"-DSRC=${PROJECT_SOURCE_DIR}"
"-DDST=${PROJECT_BINARY_DIR}"
-P "${CMAKE_HOME_DIRECTORY}/BuildNumber.cmake"
COMMAND echo "Numbering"
COMMAND echo "${CMAKE_C_COMPILER}" "\$(C_DEFINES)" "\$(C_INCLUDES)" "\$(C_FLAGS)" -c "${PROJECT_BINARY_DIR}/ErrAux.c"
COMMAND "${CMAKE_C_COMPILER}" "\$(C_DEFINES)" "\$(C_INCLUDES)" "\$(C_FLAGS)" -c "${PROJECT_BINARY_DIR}/ErrAux.c"
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
COMMENT "Numbering build"
VERBATIM
)
An explicit compilation is forced after sign-on id customization. It mimics what is found in the various Makefile's and my not be safe for production. It's a cheat trick on both CMake and make.
UPDATE: Option -c is required to postpone link step until the final application liniking process.
This addition creates havoc in the link, as shown by the log, where you see a double compilation (the standard make one and the add_custom_command() one):
Scanning dependencies of target anathem
[ 13%] Building C object AnaThem/CMakeFiles/anathem.dir/ErrAux.c.o
[ 14%] Linking C executable anathem
Numbering build
3.0.0-47
Numbering
/usr/bin/cc -DANA_DEBUG=1 -I/home/prog/projects/AnaLLysis/build/AnaThem -I/home/prog/projects/AnaLLysis/AnaThem -g /home/prog/projects/AnaLLysis/build/AnaThem/ErrAux.c
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
AnaThem/CMakeFiles/anathem.dir/build.make:798: recipe for target 'AnaThem/anathem' failed
make[2]: *** [AnaThem/anathem] Error 1
If I force a full recompilation, to make sure all sources are compiled, *main.c* included, I get the same error on `main`.
The only logical explanation is my manual C invocation is faulty and somehow destroys vital information. I checked with *readelf* that `main` is still in the symbol table for *main.c.o* and that it is still taken into account by the link step (from file *link.txt*).
UPDATE: Even with the correct link, I'm still experiencing the infinite loop syndrom. The generated application still has its sign-on id lagging behind the actual build counter.
Can someone give me a clue for the right direction?
FYI I'm quite new to CMake, so I may do things really wrong. Don't hesitate to criticize my mistakes.
The key to the solution is to put the generated module where make expects to find it. CMake organizes the build tree in a non-trivial way.
The shortcomming in my added compilation in add_custom_command() was to believe that by default the binary will be stored in the "usual" CMake locations. Since I forge manually my compiler command, this is not the case.
I found the module in the source directory, which is a consequence of the WORKING_DIRECTORY option, with name ErrAux.o and not ErrAux.c.o.
To obtain the correct behavior, I force an output location with:
-o "${PROJECT_BINARY_DIR}/CMakeFiles/anathem.dir/ErrAux.c.o"
Now, when I run make again, nothing happens since nothing changed.
Side question
To make the solution portable (if needed), are there CMake variables for CMakeFiles and anathem.dir directories? Or in the latter case, for the current target as "anathem" as the target name in add_custom_command()?
I try to execute fakeroot debian/rules binary-headers binary-genericand compile when building kernel but get the error.
Here error in below
arch/x86/built-in.o:(.rodata+0x1cb8): undefined reference to 'sys_monlak'
make[2]: *** [vmlinux] Error 1
make[2]: Leaving directory '/home/su/linux-lts-vivid-3.19.0/debian/build/build-generic'
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/su/linux-lts-vivid-3.19.0'
make: *** [/home/su/linux-lts-vivid-3.19.0/debian/stamps/stamp-build-generic] Error 2
I tried to build kernel following Build your own kernel and Clarkson.edu
I don't see any reference to the symbol "sys_monlak" inside any branch of the official Linux kernel. Are you using a branch obtained from somewhere else?
This error would happen if a driver depends on a symbol "sys_monlak" which should be defined elsewhere in the kernel but isn't, or perhaps the correct kernel module isn't enabled in the kernel config.
You can try running:
$ grep -R "sys_monlak"
If this produces a c file then you can then try to find the Makefile which should compile in this c file. If, for example, the file was called "arch/x86/monlak.c" you might find the following in the file "arch/x86/Makefile":
obj-$(CONFIG_MONLAK) += monlak.o
In this case you would want to try to enable CONFIG_MONLAK in the kernel config.
The other possibility is that you might want to disable the module that depends on the symbol 'sys_monlak'. Try to carefully read the description in the Kconfig file to see what each module does (the one that depends and the one that provides).
OS: Ubuntu 14.14
automake version: automake (GNU automake) 1.14.1
I build source codes to make a shared library by using automake.
But I got a error that automake may can't handle source codes which are same name and different directory.
Can't I compile the same file name source codes in different directory by using automake?
For instance, lib_sample/lib.c, lib_sample/enhance/lib.c those two files are the same name but different source and different directories.
Also, After typing the configure, I check the src directory, weird directory($(LIB_DIR)) is created.
./configure --with-lib=/home/user/workspace/lib_sample --enable-enhance
ls src/
$(LIB_DIR) Makefile Makefile.am Makefile.in mod_sample.c
--> $(LIB_DIR) is created. unintended directory is created.
I got an error message when I type the make command.
the error message looks like this.
Makefile:423: /src/.deps/lib.Plo: No such file or directory
Makefile:424: /src/enhanced/.deps/lib.Plo: No such file or directory
make[1]: *** No rule to make target `/src/enhanced/.deps/lib.Plo'. Stop.
make[1]: Leaving directory `/home/user/test/mod_sample/src'
make: *** [all-recursive] Error 1
First problem is, after configure script, the $(LIB_DIR) directory is created.
Second problem is a failure in build source codes when I type the make command.
I think the libtool fail to compile when it tries to make .Plo files, but what I can't understand is that why automake tries to compile lib_sample/src/lib.c.
Because I denote the LIB_DIR path with --with-lib and --enable-enhance option, before compiling the sources in ./configure script. Therefore, automake should do not manage src/lib.c.
However, automake tries to compile lib_sample/src/lib.c and the strange message comes out.
You can see codes how I write below, and project structures in detail.
Thanks in advance.
Here in details.
There are two directories.
/home/user/test/mod_sample, (build fail)
/home/user/test/lib_sample (another source codes in here)
configure.ac (/home/user/test/mod_sample/configure.ac)
dnl Process this file with autoconf to produce a configure script.
AC_PREREQ(2.59)
AC_INIT(sample, 1.5.0)
AC_PROG_CC
AC_PROG_CXX
AC_CANONICAL_SYSTEM
AM_INIT_AUTOMAKE([subdir-objects])
AM_PROG_CC_C_O
LT_INIT
AC_PROG_LIBTOOL
AC_MSG_CHECKING(--with-lib)
AC_ARG_WITH([lib],
AC_HELP_STRING([--with-lib=DIR], [Set lib path ]),
[LIB_DIR=$withval]
[have_lib=yes],
[have_lib=no])
AC_MSG_RESULT($LIB_DIR)
AC_SUBST(LIB_DIR)
AC_ARG_ENABLE([[enhance]],
[AS_HELP_STRING([[--disable-enhance]], [enhance])], ,
[enable_enhance=yes])
test "x$enable_enhance" = "xno" || enable_enhance=yes
AM_CONDITIONAL([HAVE_ENHANCE], [test "x$enable_enhance" = "xyes"])
AC_CONFIG_FILES(Makefile
include/Makefile
src/Makefile)
AC_OUTPUT
top directory Makefile.am(/home/user/test/mod_sample/Makefile.am)
SUBDIRS=src include
src/Makefile.am (/home/user/test/mod_sample/src/Makefile.am)
lib_LTLIBRARIES = libmod_sample.la
libmod_sample_la_SOURCES = mod_sample.c
if HAVE_ENHANCE
libmod_sample_la_SOURCES+=$(LIB_DIR)/src/enhanced/lib.c
else
libmod_sample_la_SOURCES+=$(LIB_DIR)/src/lib.c
endif
run configure command before make
autoreconf -if
./configure --with-lib=/home/user/workspace/lib_sample --enable-enhance
the error message when I type the 'make'.
Makefile:423: /src/.deps/lib.Plo: No such file or directory
Makefile:424: /src/enhanced/.deps/lib.Plo: No such file or directory
make[1]: *** No rule to make target `/src/enhanced/.deps/lib.Plo'. Stop.
make[1]: Leaving directory `/home/user/test/mod_sample/src'
make: *** [all-recursive] Error 1
lib_sample directory structure (same file name in different directory)
/home/user/workspace/lib_sample/lib.c
/home/user/workspace/lib_sample/enhance/lib.c
lib_sample/lib.c
void lib()
{
printf("hello\n");
}
lib_sample/enhance/lib.c
void lib()
{
printf("enhance hello\n");
}
I answered this myself.
According to the reference(http://www.gnu.org/software/automake/manual/html_node/Conditional-Sources.html), a user specified variable, $(LIB_DIR) in this case, can't be used in a _SOURCES variable. However, it works fine in my case except when the variable is used with same file name and if statement. The problem is that the variable which user specified is used in a _SOURCES variable and if statement with same file name.
So, I thought there are two possible solutions. One is that I may change a file name one of them to avoid using same file name. Another is that using a variable represents 'enhance' string, which is the directory name, to remove if statement in Makefile.am.
Solution 1
mv lib_sample/enhance/lib.c lib_sample/enhance/lib_enhance.c
make
lib_LTLIBRARIES = libmod_sample.la
libmod_sample_la_SOURCES = mod_sample.c
if HAVE_ENHANCE
libmod_sample_la_SOURCES+=$(LIB_DIR)/src/enhanced/lib_enhance.c # change the file name
else
libmod_sample_la_SOURCES+=$(LIB_DIR)/src/lib.c
endif
But, I can't change the file name, the reason for this is a bit hard to explain, in short to speak, because of source code permission.
Solution 2
I solved the problem in this way.
part of configure.ac (/home/user/test/mod_sample/configure.ac)
AC_ARG_ENABLE([[enhance]],
[AS_HELP_STRING([[--disable-enhance]], [enhance])], ,
[enable_enhance=yes])
test "x$enable_enhance" = "xno" || enable_enhance=yes
AM_CONDITIONAL([HAVE_ENHANCE], [test "x$enable_enhance" = "xyes"])
AM_COND_IF([HAVE_ENHANCE], [AC_SUBST(ENHANCE, "enhance")], [AC_SUBST(ENHANCE, "")]) # Add this line
src/Makefile.am (/home/user/test/mod_sample/src/Makefile.am)
lib_LTLIBRARIES = libmod_sample.la
libmod_sample_la_SOURCES = mod_sample.c
# Use $(ENHANCE) variable to remove if statement
# $(ENHANCE) can be "enhance" or empty string.
libmod_sample_la_SOURCES+=$(LIB_DIR)/src/$(ENHANCE)/lib.c