Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
I'm trying to compile an engineering software tool called FlameMaster using cmake, and I'm getting an error of the following:
[ 1%] [FLEX][FlameManScanner] Building scanner with flex 2.5.35
[ 2%] Built target Alligator
[ 3%] Built target configure_source_sripts
gmake[2]: *** [src/FlameMan/lexer.yy.C] Error 141
gmake[2]: *** Deleting file `src/FlameMan/lexer.yy.C'
gmake[1]: *** [src/FlameMan/CMakeFiles/FMObjects.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
[ 10%] Built target ArrayMan
gmake: *** [all] Error 2
Prior to this, I modified the CMakeLists.txt to point to my c++ compiler and Mac OS X sdk location:
set(CMAKE_CXX_COMPILER "/usr/bin/c++")
set(CMAKE_OSX_SYSROOT "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk")
and ran (from directory "Build" alongside "Repository"):
rm -rf *
cmake ../Repository/ -DCMAKE_BUILD_TYPE=Release
which doesn't seem to throw any errors. The error above comes when I run:
make --build . --parallel --target install --config Release
Any ideas on where to start with this error code?
Edit: based on some comments, I adjusted the cmakelists and used the build commands as suggested, and removed —parallel. The error is still occurring identical, even after rm -rf * and remaking ../repository as outlined
Its possible that your build is being affected by the --parallel option, so I'd suggest removing that and trying again. Also, I don't know if it was a typo in your post but the command to build the project should be cmake not make.
Just as a word of CMake advice, typically speaking you should never have to modify another project's CMakeLists.txt directly in order to build, that file should only be touched by the people who originally wrote the code. If you need to override the values of variables, you can do so from the command line (the same way you're already setting CMAKE_BUILD_TYPE=Release)
i.e. from the build directory, you can run this and it will have the same effect as the edits you made to the file
cmake ../Repository/ -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER="/usr/bin/c++" -DCMAKE_OSX_SYSROOT="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk"
However, as mentioned by [#Kuba] in a comment, CMake usually does a pretty good job automatically detecting compiler and SDK locations, so unless you've heavily customized your system it probably isn't necessary to set those variables.
And one final cmake tip: if you successfully build the 'install' target it will install all the files into the default location for whatever system you're on: (/usr/local for UNIX and C:\Program Files\ for Windows).
Unfortunately, CMake doesn't provide any easy way to 'uninstall' the program later after its been installed. So if you think you may want to remove the program in the future, it may be better to change the install location to somewhere else.
You can do this by setting the CMAKE_INSTALL_PREFIX variable, just add
-DCMAKE_INSTALL_PREFIX=/path/to/desired/install/location to your cmake configuration command.
Related
I'm installing CompCert C compiler as instructed here: https://compcert.org/man/manual002.html.
However I'm stuck at the stage where I "Run the configure script with appropriate options: ./configure [option …] target "
The console output is:
~/compcert/CompCert-3.8$ ./configure -use-external-MenhirLib x86_64-linux
Testing assembler support for CFI directives... yes
Testing linker support for '-no-pie' / '-nopie' option... yes, '-no-pie'
Testing Coq... version 8.11.0 -- good!
Testing OCaml... version 4.08.1 -- good!
Testing OCaml native-code compiler...yes
Testing OCaml .opt compilers... yes
Testing Menhir... version 20200123 -- good!
Error: cannot determine the location of the Menhir API library.
This can be due to an incorrect Menhir package.
Consider using the OPAM package for Menhir.
Testing GNU make... version 4.2.1 (command 'make') -- good!
One or several required tools are missing or too old. Aborting.
I'm running Ubuntu 20.04 LTS.
[Edit: I managed to run the ./configure. However I cannot reproduce the exact method how I did it. Now I'm stuck in a different part.]
Follow-up question:
When running make all I receive the following output:
/compcert/CompCert-3.8$ make all
make proof
make[1]: Entering directory '/home/user/compcert/CompCert-3.8'
COQC Axioms.v
Error: Can't find file ./Axioms.v
make[1]: *** [Makefile:226: Axioms.vo] Error 1
make[1]: Leaving directory '/home/user/compcert/CompCert-3.8'
make: *** [Makefile:155: all] Error 2
I fixed that problem by copying lib/Axiom.v to the root. The make all then complained about another library in lib/ so I moved a bunch of them until I received the following error:
~/compcert/CompCert-3.8$ make all
make proof
make[1]: Entering directory '/home/user/compcert/CompCert-3.8'
COQC Ordered.v
File "./Ordered.v", line 90, characters 16-19:
Error: The reference int was not found in the current environment.
make[1]: *** [Makefile:226: Ordered.vo] Error 1
make[1]: Leaving directory '/home/user/compcert/CompCert-3.8'
make: *** [Makefile:155: all] Error 2
And now I'm stuck once again.
It seems that you have an incorrect version of the menhirLib. See these lines in the configure script in the build system which lead to this error. I think the problem is that you installed a different version of menhirLib, possibly using your package manager.
I suggest you to run the following commands to install the latest menhirLib from the opam:
opam update
opam install menhir menhirLib
This should help.
I have configured and compiled the FFmpeg library using this link:
https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
Now, I am trying to build example C codes provided by FFmpeg from here:
https://github.com/FFmpeg/FFmpeg/tree/master/doc/examples
However, when I run make install-examples or make install (suggested by /example/README), I receive this kind of message:
make: *** No rule to make target '/doc/examples/README', needed by
'install-examples'. Stop.
I thought this may be due to the rules not being in the correct MakeFile format (I am not sure why they refers to README). How should I go about in fixing this and compiling the example codes? I have tried to find solutions about this, but there doesn't seem to be much information online.
Thank you.
Run ./configure && make -j4 examples in the FFmpeg source directory, then look in doc/examples for the compiled examples.
Requires make and pkg-config.
To remove the compiled examples use make examplesclean in the FFmpeg source directory.
nasm/yasm not found or too old. Use --disable-x86asm for a crippled build. If you think to configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to theffmpeg-user#ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.Include the log file "ffbuild/config.log" produced by configure as this will help solve the problem.
If you see this when you execute the above command then do this
macOS:
brew install yasm
Ubuntu:
sudo apt-get install yasm
Disclaimer: I'm no software engineer or programmer. I just know enough to get myself in trouble. Please forgive any misused or inaccurate terms.
I'm currently trying to test my HDF5 installation using the in-built Example test scripts. These are organised by CMake and compiled by gcc (MinGW and MinGW-w64). When I go to execute the test script:
ctest -S HDF518_Examples.cmake -C Release -V -O test.log
I'm met with pages and pages of errors, the core of these being:
mingw32-make.exe[2]: *** No rule to make target 'C:/aroot/stage/Library/lib/z.lib', needed by 'bin/h5ex_d_compact.exe'. Stop.
From my hours of trying to fix this on my own, I've been able to work out that z.lib is a library file part of the ZLIB library, ubiquitous these days. I also know that I have at least one copy of this particular file in my Anaconda directory under /Library/lib/.
I have two questions:
1) How can I get CMake or MinGW to recognize where this file is, and hence stop this error? Is there an environment variable I can set, or a config file I can modify?
2) As an aside, where did this path come from? There is no C:/aroot/ directory on my computer. I've also been unable to find any generators for this path in any of the CMake, HDF5, or MinGW files. So why is CMake pointing to this faux-directory?
Any help would be appreciated.
I use ENVIRONMENT PATH in set_tests_properties to specify the dependent external libraries.
set_tests_properties(${Testname} PROPERTIES ENVIRONMENT
PATH=${/your/zlib/location}
WORKING_DIRECTORY "${/your/working/directory}/")
Hello Stack overflow Community,
I'm developing an C application for a Imx6 development kit from Variscite with yocto project and Eclipse Kepler. I've build an helloworld application according to the guide and written some additional code, which I now want to place in different source and include files to keep things neat and tidy. I've made the following files: uart.c, uart.h, gmttime.c and gmttime.h and included them in the src folder. Now my problem is that when i call any function from any source file that I created, I get the following compilation errors:
Description: Resource
make: *** [all] Error 2 Helloworld C/C++ Problem
make[1]: *** [all-recursive] Error 1 Helloworld C/C++ Problem
make[2]: *** [Helloworld] Error 1 Helloworld C/C++ Problem
undefined reference to `uartInit' Helloworld.c /Helloworld/src
My project files look like this:
Helloworld
/includes
/usr/include
/usr/include/x86_64-linux-gnu
/usr/lib/gcc/x86_64-linux-gnu/4.6/include
/usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
/usr/local/include
/Helloworld/src
/src
gmttime.c
gmttime.h
helloworld.c
uart.c
uart.h
makefile
makefile.am
makefile.in
#more files are in this project, which I think are not so interresting or cause or solution to this problem.
On different websites it's mentioned that I should add the directory to the project options under:Project->Properties->C/C++ General/Paths and Symbols to the Includes and Source Location Tabs. I've added /Helloworld/src and /helloworld to both tabs, but I'm still getting errors no matter what i try. I can't find any other solution to this problem, so I hope anyone has encountered the same problem and could tell me how to resolve it.
I'd be most gratefull if anyone could help me out, if anything is wrong with my question or more information is required, just ask.
Regards,
Edit:
uart_init's function prototype is declared in uart.h and the function excists in uart.c, both files are user made, so no library inclusions are required.
I have uart.h included in my helloworld.c file, just as i would include it in any normal c application. The code highlighting does not show any errors at #include "uart.h", although it shows a red underline at each function from uart.h, complaining; undefined reference when i hover my mouse over the function.
I can open a function declaration and then eclipse takes me to uart.c and shows the function's source code. It seems that the compiler does not include additional .c and .h files except those originally made by the Hello World ANSI C project in it's build, eventhough it refers correctly when i use F3 "Open decleration" on a function. I don't know if the make file automaticly includes the new files in a build or my project source location set under Project->Properties->C/C++ General/Paths and Symbols is incorrect.
The solution was quite simple, I had to include uart.c to the project_SOURCES in the makefile.am. I've been searching in the wrong direction all along, as I thought the problem was caused by a wrong or unset project configuration. The solutions I found on the web were all resolved by setting the Includes and source location folders under C/C++ General settings and thus I thought the solution was in the project configurations. With a little bit of trial and error I finally found the solution.
Not sure if this is the correct place for this kind of question. If not, please point me in the right direction.
I'm using OSX 10.5.8 on a white 13" macbook with Xcode 3.1.4. When installing py27-bottleneck through macports, I get the following error
---> Building py27-bottleneck
running build
running build_py
package init file 'bottleneck/tests/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/func/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/move/__init__.py' not found (or not a regular file)
package init file 'bottleneck/tests/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/func/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/move/__init__.py' not found (or not a regular file)
running build_ext
building 'func' extension
/usr/bin/gcc-4.2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch i386 -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c bottleneck/src/func/func.c -o build/temp.macosx-10.5-i386-2.7/bottleneck/src/func/func.o
In file included from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1760,
from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:17,
from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/arrayobject.h:4,
from bottleneck/src/func/func.c:314:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/__ufunc_api.h:242: warning: ?_import_umath? defined but not used
cc1(53864) malloc: *** mmap(size=298745856) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
cc1: out of memory allocating 298742336 bytes after a total of 0 bytes
error: command '/usr/bin/gcc-4.2' failed with exit status 1
Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-bottleneck/py27-bottleneck/work/Bottleneck-0.8.0" && /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 setup.py --no-user-cfg build
Exit code: 1
Error: org.macports.build for port py27-bottleneck returned: command execution failed
Warning: targets not executed for py27-bottleneck: org.macports.activate org.macports.build org.macports.destroot org.macports.install
Please see the log file for port py27-bottleneck for details:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-bottleneck/py27-bottleneck/main.log
Error: Problem while installing py27-bottleneck
I don't really know what the problem is and why this had happened, but what I noticed was that macports is still using an old compiler.
So does anybody know how I can fix this problem?
Also, why is macports still using gcc-4.2, while I have all my symlinks pointing at /opt/local/bin/gcc-mp-4.8. I remember having this problem earlier with installing some other python packages (or maybe it was this one, I don't remember), so I forced macports to use the newer compiler by changing the makefile and it worked temporarily. Until I started upgrading my outdated ports. Obviously now macports encountered linking errors and just reinstalled the all those packages (this is where I am now). So why does macports not just use the newer compiler? Or how can I make him do this? (maybe I shouldn't?)
Any help is appreciated. Thanks.
On 10.5.8 with Xcode 3.1.4 MacPorts uses the following compilers (in-order, unless blacklisted by ports because known to break):
GCC 4.2 from /usr/bin
A MacPorts build of the same compiler (with a few minor bugfixes)
GCC 4.0 from /usr/bin
Clang 3.3 from MacPorts
It seems this port should be blacklisting GCC 4.2 (and probably 2. and 3., too). You could file that as a bug, but to be honest, support for 10.5 is only given on a best-effort basis because most maintainers can't test on this platform anymore, so that's probably not getting you anywhere unless you provide a patch with your report.
You could override the compiler from command line like you did before. To stop rev-upgrade from immediately starting rebuilds, you can set revupgrade_mode report in your macports.conf. I'd have to see the output of port -dy rev-upgrade when it encounters broken ports to know why it produces broken binaries.
It has already been mentioned that the select mechanism doesn't affect which compilers MacPorts chooses for its ports (because depending on what's selected by the user would add another variable that might make builds unreproducible, which is something we're trying to avoid). MacPorts' default compilers can be changed, but doing so is completely unsupported and deliberately undocumented. That being said, if you still want to attempt this, https://apple.stackexchange.com/questions/118550/define-local-keyword-globally-in-a-macports-config/122997#122997 has some info on how to do that.