Building GnuTLS on OS X

How to build GnuTLS on OS X 10.9+

    In my job I was need to build GnuTLS for OS X. But this task to complicated by the fact that I was need to build package on clean machine without any packets manager system like MacPorts. I thought that this task will be easy for my because during my experience I have build a lot of libraries. But I was wrong because GnuTLS have few non-obvious dependencies. And  I spend whole day or maybe bit more for solving.
    In this article I will try to explain how to build step by step but in pseudocode, so you will need to correct steps for themselves.

From the GnuTLS site you can know that GnuTLS requires 2 libraries libnettle and gmplib. But don't hurry to download them. First you need check availability pkg-config utility. If you don't have you will need to install it. Easiest was to do that - it’s download pkg file from the website: macpkg.sourceforge.net
Then you need check PKG_CONFIG_PATH env variable. Something like that will help you:

    echo $PKG_CONFIG_PATH

    Output of this command should have valid paths. In my case they are not! So I was need next:

    EXPORT pkg_config_path=/usr/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/X11/lib/pkgconfig

1. Download and build gmp lib before libnettle - first.
2. For some reasons configure of libnettle could found headers and binaries of gmplib. So I was need to export this env’s too:

export CPPFLAGS=“-I/usr/local/include”

export LDFLAGS=“-L/usr/local/lib”

3. download and build libnettle
4. download and build libtasn1 - yes I know that this library marked as optional but in my case I couldn't found how disable it in configure and I was needed to build it first.
5. download and build libhogweed - same as previous
6. download and build GnuTLS! Don't forget to turn off p11-kit. Sure if you don't need it
./configure —without-p11-kit

Enjoy!

Interface Builder plugins

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

Как источник вдохновления и поиска новых интересных решений для меня является просмотр и изучения OpenSource проектов. Иммено в них я впервые увидел плагины для IB. Достаточно полезная штука, как оказалось...

Плагин представляет собой файл с расширением *.ibplugin. Для его установки в систему необходимо просто 2 раза кликнуть на него. Именно такой способ установки наткнул меня на мысль о том, что нормально компилируемый проект на моем Maс'е совсем не значит что проект успешно соберется на другом... Собрав простенький проект и при попытке скомпилировать на другом, XCode выдал ошибку Unable to resolve plug-in dependency for "MainMenu.xib". : Такое поведение нарушает один из принципов Continuous Integration. Гугл в этом вопросе мне не помог поэтому пришлось самому искать ответ. Первым делом я решил, что скорее всего пути можно прописать в самом XIB'e. Полазив по настройкам ничего подобного я не нашел. После этого я решил поискать соответствующие настройки в самом проекте.

Оказывается в настройках проекта XCoda можно найти целую секцию: Interface Builder XIB Compiler - Options которая отвечает за настройки компиляции файлов IB. И в частности нас интересует пункт Plug-In Search Paths Именно этот пункт отвечает за директорию в которой искать плагины. По этому для себя я определил структуру проекта: в корне проекта у меня находится папочка 3rdparty, в которой хранятся все сторонние библиотеки используемые в проекте. В папочке 3rdparty находится подпапочка binaries, которая в частности отвечает за бинарные данные т.е. статические динамические библиотеки, плагины и т.д. Тогда путь к библиотекам и плагинам будет достаточно простой: $(SRCROOT)/3rd_party/binaries

Статический анализ кода

 Недавно, в моем проекте возникла проблема. Суть ее заключалась в не стабильных крэшах приложения, которые было очень трудно воспроизвести и редко повторялись, но тем не менее они присутстовали, чем сильно раздражали. Главая из версий, объясняющая их была до банальности проста – не коректная работа с памятью. На поиски освобожденных / не освобожденных объектов было потрачено не один день. Было найдено и справленно несколько других багов связанных с памятью, но это не привело к ожидаемому результату.

 Буквально недавно, я узнал, что в Xcode 3.2 есть возможность статического анализа кода. Статический анализ – это анализ выполняемый над версией кода, с целью выявления мест содержащих ошибки. Встроеный в Xcode 3.2 анализатор, основан на консольном анализаторе clang. Если вы щасливый обладатель OS X Snow Leopard и Xcode 3.2, то советую вам прочитать статью из эпловской документации:

