неділя, 21 лютого 2010 р.

libsequence та прапорці

Чомусь libsequence ігнорує змінні середовища. Заміст

export CFLAGS="-arch x86_64"
./configure

має бути

./configure CFLAGS="-arch x86_64" CPPFLAGS="-arch x86_64" \
CXXFLAGS="-arch x86_64" LDFLAGS="-arch x86_64"

Boost

Треба було скомпілювати Boost під Дарвіном. Щоб не думати що там обере лінкер під час запуску, хотілось виключно 64-бітну версію і лише для Інтел. Документація на сайті чомусь не дуже. Щонайменше у мене недостатньо досвіду, щоб зрозуміти, що саме вони мають на увазі. Отже...

./bootstrap --with-libraries=regex,filesystem,iostreams
sudo ./bjam link=static threading=multi architecture=x86 \
address-model=64 install

Опції:

link={static|shared}
architecture={ppc|x86|combined}
address-model={32|64|32_64}

четвер, 4 лютого 2010 р.

Зіпсований кеш шрифтів

Одержав два документи у форматі Майкрософт і не зміг їх відкрити жодною програмою. Потім помітив, що всі виринаючі повідомлення OpenOffice не містять тексту. Деяка графіка теж попсувалася. Проблему вирішив через видалення кешу шрифтів.

atsutil databases -removeUser
atsutil server -shutdown
atsutil server -ping

пʼятниця, 29 січня 2010 р.

Особливості компіляції під Леопардом

Вже другий тиждень боркаюся зі встановленням Gbrowse на старий сервер з двома процесорами G5 і Леопардом. По-перше, за умовчанням архітектура є ppc, але Apache використовує ppc64. Навіть якщо встановити PATH=/usr/local/lib:/usr/lib, деякі пакети (наприклад jpeg-7 та GD) під час встановлення лізуть до /usr/lib, а потім обурюються, що не та версія або не така архітектура. Щоб їх одурити, мав терміново замінити /usr/lib/libiconv.2.dylib та /usr/lib/libiconv.la символичними посиланнями на відповідні бібліотеки у /usr/local/lib.

Почав робити універсальні об'єкти під ppc та ppc64, але деякі пакети відмовились компілюватись. Наприклад, pkg-config та glibc щось там плели про несумісність прапорців -M з подвійним прапорцем -arch. Знайшов інструкцію для libtiff на http://www.kyngchaos.com/macosx:build:libtiff . Після кількох тестів, виявив, що решта пакунків теж компілюються з прапорцем --disable-dependency-tracking .

Дерево (перелік) залежностей можна знати на http://ifeghali.blogspot.com/2008/03/compiling-gtk-on-mac-os-x-105-leopard.html .

Моя рекомендація: використовуйте fink або darwinports і не морочте голови.

PS Містика. Спробував перекомпілювати libiconv і прапорець --disable-dependency-tracking вже не допомогав. Врешті решт, спрацювало ось що.

export ARCHFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64"
CFLAGS="$ARCHFLAGS -pipe" \
CCFLAGS="$ARCHFLAGS -Os -pipe" \
CXXFLAGS="$ARCHFLAGS -Os -pipe" \
LDFLAGS="$ARCHFLAGS -bind_at_load" \
./configure --enable-static

Проте різниці я не бачу взагалі.

PPS Конфігурацію для glib треба робити під root. Інакше вилазить така помилка:
configure: error:
*** GLib requires a 64 bit type. You might want to consider
*** using the GNU C compiler.

AFP

Байдуже, що там каже Apple, у жодному разі не використовуйте AFP для віддалених тек користувачів. Після завантаження, сервер використовує рахунок першого користувача для монтування теки Users. Втім жоден інший користувач не може зайти через невідповідність прав на теку. Можно побачити щось на кшталт

d---------+ 4 user1 group1 136 Jan 15 09:22 user1
d---------+ 4 user2 group1 136 Jan 15 09:40 user2

Крім того, монтування не працює автоматично при користуванні SSH. Автоматичне монтування інших тек по протоколу AFP має ті ж самі вади. Тому краще автомонтувати все по протоколу NFS.