Linux установка PostgreSQL

[Single]

Появилась необходимость поставить PostgreSQL 9.0
Ставил по гайду openscg

Появилась ошибка (при компиляции php но это не суть важно):

/usr/bin/ld: warning: libssl.so.6, needed by /opt/postgres/9.0/lib/libpq.so, may conflict with libssl.so.0.9.8

из ошибки понятно что конфликтуют либы хотя не совсем понятно с чего бы вдруг.
может кто решал подобную проблему и в курсе как правильно пролинковать уже установленный постгресс со своими либами на шаред либы.

можно конечно сделать это установкой постгресса из исходников но как то пока не сильно хотелось бы это делать, не видел толковых гайдов по сборке.

 

[MiksIr]

Это варнинг, а не ошибка. И что, что-то не работает?

 

[Single]

php не собирается если все модули используют шаред либы а постгрес отдельно свои.
вот думаю как бы постгрес слинковать с общими либами.
проблема по сути в том что постгрес ставится из деб пакета и внести поправки в конфиг не представляется возможным.

 

[Single]

в итоге поставил postgresql-8.4 с которым нет таких проблем.

 

[grigori]

как же народ рвет задницы за целостность дебиановских пакетов!
хоть бы в одной теме хоть кто-то написал "все работает отлично, проблем нет, делай так"
нет, все мучаются, но хранят пакеты во веки веков

 

[MiksIr]

Ну просто или пакеты или сырцы... или пакеты и сырцы + голова. Там, имхо, проблема то не в этом была, а если и в этом - симлинком решилась бы скорее всего.

 

[tz-lom]

MiksIr
каким нафиг симлинком,такие именования либ делались специально,а ты хочешь всё это запороть
а вообще народ тратит кучу времени на выпасывание пакетного менеджера,хотя пересобрать критичные пакеты не так и сложно,зато даст прирост в скорости

 

[Dovg]

хотя пересобрать критичные пакеты не так и сложно,зато даст прирост в скорости

Замерял?

По моему глубокому убеждению прирост скорости работы после пересбора чего-либо на большинстве типичных задач - это миф.

 

[tz-lom]

Dovg
да
это не миф а обоснованный факт,при пересборке вы можете оптимизировать код под конкретный процессор,а в пакетах у вас код который должен завестись на куче платформ,т.е. особенности конкретно вашего процессора в нём не используются
прирост не большой,но в купе с точным знанием того с какими патчами и флагами собран софт,а так же возможностью его быстро пересобрать,с лёгкостью дособирать к нему модули итд это сильно упрощает жизнь,во всяком случае мне

 

[Dovg]

tz-lom
У меня тоже раньше была гента.
Опять же ИМХО процессорного времени на сборку расходуется больше, чем получается выигрыш от пересборки ).

 

[MiksIr]

да
это не миф а обоснованный факт

Обоснованные факты принято приводить с цифрами. А без этого человек считается... ну, все поняли.

 

[tz-lom]

MiksIr
гм,весьма грубо однако,посылаю за цифрами в гугл,там они есть
проводить тесты ещё раз ради удовлетворения вашего ЧСВ лень,обоснование идёт сразу после цитаты,если вы с чем либо из этого не согласны можете привести своё мнение

 

[Absinthe]

при пересборке вы можете оптимизировать код под конкретный процессор

Т.е. если у меня есть 2 одинаковых компьютера, то скомпилированная на первом программа будет медленнее работать на втором? Что за фигня, где логика?

 

[cDLEON]

Т.е. если у меня есть 2 одинаковых компьютера, то скомпилированная на первом программа будет медленнее работать на втором? Что за фигня, где логика?

код под конкретный процессор

 

[Absinthe]

Ни разу не видел в бинарниках записей серийника процессора и инструкций "тормозить, если запущено не там, где собрано".
Так все же почему должен быть прирост?

 

[tz-lom]

Ни разу не видел в бинарниках записей серийника процессора и инструкций "тормозить, если запущено не там, где собрано".

хмм , Intel C++ compiler и AMD процы
кстати из этой же фразы делаю вывод что с этой темой вы не знакомы абсолютно,так что может перечитаете тему ещё раз,там уже всё написано

но не об этом речь
а речь о том что сборка дистрибутива ведётся допустим под 586 MMX , а у вас - 686 MMX SSE SSE2 SSE3 SSSE3 итд итп ,и не в "запущено не там где собрано" суть,а в том что фичи конкретного проца не используются,а где оно собранно - не важно,можно и на старом бревне собрать под современный проц

 

[Absinthe]

tz-lom, давайте не будем говорить абстрактно.

Вот возьмем проц 2006 года. И 2011. В чем разница? Правда считаете, что включив SSE 4A или SSSE3 повысите производительность apache или PHP?
А к чему говорите про i586?

 

[tz-lom]

Правда считаете, что включив SSE 4A или SSSE3 повысите производительность apache или PHP?

а что,понизим?

А к чему говорите про i586?

к тому что у того же дебиана есть и 386 ветка
а вот и его CFLAGS:
-g -O2 -g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g

 

[Absinthe]

а что,понизим?

Да нет, такая же будет.

к тому что у того же дебиана есть и 386 ветка

И что? Если кто-то использует подобную ветку - то это целенаправленный шаг уменьшения производительности.

А тот же amd64 не будет отличаться в производительности от красноглазой сборки.
А я то думал, что вы пытаетесь впарить, что в никсах есть закладки в стиле "если чужой_серийник_проца: тормозить()"

С чего ему тормозить, если в некрасноглазых сборках используются все последние инструкции кроме специфических(которые понадобиться могут лишь в узких задачах, и то на них есть отдельные пакеты в зависимости от архитектуры)

 

[tz-lom]

Absinthe
у тебя никс какой?
просто посмотри на свои CFLAGS , сравни с
gcc -Q --help=optimizers
особое внимание на -march
при особом желании запусти acovea , и узнай что там должно было бы быть для максимальной производительности

в "не красноглазых" сборках используются не все инструкции - у них есть понятие совместимости , и выше него в дистро не поднимаются, можно кучу раз говорить о том что новые инструкции нужны только для специфических задач,но допустим в том же SSE4.2 есть весьма полезные операции над строками (которые не только для этого могут использоваться) , а так же CRC32 (и не надо говорить что эта штука не используется)