http://developer.apple.com/mac/library/featuredarticles/StaticAnalysis/index.html

иначе читаем далее.

Для начала нам предстоит установить анализтор clang. Для этого мы должны скачать архив checker-0.223.tar.bz2 с сайта:

http://clang-analyzer.llvm.org/

и распаковать его, скажем, на рабочий стол. В итоге, на вашем рабочем столе, у вас окажется папка checker-0.223. Теперь переместим папку checker-0.223 в дирректорию /usr/bin. Запустите Терминал, перейдите на Рабочий стол и выполните команду:

sudo mv checker-0.223 /usr/bin/

Теперь перейдите в папку /usr/bin/ и создайте символьные ссылки на статический анализатор и просмотрщик результатов:

sudo ln -s checker-0.223/scan-build scan-build

sudo ln -s checker-0.223/scan-view scan-view

На этом установка анализатора завершена. Перейдем непосредственно к настройке проэкта. Настраивать особо много не прийдется, только Code sign и Base SDK. Для настройки Code sign, зайдите в настройки таргета, на вкладку Build, перейдите в секцию Code signing и для ключа Any iPhone Device выберете Don't Code Sign:

Теперь зайдите в настройки проэкта, на вкладку General и выберите iPhone Simulator 2.1 для Base SDK for All Configurations.

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

При установке Xcod'а, по умолчанию установливается замечательная консольная утилита xcodebuild. Она позволяет собирать ваш проект из под консоли. Именно связка xcodebuild + scan-build, даст нам возможность найти баги в нашем коде.

Создадим новый Window Based проект с названием TestProject и добавим в метод applicationDidFinishLaunching код:

NSString *testString;

NSString *testString2;

testString2 = [testString copy];

Сразу предупрежу вас, что код заведомо содержит ошибки. Они созданы с целью показать возможности статического анализатора.

Теперь сохраним проект, запустим консоль и перейдем в папку проекта. Остается только выполнить статический анализ. Очень хорошо, перед каждым анализом очистить проект. Для этого вызовете команду:

scan-build xcodebuild -configuration Debug clean

ну и после ее выполнения, запустите сам статический анализатор:

scan-build -k -V xcodebuild -configuration Debug

В результате, после билда и анализа у вас в консоль напишется что то типа того:

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

cd /var/folders/qE/qEWzPoglGVWOVJJ2d-amzU+++TI/-Tmp-/scan-build-2009-10-05-1

open index.html

В результате у вас загрузится браузер, в котором будет html отчет отображающий результат анализа:

Сам отчет разделен на 3 части:

1. информация о билде (пользователь, дата путь);
2. количество найденных багов, разбитые на категории;
3. список файлов, в которых найдены баги.

Для удобства вы можете выбрать определенный тип ошибок, убрав или проставив галочки. Наибольший же интерес для нас представляет раздел Reports, в котором, как сказанно выше, отображается список файлов в которых найдены баги. Нажав на ссылку View Report, вы можете просмотреть подробный отчет по определенной ошибке в файле. В подробном отчете отображается линия в которой найдено уязвимое место и примерное описание что не так. Вам остается хорошенько проанализировать код, ведь анализатор не искуственный интеллект, и если уязвимость подтверждается, исправить ее.

Если честно, для меня остается загадкой, по какому приницпу определяются файлы в которых присутствуют ошибки. Так как бывали такие места, в которых явно были “опсные” места, а анализатор не помечал их. Надеюсь в ближайшем будущем я разберусь в этом и подправлю статью. Хоть анализатор нашел в проекте несколько критических утечек, но все равно приходится быть внимательным. Чего и вам желаю.

Борьба с утечками памяти

