неділю, 24 жовтня 2010 р.

Sleipnir та boost::regex

Sleipnir/stdafx.h містить макрос

#define strcpy_s(a,b,c) strcpy(a,c)

Цей макрос ламає boost::re_detail::strcpy. Тому включення boost/regex.hpp має завжди бути до включення Sleipir/stdafx.h

четвер, 20 травня 2010 р.

Посилання

Майже всі хеші та масиви у GBrowse доступні через посилання. Наприклад, настройки у html1 можно дістати наступним чином.


html1 = sub {
my $txt;
my $cfg = $_[1];
while (my ($key, $value) = each(%$c)) {
$txt .= "$key : $value";
}
return $txt;
}

Як сховати стежку у GBrowse

Howto стверджує, що за це відповідає параметр visible. Можливо так і є у версіях 2.х, але у 1.70 має бути 'hide = 1'

пʼятницю, 26 березня 2010 р.

libjpeg на Леопарді

Дуже багато часу змарнував з цим libjpeg'ом. Помилки бувають різні, але переважно компілятор скаржиться що якась функція відсутня у /usr/local/lib/libJPEG.dylib. Леопард має свої вбудовані бібліотеки для зображень і вони розташовані у /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources. Проте всі вони мають одну осбливість: назва після lib йде великими літерами. Наприклад, libJPEG.dylib або libTIFF.dylib. Бібліотеки досить старі і побудовані під Леопард, тому в них є деякі функції, що відсутні у стандарних версіях доступних до завантаження. Якщо стандартні версії встановлені у /usr/local/lib та змінні LD_LIBRARY_PATH і DYLD_LIBRARY_PATH вказують на ту директорію, компілятор використовуватими неприйнятну версію. (Нагадаю, що типова файлова система під Леопардом не залежить від реґістру; тому libjpeg.dylib та libJPEG.dylib не відрізняються.) У таких випадках перед компілюванням треба додати стежку до Леопардівських бібліотек.

export LD_LIBRARY_PATH=/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources:$LD_LIBRARY_PATH
export DYLD_LIBRARY_PATH=$LD_LIBRARY_PATH


Джерело натхнення: http://tolstoy.newcastle.edu.au/R/devel/05/05/0755.html

неділю, 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.