A question about g++ -l

[yj1214]

g++ -l I heard that this tells compiler the library name. What is it mean by library name? is it the file name?


Also, this is not related to g++ but what is it mean by pushed to the stack?


*EDIT*

I have another question :D

g++ -EXMAPLE_BLA_BLA Why do you put this?

[E l e c t r i c]

I'm not sure what g++ -l does specifically but a library name is going to be something such as iostream, string, vector etc. Those are all libraries.

As far as your stack question goes, the stack is a special reserve location in memory that is used for excess data that you need to store. The stack can be organized byte by byte or by a larger amount of bytes if needed. If you every learn MIPS Assembly you'll play around with the stack. The concept to PUSH the stack essentially means to make space in the stack for data. Usually to do this we have to PUSH (decrement) the stack pointer by a certain amount of bytes to make room for the data we want to store into it. We can later access the data by simply pulling it out and the "POPPING" the stack or POP the stack. Popping the stack essentially requires you to grab the data you need and then increment the stack pointer back to its standard pointer position.

[Peter87]

yj1214 wrote:

g++ -l I heard that this tells compiler the library name. What is it mean by library name? is it the file name?

Yeah, I think they are files stored somewhere on you computer.

E l e c t r i c wrote:

I'm not sure what g++ -l does specifically but a library name is going to be something such as iostream, string, vector etc. Those are all libraries.

Those are usually called headers. A library can consists of many headers.

yj1214 wrote:

what is it mean by pushed to the stack?

Pusing to the stack means you add something to the stack.
Popping means you remove something from the stack.

What is special about a stack is that you always add and remove the top item(s).

E l e c t r i c has described the "call stack" but a stack data structure can also be used to store other types of data.
http://en.wikipedia.org/wiki/Stack_%28abstract_data_type%29
http://en.wikipedia.org/wiki/Call_stack

[dhayden]

Suppose you write a program that uses a lot of external code, such as operating system calls, or windows functions. It would be very inefficient to recompile all of that code each time you need to recompile your program. After all, Windows didn't change, just your program. Also, it's unlikely that Microsoft would want to give you the source code to windows.

To solve this problem, compilers use libraries. These are precompiled source files that are then combined into a single larger file. The process of combining your program and any necessary libraries together into an executable program is called linking.

If you look closely, you'll find that your final program might not be as large as the libraries that it links with. This is because the linker is smart enough to include only the parts of the library that your program actually needs.

[Ganado]

Figure I'd ask here, dhayden your post reminded me of a question I've had :)

Does using libraries limit the amount of optimization that a linker can do when the file program is put together? Or does it make no difference?

[ne555]

> What is it mean by library name? is it the file name?
not quite

if you want to use a function you need to link the file that defines it. By instance, cv::imshow is defined in /usr/lib/libopencv_highgui.so so your build command becomes

$ g++ main.cpp -c
$ g++ main.o /usr/lib/libopencv_highgui.so -o program.bin

-l is simply a shortcut, it adds the lib prefix and the .so|.a|.dll suffix
so instead of writing /usr/lib/libopencv_highgui.so you just to -lopencv_highgui
(there are defined paths to look for libraries, /usr/lib being one of those)

[dhayden]

Does using libraries limit the amount of optimization that a linker can do when the file program is put together? Or does it make no difference?

Generally it makes no difference. Unless a function can be inlined, it has to do what it has to do. The compiler has no idea what will call the function when compiling it, so it can't really apply any sort of cross-function optimization. This is true with any external function regardless of whether it's in a library or a separate file.

[JLBorges]

> Does using libraries limit the amount of optimization that a linker can do when the file program is put together?
> Or does it make no difference?

Optimisations typically depend on the compiler/linker options specified. These days, every mainstream C++ compiler supports inter-procedural optimisation and link-time optimisation/code generation.

For instance, with g++, if the library and the program using the library is built with

-flto

This option runs the standard link-time optimizer. When invoked with source code, it generates GIMPLE (one of GCC's internal representations) and writes it to special ELF sections in the object file. When the object files are linked together, all the function bodies are read from these ELF sections and instantiated as if they had been part of the same translation unit.

and the program is linked with -fuse-linker-plugin

Enables the use of a linker plugin during link-time optimization. This option relies on plugin support in the linker, which is available in gold or in GNU ld 2.21 or newer.
This option enables the extraction of object files with GIMPLE bytecode out of library archives.

https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Optimize-Options.html#Optimize-Options

[dhayden]

These days, every mainstream C++ compiler supports inter-procedural optimisation and link-time optimisation/code generation.

Cool! I didn't know that.