Наверное 90% крэшей приложения связанно с некоректной работой с памятью. Иногда, в большом проэкте, чтоб отловить такой крэш может затратиться значительное время. И хорошо, когда по внешним признакам падения приложения(то есть на каком экране или при каких действия пользователя) можно определить из за чего именно оно упало. Но к сожалению не всегда так. Какие же первые меры необходимо принять, после крэша? На мой взгляд самое логичное и простое – это посмотреть, что вывелось в консоль дебагера. Чаще всего в консоли можно увидеть такое сообщение:

Первая фраза, из сообщения:
-[NewObject show]: unrecognized selector sent to instance 0x12179b0
указывает на то, что у объекта NewObject был вызван не существующий метод show. Здесь, все просто – возможны 2 варианта:

• вы просто ошиблись с именем метода или со списком передваемых параметров;
  
• NewObject не NewObject, а что то другое. Такой вариант возможен, когда вы используете авторелизные объекты. Вы посылаете сообщение объекту, который был уже освобожден и в итоге в переменной хранятся некоректные данные (к примеру указатель на другой объект). Так что вам предстоит кропотливый поиск освобожденного объекта.
  

Но за частую консоль не предоставляет никакой отладочной информации. Для такого случая в Xcode предоставляется средство позволяющее ускорить процесс поиска освобожденного объекта. Для активации этого средства необходимо прописать переменную окружения NSZombieEnabled и установить ее значение в YES. Для этого в группе Executables вызовте свойства для вашего executable: В появившемся окне перейдите на вкладку Arguments добавте перменную окружения NSZombieEnabled и установите ее значение YES. В итоге у вас должно быть нечто вроде этого: Теперь можете опять попробовать запустить приложение. В этом случае сообщение будет посодержательней: Ну а далее – знание проекта и ваша интуиция... Эти способы хорошо применять на часто повторяющихся крэшах, которые удается воспроизвести при определенных действиях. Но иногда возникает такое ощущние, что программа начала жить своей жизнью. То работает, работает при определенных действиях, а потом ни с того ни с его падает. В такой ситуации следует вводить “тяжелую артилерию”. Под тяжелой артилерией я понимаю интсрумент Leaks и статический анализатор кода, о котором я расскажу в следующей статье. Leaks – утилита, которая в реалтайме анализирует выделяемую и освобождаемую память и на основе полученных данных отображает объекты, которые утекают. Для того, чтоб запустить Leaks, выберете в меню Run – Start with Performance Tools – Leaks. Приложение установится в телефон/симулятор и запустится на выполнение. При этом у вас появится окно инструмента Leaks: Верхняя часть, ObjectAlloc, говорит нам о размере потребляемой памяти приложением. Нижняя часть – утечки памяти в прогамме. Если Leaks обнаруживает лики, они сразу же отобажаются в виде оранжевых пик и в виде записи процент – размер – адрес – объект. Более детальную ифнормацию вы можете посмотртеть в строке адреса, нажав на кружочек со стрелочкой: В появившемся окне наибольший инетерес вызывает столбец Responsible Caller, в который заносится метод и имя класса, у которого был вызван метод, произвевший утечку памяти. Остается только найти этот метод и исправить утекаемый объект.

Memory management

Одной из главных проблем, с которой сталкивается начинающий разработчик под iPhone, является не понимание принципов управления памятью в Cocoa, которым и посвящается данная статья.


Итак, начнем с самого начала. Как нам известно, в Objective C все строится вокруг динамических объектов. Это ведет к более рациональному использованию памяти, так как мы управляем, когда освободить объект и занимаемую им память. Из этого следует, что у каждого объекта должен быть свой владелец, от этого будет зависеть, кто должен освободить объект. Каким образом можно определить, кто является владельцем объекта? В Cocoa есть простое правило – владельцем объекта является тот, кто создал его. То есть, если вы не посылали объекту сообщение содержащее alloc, copy или new, то можете не переживать, вы не владелец объекта и вам не надо заботиться об освобождении его. Иначе прийдется считать ссылки, увеличивать, уменьшать их количество… Рассмотрим пример:

