Добрый день. Есть ли на форуме люди, которым удалось осуществить статическую линковку своих программ с libpq.a в MinGW? Если да - поделитесь опытом, как вам это удалось. Бюсь вторую неделю - все бестолку. В dependencies все время фигурирует libpq.dll (без нее есесно ничего не запускается).

молодец, знаешь русский язык (филфак заканчивал?). когда станешь программистом - поймешь и мой вопрос.

http://en.wikipedia.org/wiki/Static_library - просьба прочитать последнюю строку в конце первого абзаца и товарищам Ожеговым сюда больше не писать

Командная строка:


Без ошибок. Но в dependencies все время фигурирует libpq.dll. Ни на какие мысли это не наводит, т.к.:
1. lpq - это libpq.a (статическая либа - аналог libpq.lib для VS).
2. libpq.dll специально везде поубирал из всех папок.

Но без libpq.dll программа не запускатеся.

Более глубинно - libpq нужна QtSql модулю.

По поводу чувака с крутой историей сообщений:

http://en.wikipedia.org/wiki/Static_library, читаем конец первого абзаца сверху:
авторHowever it is debatable whether such a process can be called static linking.

согласен, что debatable, но у меня вопрос в другом.

Очевидно, человек хотел сказать, что libpq.a - это не статическая либа, и, соответсвенно, в документации все врут, и то что все либы, заканчивающиеся на "a" - статические это миф и т.п. Это было бы по существу.

авторДалее. Как я понимаю - QtSql у вас уже скомпилен, причем он *.dll и
кроме него libpq.dll ничего не использует.

Qt собрана статически, QtSql прилинковывается статически.

Насчет моей libpq.a - она действительно содержит только переходники на dll. В таком случае вопрос: как используя средства MingW (MSYS) сбилдить реальную статическую libpq.a?

Исходные тексты естественно есть. Проблема оказалась в параметре enable_shared = no, который не был указан при компилляции libpq.a. Документированный --disable-shared в configure не спасал.
Проблема решена, всем спасибо.

Кстати, баг (или фиче) сборки libpq.a так и осталась, может кому пригодиться на будущее (из-за чего и возникла проблема изначально).

Заключается оно в следующем: если сначала собрать libpq в виде shared library, то потом никак не получится скомпилить статическую версию без удаления псевдо-статической.

Вот нерабочий вариант:
1. make install (динамическая libpq.dll и псевдо-статическая libpq.a библиотеки созданы).
2. make install enable_shared=no (получить реальную статическую libpq.a - облом).
Реальная статическая libpq.a не создана. Вместо нее мы видим старую, псевдо-статическую libpq.a.

Еще один нерабочий варинат:
1. make install enable_shared=no (создана статическую libpq.a - таки да, создана).
2. make install (динамическая libpq.dll и псевдо-статическая libpq.a библиотеки созданы).
Реальная статическая библиотека полученная на первом шаге затерта псевдо-статической...

Вот правильный, рабочий вариант:
В каталоге "\src\interfaces\libpq\":
1. make install (динамическая libpq.dll и псевдо-статическая libpq.a библиотеки собраны).
2. Удалить псевдо-статическую libpq.a.
3. make install enable_shared=no (получить реальную статическую libpq.a).

Странно, почему псевдо-статическая libpq.a может затирать статическую libpq.a, а наоборот этого не происходит. Кажется, половина всех проблем по libpq на всех форумах заключается именно в этом глюке.

про make clean я знал. Просто еще раз: скомпилить libpq.a статическую, а потом динамическую - можно вообще без make clean. Наоборот - нет.

Было бы понятно, если б без "make clean" вообще ничего собрать нельзя, а так - глюк.