Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
My issues here led to the solution/new problem that I naively built the external library I am using for my host machine.
Thus of course arm-none-eabi-gcc compiler throws a fit when it meets elf32-i386 object files.
I originally built the library using:
./configure
make && make check
make install
So, now I thought I might be able to simply do:
make clean
./configure --host=arm-none-eabi
make && make check
make install
to fix it. Sadly mistaken.
I also tried --build=x86 but it seems this is auto-detected anyway.
CC=arm-none-eabi also seemed to have no effect.
What do I need to do in order to be able to build this library for linking when compiling with arm-none-eabi-gcc?
I was able to get this working with a couple of extra options specific to that configure script.
Though I didn't realise at the time of asking the question, these vary, so some familiarity or trial and error with the specific options available (./configure --help should always list those available) is required.
I should also note that make check will always fail on the build system, so isn't worthwhile.
You using wrong cross compiler .
arm-none-eabi is used for bare metal programs.
Instead use arm-none-linux-gnueabi-gcc which will contain library to solve undefined behaviours.
Have a look # Cross compile error "arm-none-eabi-g++ cannot find entry symbol"
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
This question may seem stupid, but as a beginner I did encounter this question when I moved forward, and I couldn’t find any information.
https://upload.cc/i1/2020/12/30/rUEC9s.png
https://upload.cc/i1/2020/12/30/d7Gwbr.png
https://upload.cc/i1/2020/12/30/6vr3lQ.png
This is an open source C++ program, I tried to compile and run it, but it failed
I have the following confusion:
Why the program does not have main.cpp
Update: When asking the first question, I even forgot helloworld.cpp, sorry
How do I compile and run it with CLion
Update: Usually I create a new project. After I create the project, it seems that it can be compiled and run for granted, but I don’t know how to compile and run an existing project (from others).
What do the folders in the first picture usually refer to
What does cmake and CMakeList.txt mean?
This open source program calls opencv, fftw and other libraries. I downloaded the corresponding files on the official website. How should the program call these libraries next?
If I download the library package on the official website, how should I install or configure it; if I install the package using homebrew, does that mean I have already configured it? Or I just finished downloading
I have written some programs in c++ and qt, but I don’t seem to know anything about c++
Finally, there is really nothing in the readme of this project
Your questions are too broad. Generally speaking, the answers would be something like this:
Naming your main file main.cpp is a convention, but is not required. What is required is a main() function (More info here).
You have to configure CLion to open Makefiles. There is a tutorial in CLion's website (Here).
What documents do you refer to?
src: Naming convention to the folder where the source (.cpp) files go.
include: Naming convention where the header (.hpp) files go.
License.txt: Where the software's license is written.
readme.md: Document that gives information about the project.
tests: Files to test the software.
cmake is a tool designed to build and package software (Their website is here). CMakeLists.txt is the file CMake uses to know how to create a Makefile and build the program.
You have to make the system know where the libraries are. You can achieve this by adding them to the project's folder or by adding them to the PATH of your compiler.
If you don't know very much about of C++ you should probably search a good C++ textbook. However, remember that Makefiles and C++ are 2 completely different things.
Most open source programs have build instructions somewhere in the readme.
It is usually best to follow those, even if they require downloading unfamiliar tools.
If the project doesn't have (detailed) build instructions, you should ask the owner, to add (more detailed) build instructions(by for example creating an issue for git-based repositories).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I use Visual Studio 2017 Community for C++ coding. I have made a simple win32 console app and do not want to expose my code. I have also found the .exe file in the debug folder of the solution. When I try copying the .exe file in the Debug folder in another folder it says that the dll isn't found.I also tried copying the whole folder but the same error occurs. Please help me...I want to run my app on another computer also.
You can Generate Code Map for Solution.
Navigate to Architecture –> “Generate Code Map for Solution”
Generates a code map like:
Which shows the inter-dependency between modules and libraries.
In your case by just copying the exe, you are breaking the references to all of the required libraries. Depending on your scenario, you have two good options. Copy the entire source tree + dependencies for you project and recompile it in the new working directory or create an installer which will allow you to distribute dlls and any other required resources.
This is more complicated that one might hope. To answer the question in the title, you need Dependency Walker. (The web site doesn't mention Windows 10, but this stuff hasn't changed much recently, so don't worry about that.)
To distribute the program to another machine, you need to create a release build (the debug run-time libraries are not redistributable). Once you have done that, you will almost certainly find that the other machine already has the release run-time library, but you will need to copy other libraries.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Where do you usually install debug versions of libaries you build from sources, e.g. under /usr/local/debug, something else?
Consider a software library you use for your developing program. If you need to go into the library's source code under debugger, you need the library build without optimizations and with debug symbol generated. On the other hand, to normally run your application or estimate a performance you usually use 'release' build of the library, such builds are typically installed under /usr/local (default prefix).
thx
There is no standard answer to this.
If we assume that ${project} is the name of the relevant project - e.g llvm or jpeglib or whatever, then:
You can store the files locally in your home directory (~/${project}/...). I use the pattern /usr/local/${project}-debug/... on my home machine. At work, I have my files in /work/${project}/target-dir - where target-dir is the name of the embedded platform I built it for - since my work involves building for a variety of different platforms, and I don't want to rebuild every time.
Of course, this also means that you have to modify the linker path to take this path ahead of the "normal" install directory. Not a big problem, just add a -L~/${project}/lib or whatever you decided on. And when you run things, you may need to use LD_LIBRARY_PATH=...:${LD_LIBRARY_PATH} to ensure the correct shared library files are picked up.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
We have a very old and big project which is mainly written by C (and a small piece of C++), and it can be built in both Linux and Windows. Currently, we write all the Makefiles in this project manually which I think is not good.
Now we want to make this project fully open source. However, before that, we want to enhance the way to build this project. So I'd like to know what is the best/popular way in open source community to build such project? I know a bit about autoconf/antomake which seems existing there for quit a long time, just wondering if any new and better way to build C/C++ project come up?
Thanks!
The most "open source" way would be to retool the compiler chain to use autotools.
Basically it permits compilation on one of a number of "unknown" systems by detecting the need libraries and their locations and then writing the makefiles to match the platform.
For C and C++ it is a very good match.
If you want to "push the envelope" Apache's Maven can also compile C and C++ with the NAR plugin. Personally, I really like Apache's Maven; however, if you are not versed with it, NAR plus "learning maven" will be quite a challenge. Meanwhile, everyone who's installed from source on a Linux box quickly becomes familiar with auotmake's "configure; make; make install" routine, so using Maven to do this is really a bit "outside the box".
There is also CMake; however, the benefits of CMake don't really strike me as overwhelmingly different from the more mature autotools tool chain. That said, CMake is a pretty nice setup, which becomes more complex (and matches the automake environment more and more) as it has to support the issues that a mature tool-chain like automake support.
All in all, I'd say stick with autoconf/autotools/automake. There are plenty of examples, and while you might have to leverage the M4 macro language, every part of the build system is readable, and can be leveraged to create your own custom extensions.
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 8 years ago.
Improve this question
I am attempting to create/build/run a second target for a library project in xcode. The library is being consumed by another project in the workspace, and I have:
Created the second target, a console app
Confirmed that the generated main.cpp file is included in the
console target
Cleaned and rebuilt, confirming that the library still builds and
works
However the console target remains unbuilt. I have not received any errors.
Places I have researched looking for higher resolution steps:
Googletest xcode tip (meandmark.com)
Google test project target docs (per my use case)
Should I be using one project with multiple targets?
Build static library target with main target for...
Xcode concepts
Xcode help docs
If you think you can help, I'd be much obliged.
It might not be the answer you are looking for, but if you are new enough to XCode, that setting up a test.cpp to your library is challange enough, you might try another tool that in the long run might prove to be more useful.
CMake is an excellent cross-platform tool that is capable of generating platform-specific makefiles or project/workspace files for various IDE-s, including XCode. So you need to learn only one tool, and you're good for all platforms and compilers.
CMake has a companion app that ships with it, CTest. It is meant for just the thing you are looking for. It basically adds build targets that build a certain app (test.cpp in your case), and check if the return of int main() is zero or not. Multiple tests can be created (all testing different aspects of your library), and CTest provides nice interface to run all tests, just the specified ones and what not, plus it prints runtime of tests and shows which have failed.
CMake and CTest have good documentation, and there are myriads of tutorials available online. It might take some time to master, but in the 2 days time you spent googling, you could've ported your workspace to CMake easily. In the long run, it pays off.