Это не правильно поведение, так как функция print не являетесь владельцем объекта strPrintText. Исправим пример:

Что же значит увеличивать уменьшать количество ссылок? В Objective C управление памятью основывается на подсчете ссылок. Все классы в иерархии наследования имеют общего предка — класс NSObject. NSObject содержит в себе счетчик ссылок (retaintCount). И методы позволяющие управлять счетчиком. При создании объекта, переменной retainCount будет присвоено значение 1 и объект будет существовать до тех пор, пока retainCount не станет равен нулю. Как только это случится, объекту будет послано сообщение dealloc и объект удалится. Для увеличения/уменьшения количества ссылок в NSObject'e есть 3 метода reatin, release и autorelease. И еще 2, которые не посредственно влияют на счетчик: alloc и copy. Для того, чтоб увеличить счетчик ссылок на 1 объекту необходимо послать сообщение retain, для уменьшения – release. Есть еще метод autorelese, который уменьшает количество ссылок на 1, но через время.


Из вышесказанного можно выделить несколько простых правил по управлению памятью:

• только владелец объекта должен освобождать объект;
  
• сообщение release должно посылается объекту столько раз, сколько раз были посланы ему сообщения retain, alloc, new или copy.
  

На мой взгляд, наибольшей неразберихи в этом простом процессе вводят авторелизные объекты. И по сему хотелось остановиться на них поподробнее.


Как говорилось выше авторелизный объект — это объект, которому было послано сообщение autorelease и у которого количество ссылок уменьшится на 1 спустя какое то время. Для осуществления этого механизма в Cocoa предусмотрен менеджер авторелизных объектов - NSAutoreleasePool. Образно говоря пул представляет из себя стэк, хранящий в себе ссылки на авторелизные объекты. После посылки объекту сообщения autorelease, ссылка на объект копируется в ближайший пул и находится там до тех пор, пока пул не будет освобожден или ему не будет послано сообщение drain. В этом случае всем объектам находящимся в пуле будет послано сообщение release, причем столько раз, сколько им было послано сообщение autorelease. Так что будьте аккуратней. Вся хитрость использования авторелизных объектов заключается в том, что вы наверняка не знаете когда они освободятся. В Cocoa приложении существует как минимум 1 пул. В этом вы можете убедиться взглянув в файл main.m вашего проекта. Но кроме этого Application Kit автоматически создает свой пул на каждый новый поток или, к примеру, обработчик события, так что в какой именно пул попадет объект и когда он освободится вы точно не знаете(Хочу заметить, что если поток создаете вы, то вы обязаны сами создать пул).


Очень часто бывает, что написав код, протестировав его, он работает прекрасно, а потом неожиданно, без видимой причины приложение валится. На 90% - это пул пытается освободить уже освобожденный обект. Так что можете смело начинать считать ссылки. Кроме того, чрезмерное использование авторелизных объектов ведет к переполнению памяти мусором, а позже и к крэшу приложения. Прочитав выше написанное получается, что авторелизный пул лучше не использовать ну или по крайней мере свести его применение к минимуму. Лично я поддерживаю это мнение, но как показывает практика, без него никуда не деться.


Когда же использовать авторелизные объекты? Давайте рассмотрим заведомо не правильный пример:

Так делать не правильно, так как функция print не является владельцем объекта string. Память под объект string была выделена в фунцкии getString, значит там и должна быть освобождена. Исправим пример:

То есть, можно сформировать следующее правило:

• используйте авторелизные объекты только тогда, когда вам их необходимо передать в качестве возвращаемого значения функции.
  

А далее или увеличивайте количество ссылок или копируйте объект.


Не выполнение этих 3х простых правил, как правило, ведет к утечкам памяти или частым крэшам приложения. В следующей статье я опишу методы борьбы с утечками и крэшами связанными с не корректной работой с памятью.

