I have been trying to compile open source projects since past few months with no success. I just don't know how to go about the entire thing. Readings over the internet have not helped much.
Some come with ./Configure and a Makefile while others with only a Makefile. How to use them to generate executables (or they have some other purpose ).
My machine currently has:
Windows XP,
Mingw Compiler for C/C++,
Cygwin
Do I need any other software?
Thanks!
Edit:
Thanks for the response. Currently I am trying to compile "Null Httpd". It comes only with a makefile.
In my command line prompt I type
/directoryContainingMakeFile/mingw32-make Makefile
I get
"Nothing to be done for 'Makefile'"
:(? Am I doing it the right way?
./configure is the first thing to run, if it exists -- it checks if your system has the requirements for the project, and also allows you to set project specific settings or simply set the default values.
Next, the command make (though some projects require automake, or cmake, which are similar but more powerful utilities) takes those configurations and builds from the source code into the executable. Make isn't a compiler in itself though -- its simply used to specify how to build the project. Most projects in C use gcc, probably with many standard libraries to be linked in, in which case this should run on top of cygwin perfectly well. If it has other dependencies however, you are on your own for the most part (this gets complicated very quickly -- if this happens, its usually a less time-consuming effort to work in the OS the source was made to compile on).
After this, you should find the binaries you require in the same directory :)
Related
It seems like CMake is fairly entrenched in its view that there should be one, and only one, CMAKE_CXX_COMPILER for all C++ source files. I can't find a way to override this on a per-target basis. This makes a mix of host-and-cross compiling in a single CMakeLists.txt very difficult with the built-in CMake facilities.
So, my question is: what's the best way to use multiple compilers for the same language (i.e. C++)?
It's impossible to do this with CMake.
CMake only keeps one set of compiler properties which is shared by all targets in a CMakeLists.txt file. If you want to use two compilers, you need to run CMake twice. This is even true for e.g. building 32bit and 64bit binaries from the same compiler toolchain.
The quick-and-dirty way around this is using custom commands. But then you end up with what are basically glorified shell-scripts, which is probably not what you want.
The clean solution is: Don't put them in the same CMakeLists.txt! You can't link between different architectures anyway, so there is no need for them to be in the same file. You may reduce redundancies by refactoring common parts of the CMake scripts into separate files and include() them.
The main disadvantage here is that you lose the ability to build with a single command, but you can solve that by writing a wrapper in your favorite scripting language that takes care of calling the different CMake-makefiles.
You might want to look at ExternalProject:
http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html
Not impossible as the top answer suggests. I have the same problem as OP. I have some sources for cross compiling for a raspberry pi pico, and then some unit tests that I am running on my host system.
To make this work, I'm using the very shameful "set" to override the compiler in the CMakeLists.txt for my test folder. Works great.
if(DEFINED ENV{HOST_CXX_COMPILER})
set(CMAKE_CXX_COMPILER $ENV{HOST_CXX_COMPILER})
else()
set(CMAKE_CXX_COMPILER "g++")
endif()
set(CMAKE_CXX_FLAGS "")
The cmake devs/community seems very against using set to change the compiler since for some reason. They assume that you need to use one compiler for the entire project which is an incorrect assumption for embedded systems projects.
My solution above works, and fits the philosophy I think. Users can still change their chosen compiler via environment variables, if it's not set then I do assume g++. set only changes variables for the current scope, so this doesn't affect the rest of the project.
To extend #Bill Hoffman's answer:
Build your project as a super-build, by using some kind of template like the one here https://github.com/Sarcasm/cmake-superbuild
which will configure both the dependencies and your project as an ExternalProject (standalone cmake configure/build/install environment).
I have been reading up on make and looking at the Makefiles for popular C projects on GitHub to cement my understanding.
One thing I am struggling to understand is why none of the examples I've looked at (e.g. lz4, linux and FFmpeg) seem to account for header file dependencies.
For my own project, I have header files that contain:
Numeric and string constants
Macros
Short, inline functions
It would seem essential, therefore, to take any changes to these into account when determining whether to recompile.
I have discovered that gcc can automatically generate Makefile fragments from dependencies as in this SO answer but I haven't seen this used in any of the projects I've looked at.
Can you help me understand why these projects apparently ignore header file dependencies?
I'll attempt to answer.
The source distros of some projects include a configure script which creates a makefile from a template/whatever.
So the end user which needs to recompile the package for his/her target just has to do:
$ configure --try-options-until-it-works
$ make
Things can go wrong during the configure phase, but this has nothing to do with the makefile itself. User has to download stuff, adjust paths or configure switches and run again until makefile is successfully generated.
But once the makefile is generated, things should go pretty smooth from there for the user which only needs to build the product once to be able to use it.
A few portion of users will need to change some source code. In that case, they'll have to clean everything, because the makefile provided isn't the way the actual developpers manage their builds. They may use other systems (code::blocks, Ant, gprbuild...) , and just provide the makefile to automate production from scratch and avoid to depend on a complex production system. make is fairly standard even on Windows/MinGW.
Note that there are some filesystems which provide build audit (Clearcase) where the dependencies are automatically managed (clearmake).
If you see the makefile as a batch script to build all the sources, you don't need to bother adding a dependency system using
a template makefile
a gcc -MM command to append dependencies to it (which takes time)
Note that you can build it yourself with some extra work (adding a depend target to your makefile)
i want to compile a 'c' code and create an executable from my application. as of now i do it by specifying the path of my compilation .exe (c++) present in the bin folder of my Dev-Cpp folder.
it works fine but i need to pack the compiler along with the application so i wanted to know what files and folders are needed so that i can compile it directly from the application.
what are the files needed exactly i.e. headers,the compilation application, libs and what else...
any help?
If you're asking how to create and distribute a project which is able to build upon an existing compiler for its functionality, there are packages you can find which are just the compiler portion without the IDE. Minimalist GNU for Windows is such a package:
http://en.wikipedia.org/wiki/MinGW
(In fact, when the people who put together Dev-C++ wrote their integrated development environment, they get the actual compilation functionality from MinGW...which they bundled into their package for good measure. So if you were going to write an IDE of your own, you would start from the MinGW distribution...not by trying to hand-pick files out of Dev-C++.)
One issue to be sensitive to is licensing. While there are not generally any legal issues out of the box regarding distributing executables built with a system like MinGW, when you go as far as to include the compiler in your own "product", it might be tricky. Dev-C++ is under the same license as MinGW (GPL) but I'd imagine there'd be issues if it were not.
If you only need a subset of the full functionality (let's say you only compile C and not C++) there will be a lot of header files and such that you could cut out. But you have to trade off the difficulty of maintaining this sort of optimization vs. just having your program ask users to install MinGW and then tell your program where they installed it. It might take up more space and lead installation to be a two-step process...but frees you from a large number of concerns.
So that's what I would suggest: Have a setting in your program (much like Dev-C++ does) which lets people specify where the MinGW binaries are installed on their system. But let them install it independently.
There is few files with .c anf .h extensions (cmdline.c cmdline.h core.c core.h and so on) in src directory, also there is one file "MakeFile" without extension. Is there any possibility to build these source files into some executable file on Windows 7 (64bits) ? I think i need to download compilers for C or some sdks right?
Yes.
You need to:
download and install a C/C++ compiler (I recommend TDragon's distribution of MinGW ),
add the compiler to your PATH (the installer can do it for you most of the cases); verify it's done by opening cmd.exe and typing gcc -v and mingw32-make -v, both should give you half a screenful of version information if your path is set correctly,
via cmd.exe, navigate to the folder in which the Makefile resides and call mingw32-make.
From now on everything should compile automatically. If it doesn't, post the errors.
Update:
First of all, it'd be useful for you to get the MSys package. Install it and you'll have a more recent version of make (use it instead of mingw32-make from now on).
About the CreateProcess bug, it has to do with the system PATH variable being too long. You'd need to do something like this:
open cmd
execute set PATH=c:/mingw32/bin;c:/msys/1.0/bin (change the paths here to reflect your own installation if it's different)
then as before: navigate to your project's directory, run make. Everything should be smooth now if you're not missing any external libraries.
BTW- remember not to install MinGW or MSys in directories with spaces.
I am not a Windows Developer..
But still as per my knowledge. Visual Studio (i.e 2008, I guess) has the ability to read the Makefile.
Please have a look at it..and if needed change this makefile to their format..
There are many opensource product which are platform independent..and they get compiled on both OS with the just Makefile they provided.
Or else use 'cygwin'
Developer C++ works in windows but it is actually GCC code bought into Windows, Is anyone familiar about the procedure they used to convert the linux ( .sh) to executables ??
I think i need to download compilers for C or some sdks right?
A compiler certainly, but what additional libraries you may need will depend entirely on the code itself. A successful build may also depend on the intended target of the original code and makefile. The makefile may be a GNU makefile, but there are other similar but incompatible make utilities such as Borland Make and MS NMake. If it is a simple build, you may be able to avoid the makefile issue altogether and use the project management provided by an IDE such as Visual C++ 2010 Express.
If you do not know what this code is or what it does and what it needs to build, you are taking a risk building it at all. Maybe you should post a link to the original source so that you can get more specific advice on how to build it.
[EDIT]
Ok, now looking at the code you are attempting to build, it is a very simple build, so if you wanted to avoid using GNU make, then you could just add all the *.c files in the src folder to a project in your IDE and build it.
However there is one serious gotcha, it uses the BSD sockets API and Linux system headers. You will need to first port the code to Windows APIs such as WinSock (very similar to BSD Sockets), or build it under Cygwin (a sledgehammer for a nut somewhat). There may be other Linux dependencies that need sorting, I have not looked in detail, but it looks fairly simple. That said, if you did not have the first clue regarding compiling this stuff, then perhaps this is not a task you could do?
Of course compiling the code may only be half teh problem, if it was designed to run on Linux, there may be run-time dependencies that prevent it running on Windows. Again I have not looked in detail.
Also looking at the code, I would suggest some caution, this may not be the best quality code. That may be unfair, but one obvious flaw and an indication if inexperience is the lack of include guards in the headers.
I have a C code created in Plato3. I want to create an exe file so I can share it with others.
Can someone please tell me how is this possible ?
I have tried sending the exe file that is created when normally compiled, but it crashes every time in runs on computers other than mine ...
Please help,
Thanks :)
[EDIT]
Program running on windows xp or vista .. same error :
Compiler used : SilverFrost (Fortran/C/C++) Development Studio (Plato3)
This application has failed to start
because salflibc.dll was not found,
reinstalling the application may fix
this problem
salflibc.dll is a library installed by the compiler on your development machine.
salf = Salford C Compiler, the obscure compiler included in Silverfrost
libc = C-language runtime support library, necessary for the basic functionality of any program
.dll = dynamically-linked library, i.e. a separate file from your .exe file
You might look for a compiler option that looks like "statically link runtime library;" this might eliminate the DLL dependency. However, if the compiler were capable of doing that, one would expect it to be the default, if not the only way.
However, I recall from the olden days of Classic Mac OS that sometimes DLL runtime libraries were used, the benefit being upgradability. Sometimes is a key word, though. (I suppose when the compiler vendor is the OS vendor, as with MSVC or Apple GCC, it is the norm, though.)
Another trick from that environment was to put the DLL in question in the application's directory and distribute it with the app. Typically runtime DLLs are licensed for free redistribution.
At the very least you have to make sure that the executable is running on the same architecture/operating system that it was compiled on.
Additionally, you need to make sure that any third party, or system libraries that are needed are available on the other systems too.
update
Based on the new information and error message you provide, it looks like you need to re-distribute the salflibc.dll
I would agree with other commenter's and suggest a different platform for development that is more mainstream, or supported.