I have 2 questions... I couldn't find answers by Googling (more precisely, by Blackling) and in GCC documents, so I'm asking here.

1. There are 2 flags for position independent code, -fpic and -fPIC. All the examples I read use -fPIC... so when is -fpic useful and what is the difference?

2. Some tutorials use "g++ -shared" while others use "ld" for the creation of the shared library. Why? Does it matter which method I use? Is there a difference? Why does nobody mention both options?

Do you in general understand what gcc/g++ is ?

Do you want me to prove here you actually haven't read 'gcc' documents ?

You may want to try this page...

I think people in this forum are usually more helpful than was demonstrated by the first two replies you got.

I often have trouble finding info in GCC documents even when that info is actually there. But the -fpic vs. -fPIC discussion is right where you would expect it to be as graemef linked.

It tells you the difference for SPARC, m68k and RS/6000 and it tells you there is no difference for X86. IIUC, it doesn't mention X86_64 (I don't know whether you care about X86_64. I do.) So I don't know whether -fpic vs. -fPIC makes a difference for X86_64.

I don't know either. But I think a few experiments with gcc -v -shared would tell you (-v is documented in 3.2).

I (probably not the OP) have read every page of the gcc documents for some 4.x.x version at some point. But that doesn't mean I can remember every detail. It doesn't even mean I can find them again when I need them. Much of GCC documentation is very poorly organized.

For a recent thread at LQ, I search GCC docs again to find the documentation of -shared. (My own use of -shared has been buried in unchanging build control files for so long I forget the reasons behind the choices). I found -shared documented, not in the section where I would have expected it and not with enough explanation to understand it.

So your proof that the OP hasn't read the documents probably wouldn't be very convincing and more probably wouldn't be very helpful.

I still don't know what's the difference between ld and gcc -shared, but anyway, I have a new question: On Windows, variables can be exported and imported from DLLs using non-standard syntax: __declspec(dllexport). But I didn't see anything like that for Linux. Are all the global variables in the cpp files exported to the library? And when I write a program that uses the library, do I declare the imported variables with extern
(extern int globalVariable; ) ?

No, first and foremost you don't know how 'gcc' works at the very top level and what 'gcc' as an executable really is.

Consider gcc/g++ as compilers supporting standard C99/C++ (with the appropriate command line switches).

GCC is actually a binary that calls ether ld or cc1.
It just makes it easier.

"No, first and foremost you don't know how 'gcc' works at the very top level and what 'gcc' as an executable really is."

Dude, this forum is for answering questions. With all the respect, and I have no doubt you have lots of knowledge and experience, those replies of your do nothing more than waste the servers' memory. Also, I only USE gcc. I don't DEVELOP it, so I'm not ecev supposed know how it works. It's just a bonus. Having documentation of all the command-line options and all the other things listed in the manual is enough.
I just asked a simple question. I WILL learn more about GCC gruadually, but right now what I need is the answer to my question. If you're not planning to help, I don't understand why you posted here in the first place...

Also, I think I already know the answer (gcc -shared makes sure constructors of exported objects are executed, while ld doesn't), so if you don't know the full answer it's ok if you don't bother, King Sergei.

Dude, this forum is also about not answering questions asked by those, who don't deserve it.

This is your very first statement:

http://www.linuxquestions.org/questi...6/#post3923626 :

The items in bold indicate one or more of the following:

1. you didn't even read the 'gcc' documentation, but you lied stating you did;
2. you were incapable of using "Find" function in the documentation browser you used;
3. you were lazy to use "Find" function sufficient number of times while reading the documentation;
4. you can't comprehend what you are reading.

.

Neither of the above possibilities encourages answering your questions.

Could you tell me where you found that in the documentation and/or what experiment gave you that result.

I would not have expected that difference. I probably wouldn't know, because I rarely export any C++ interface from a .so. I generally use only extern "C" interfaces on the boundaries of my .so files, even though the main executable and the .so are both internally C++. But I have browsed enough documentation, I would have expected to remember something about that difference if it is correct.

I believe that is a more complicated topic than you would expect. The keyword "visibility" shows up in most discussions of that topic. You might try some google searches including that with other appropriate keywords.

The Unix compatible defaults make much more visible on .so boundaries. That also happens by default in both directions, so a function statically linked into a .so can be interposed at load time so that .so instead uses the same named function linked into the main executable or into some .so that was loaded earlier.

Normally a symbol you intend to resolve from a .so would appear in the calling source code exactly the same as one resolved from a static library.

At link time, the linker must be told to read the .so files along with any static libraries. Anything the linker decides should be resolved at load time from a .so will be left unresolved at link time. (So in reading the .so files, the linker does not resolve anything from .so files, it just decides what can be left unresolved).

Folks;
Please tone down the personal comments and criticisms. thank you.