iPhone static library

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

В мире *nix систем да и вообще в мире OC существует 2 вида библиотек.

1. динамические;
2. статические.

Каждый тип библиотек имеет свои достоинства и не достатки. Прозрачный механизм создания динамических библиотек под iPhone отсутствует, хотя лично мое мнение – я не вижу большого смысла в использовании их под iPhon'ом. Нам же, наибольший интерес, представляют статические библиотеки, речь о которых пойдет далее в статье.

Статическая библиотека – это хороший способ повтороного использования кода. Кроме того, в некоторых проектах, при использовании множества не маленьких OpenSource – решений применение статических библиотек – отличный вариант сократить время на перекомпиляцию проекта. Это достигается путем хранения заранее обработанного компилятором исходного кода в объектные файлы.

В nix системах, как правило, статические библиотеки имеют расширение *.a. Таким образом, статическая библиотека – это архив, содержащий в себе объектные файлы.

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

ar -xимя_статической_библиотеки

В результатет, в том же каталоге, у вас должны появиться распакованные объектные файлы.

Итак, перейдем к практике. Практиковаться мы будем, на свежесозданном проекте и исходниках обертки над sqlite – FMDatabase.

1. Для этого создадим новый проект, к примеру Window-based Application, (тип проекта может быть любой) и назовем его MakeStaticLib. Далее, для удобства, создадим новую группу для обертки, привяжем ее к папке и добавим в нее исходники.
2. Нажмем правой кнопкой, на группу Classes и выберем пункт Add – New group. Свежесозданную группу назовем FMDatabase и создадим для нее одноименную папку. Для этого зайдем в свойства группы FMDatabase, нажмем на кнопку Choose и выберем папку, где мы хотим хранить исходники.
3. Добавим исходники FMDatabase в проект, (взять их можно с сайта http://code.google.com/p/flycode/)
4. На этом подготовительная часть окончена, теперь приступим непосредственно к созданию библиотеки. Для этого нажмем правой кнопокй на раздел Targets и выберем пункт Add – New Target.
5. В появившемся окне выберем тип target'а Static Library, назовем ее FMDatabase и нажмем Finish. В результате структура проекта должна получиться следующая:
6. Теперь приступим непосредственно к добавлению исходников к статической библиотеки. Здесь прячется небольшая хитрость. Дело в том, что при добавлении исходников в проект, по умолчанию они добавляются в главный таргет, а он у нас является MakeStaticLib. На простороах сети, в основном, я встречал способ, при котром файлы добавлялись напрямую в Static lib target, но к сожалению с первого раза я не смог повторить этот трюк и нашел другой, на мой взгляд, более красивый способ. Для этого выберем ТОЛЬКО *.m файлы, которые мы хотим, чтоб присутствовали в библиотеке, выбрем у них пункт Get Info, перейдем на вкладку Targets и сменим “пункт назначения” c MakeStaticLib на FMDatabase:
7. Далее добавим библиотеку в наш проект. Для этого мы зайдем в свойства таргета MakeStaticLib на вкладку General, и выберем один из 2х способов. Первый способ заключается в том, что мы добавим библиотеку как Direct dependencies объект. Это дает возможность, после изменения кода библиотеки, автоматически перекомпилировать статическую библиотеку во перекомпиляции всего проекта. Иначе, если вы вебрете второй способ, добавления библиотеки как Linked Libriries объект, вам будет необходим сперва перекомпилировать библиотеку вручную, а потом сам проект. На мой взгял это не совсем удобно и я бы вам порекомендовал добавлять как Direct dependencies объект.
8. И наконец последний пункт, который многие не понимают зачем делать, так как и без него все работает. Для того, чтобы в библиотеки нормально отрабатывали возможности языка Objective C (к примеру категории) необходимо добаить флаг -ObjC к флгам линковщика (Other linker flags). Делается это в Info таргета MakeStaticLib, на вкладке Build в секции Linking.

На этом создание статической библиотеки окончено.