To link a library, say, BLAS, in gfortran one needs to use gfortran file.f90 -lblas to compile.
Is there any way to avoid that part by directly writing some command inside the main program so that one does not need to add some extra command while compiling?
No.
Theoretically, I suppose you could do some crazy stuff where you go a grab that file in code essentially linking it yourself but that would be.. unusual. The general solution to this is to use a makefile or if you are really just messing around a temporary alias in your terminal can keep things simple.
Related
I've been searching around for different custom pre-processor extensions and replacements, but all of them seem to come with 1 of 2 caveats:
Either 1), you generate the code as a separate build-system, them manually put the output into your real (CMake) build system, or 2) you end up losing the builtin preprocessor for GCC.
Is there really no tool that can, say, run each file it gets against some configured script, then through cpp, then pass the result to gcc?
I'd love to use something like Cog by just setting an environment variable for gcc, indicating a tool that runs Cog first and then the standard preprocessor.
Alternatively, is there a straightforward way to accomplish that in CMake, itself? I don't want to have to write a custom script for each file, especially if I have to then hard-code the compiler/preprocessor flags in each target.
edit: For clarity, I am aware of several partial/partially-applicable solutions. For example, how to tell GCC to use a different preprocessor. (Or really, to look in a different place for its own preprocessor, cc1. See: Custom gcc preprocessor) However, that leaves a lot of work to do, to modify files, and then correctly invoke the real cc1, with the correct original arguments.
Since that is effectively a constant/generic problem, I'm just surprised there is no drop in program.
Edit 2: After looking over several proposed solutions, I am not convinced there is an answer to this question. For example, if files are going to be generated by CMake, then they can't be included and browsed by the IDE - due to not yet existing.
As ridiculous as it sounds, I don't think there is any way to extend the preprocessor short of forking Gcc. Everything recommended so far, constitutes incomplete hacks.
The GCC (C++ compiler) is made for compiling C++ programs. As the C++ preprocessor is standardized within the C++ standard there is usually no need for anything like a "plugin" or "extension" there.
Don't listen to the comments, that suggest you using any exotic extension to CMake or change source code of GCC. Running source files through a different program (cog in your case) before compiling is a well known task and all major build systems support it right away.
In CMake you can use the add_custom_command function. If you need this for more than one file, you could use a CMake loop like e.g. suggested in this answer.
How can i compile my app linking statically glibc library, but only the code needed for my app? (Not all lib)
Now my compile command:
g++ -o newserver test.cpp ... -lboost_system -lboost_thread -std=c++0x
Thanks!
That's what -static does (as described in another answer): unneeded modules won't get linked into your program. But your expectations on the amount of stuff which is needed (in a sense that we can't convince linker to the contrary) may be too optimistic.
If you trying to do it for portability (running an executable on other machines with older glibc or something like that), there is one easy test question to see if you're going to get what you want:
Did you think of the problem with libnss, and are you sure it is not going to bite you?
If your answer is yes, maybe it makes sense to go on. If the answer is no, or the question seems too obscure and there is no answer, just quit your expirements with statically linked glibc: it has more chance to hurt than help.
Add -static to the compile line. It will only add what your application needs [and of course, any functions the functions you application calls, and any functions those functions call, including a bunch of startup code and some other bits and pieces], so it will be around 800K (for a simple "hello world" program) on an x86 machine. Other architectures vary. Since boost probably also calls the standard library at least a little bit, it's likely that you will have more than 800K added to your appliciation. But it only applies functions used by any of the code in the final binary, not the entire library [about 2MB as a shared library].
If you ONLY want link glibc, you will need to modify the linking line to your compile to:
-Wl,-Bstatic -libc -Wl,-Bdynamic. This will prevent any other library from being linked statically [you sometimes need to have more than one of these statements, as sometimes something pulled in by another library requires "more" from glibc to be pulled in - don't worry, it won't bring in anything more than the linker thinks is necessary].
I've implemented a reasonably good optimizing compiler (for a toy language), and have come across a rather puzzling scenario. I can take an input file and produce assembly from it, so in that respect the "compiler" is finished. If I take that assembly file assemble it with NASM and link it to my runtime support library with G++ (the runtime needs libstdc++), I get a working executable, with no errors. However, I'd like to be able to compile to an executable in one command, so I added some calls to system to my compiler, passing the EXACT SAME COMMANDS as I was using in bash. When I run the compiler, it seems to assembly properly, but the linking step (again, using g++) fails with an undefined reference to main. Confused, I attempted to link manually (without reassembling, so I was using the object file produced by the NASM run with system, and received the same error. If I reassemble using the new compiler's assembly output, I have no problems, which has led be to believe that NASM is the problem. Like I said, the commands are exactly the same (I literally copied and pasted them just to make sure after the first time). Is this environment variables or something? What's going on?
EDIT:
I manually assembled an object file, again using the same command as the one in the compiler, and I did a vim diff between the two. The compiler-generated one seems to only contain the ELF header.
EDIT 2:
A screenshot of the diff
EDIT 3:
I tried using system to call a Perl script that in turn would call NASM and G++, still no luck.
Fixed it! It was the file not being flushed due to a race condition. Thanks for all the help, much appreciated.
a linker receives obj's and lib's to create exe's or other libs. But so does a makefile(but it can start from sources on top of that). what is the difference between the two?
No, a Makefile does not.
A Makefile is essentially a script to tell the make program what files to send to what programs as part of the build file.
So, a Makefile can invoke the compiler, linker, etc with the appropriate source files/object files, but it doesn't actually do the work itself.
I think you have missed the whole concept of a Makefile, so I suggest you do some further reading.
A linker and a makefile have almost nothing in common. A makefile is a set of instructions used by make. They can be instructions that build a program, install some files, or whatever you want make to do. A linker is a program that takes object files as input and combines them into an output executable (or shared library).
A makefile is just some kind of ruleset that defines what needs to be compiled and which compiling process depends on what. That way the make software can automate the process.
Using make and makefiles however does not mean that you are not using a regular compiler and linker. So basically those will still run, you just don't need to run it yourself, but define the process before in the makefile.
Make uses a makefile to evaluate a set of rules on whether to invoke the compiler on a source file (due to it changing, most likely) and eventually invoke the linker to create final object file.
You can read more about make here: http://www.gnu.org/software/make/
I need to gprof a library in our system to examine the function calls and see if we can optimize it any more. Basically, what I have is
Executable A which uses a shared Library myLib.so
I want to gprof the myLib.so. When I compile myLib.so source using -pg option, it produces a .so file just fine.
But, recompiling the Executable A against that library is not producing the *.gmon file for some reason. What needs to be done? Should I link the myLib statically? If so, please tell me how. I am a newbie, so pardon my ignorance. I am learning everyday
thanks in advance.
You can do better than gprof.
You could use a good sampling profiler like RotateRight/Zoom, or you could try this technique. Also lsstack serves well. pstack does too, but is more work for you.
I have the same issue, but I think the best thing to do is to create a small C/C++ program that uses the library with some test calls, compile it with the library using -pg, and profile that.
That way you nicely isolate the profiling issues of the library from other stuff, too.
As http://sourceware.org/binutils/docs/gprof/Implementation.html and https://stackoverflow.com/a/7290284/885650 point out, you need -pg when linking, as it adds extra code everywhere.