really necessary to segregate the locations of static and shared versions of Qt?

Recently I was editing the hints section of the building Qt statically on Linux page and I learnt a lot of things.

I have raised a question there about whether it is really necessary to separate the install locations of static and shared versions of the Qt library, seeing as the linker has an option -static which forces it to use static libraries when available, thus overriding its behaviour of defaulting to shared libraries when both are found in the library path.

Please elucidate the situation and correct the wiki page also accordingly, providing an answer to my question. Thank you.

On Linux it doesn't make much difference where are the libraries if you're sure the linker will take the one you want(*), but on Windows the library consists of two parts - the real dynamic object and a static stub linked to the application. The static library and stub for the dynamic version are named the same, so you can't keep them in the same directory.

*) what happens if you want a shared build but a shared object is missing whereas a static one is present? The linker will try to use the static one, which is not what you want.

Quote:

---

Originally Posted by wysota

on Windows the library consists of two parts - the real dynamic object and a static stub linked to the application. The static library and stub for the dynamic version are named the same, so you can't keep them in the same directory.

---

I don't fully understand. What is this stub thing? (Wikipedia did not help.)

I thought that on Windows shared libs are present as dll files and static libs are present as lib files and the linking behaviour is the same as on Linux. From what you say, apparently this isn't true. Are you saying that libs are never static-linked on Windows and only some form of pseudo static-linking is done?

Quote:

---

what happens if you want a shared build but a shared object is missing whereas a static one is present? The linker will try to use the static one, which is not what you want.

---

I will prevent this using the explicit -call_shared option. Won't that work?

BTW is it possible to specify in the qmake build system which libraries to link static and which to link dynamic? I don't seem to see anything on this in the qmake reference.

Quote:

---

Originally Posted by jamadagni

I don't fully understand. What is this stub thing? (Wikipedia did not help.)

I thought that on Windows shared libs are present as dll files and static libs are present as lib files and the linking behaviour is the same as on Linux. From what you say, apparently this isn't true. Are you saying that libs are never static-linked on Windows and only some form of pseudo static-linking is done?

---

No, I mean that even if you link your application dynamically, you need to link (statically) against a small .lib (or .a) file during compilation. Static linkage works as usual.

Quote:

---

I will prevent this using the explicit -call_shared option. Won't that work?

---

Do you use that flag for every project of yours?

Quote:

---

BTW is it possible to specify in the qmake build system which libraries to link static and which to link dynamic? I don't seem to see anything on this in the qmake reference.

---

No, it's the linker that decides what and how to link. The only portable thing you can do is to ask for static linkage which will prevent any libraries from being linked dynamically. If you want more, you have to use implementation-specific switches.

Quote:

---

Originally Posted by wysota

Do you use that flag for every project of yours?

---

Of course not. I was only discussing the possibilities.

Quote:

---

If you want more, you have to use implementation-specific switches.

---

You mean switches to ld? Such as...?

Quote:

---

Originally Posted by jamadagni

You mean switches to ld? Such as...?

---

I don't know... "any" switches...