SergMarkov, почему тогда в названии созданного слакбилдом пакета есть (в моем случае) x86_64 на 64-битном компьютере?

Это верно в части установленных на момент сборки библиотек, при условии использования соответствующих средств автоконфигурирования (например, ./configure из autotools).
И неверно в части "прибитых гвоздиком" внутри SlackBuild-а параметров: CCFLAGS, LDFLAGS, параметров configure --with-option, --without-option, --enable-option, --disable-option, и т.п.

Потому что процессоров x64 как собак нерезаных :-) и слакбилд настроен именно что на средний или абстрактный x64 а не на какой то конкретный.
Вообще говоря слакбилд со skackbuild.org в своем природном виде это далеко не самый лучший выбор если делать систему под себя. Проги в них со стандартными опциями и настройками, если это устраивает, ну и прекрасно, если нет, то лучше его править ручками, делать свои опции конфигурирования самой проги и заменять опции компиляции и линковки на свои. Если первое приходится делать ручками (но и тут можно как то автоматизировать) то второе делается через простейший скриптик с sed. Впрочем еще лучше сделать свой стандартный слакбилд и править опции конфигурирования проги в нем, это получается проще

Вход в систему осуществляется по средствам gdm(предварительно выставив runlevels 4 в /etc/inittab) под обычным пользователем, затем gnome-terminal > su > locale. В консоли я заходил под root.

Команда cat .profile | grep LANG ни чего не выдает.
Вот собственно сам .profile:

PS:bormant, по поводу репозитория с дополнительными зависимостями все понятно.И еще хотел спросить: ни чего страшного если устанавливать пакеты для разных версий слаки(например 13.37 и 13.1)

Это та же самая ошибка, что описана тут: http://www.slackware.ru/wiki/BugFix/13.1/su.

/source/a/shadow/shadow-4.1.4.3.tar.xz
src/libmisc/env.c
строка 254:
-            if (strchr (*cur, '/') != NULL) {
+            if (strchr (*cur, '/') == NULL) {

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

Не нашел описание редактирования program.SlackBuild, и в частности SLKCFLAGS и архитектуры для оптимизации.
Подскажите, если знаете.

Перечитывал раз 50 эту статью

И не помогло? Гуглить не пробовали на тему CFLAGS optimizations (на сколько я понимаю CFLAGS равносильно SLKCFLAGS, но могу ошибаться) или остается только одно читать и разбираться с GCC Optimize Options

Оптимальные флаги находятся методом научного тыка :-) и последующим замером производительности
У меня к примеру это
-O3 -march=native -mtune=native -fomit-frame-pointer -pipe -msse4 -falign-jumps=1 -falign-labels=1 Тоже самое стоит и в опциях cmake и qmake. Но это только для конкретного компа и флаги выбраны по замерам производительности. Впрочем native pipe и fomit применимы и в самом общем случае. Единственно что с fomit нельзя пересобирать gtk.  Да-да :-) -O3 это некошерно, но проблем с ним не имел, к тому же не сервер с доками на лямы баксов
Плюс, что давно ставят практически везде, но почему то не ставит Патрик
LDFLAGS="-Wl,-O1 -Wl,--as-needed

Это да :-) Но в принципе есть самые общие флаги, native, pipe, fomit, остальное от лукавого и надо мерять производительность на конкретном компе с разными флагами
Немного не здесь, вот где флаги под процессор, они по линкам
http://en.gentoo-wiki.com/wiki/Safe_Cflags
но в принципе лучше не парить себе мозги и ставить native

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

man gcc

-mcpu=cpu_type
           ...

           Native Linux/GNU toolchains also support the value native, which selects the best architecture option for the host
           processor.  -mcpu=native has no effect if GCC does not recognize the processor.

-mtune=cpu_type
           Set only the instruction scheduling parameters for machine type cpu_type.  The instruction set is not changed.

           Native Linux/GNU toolchains also support the value native, which selects the best architecture option for the host
           processor.  -mtune=native has no effect if GCC does not recognize the processor.

тыц
есть конечно много мнений на этот вопрос , но (!) - весьма существенное - то что выставлено по дефолту в(практически любом) слакбилде это практически золотая середина и дело не процессоре как таковом ( да будь он хоть десятиядерным турбо-монстром) дело в коде ! .. поясню :
... к примеру у вас corei7 и вы выкрутили "все ручки на красное" , выставили MAKEFLAGS="-j9" - превосходно ! вы надеетесь таким образом собрать Gnome3  за три часа - не надейтесь этого не будет , более того , то что без проблем за двенадцать часов собирается на дохленьком Целероне , на вашем монстре встанет колом через пять минут с какой нибудь потешной ошибкой и вы никогда не найдёте её причин . Вопрос почему ? Всё очень просто - те кто пишет софт , пишет его по вдохновению на том что есть и в 99% случаев "ложит с большим прибором" на ваши многоядерные монстры и параллелизм , поэтому не стоит возлагать большие надежды на то , что какой нибудь там Inkscape или VLC вдруг начнёт собираться в двадцать раз быстрее если запустить его в 9 нитей сборки - не факт что вообще соберётся , а если соберётся то будет правильно работать . Читайте доки на то что хотите собирать , как правило разработчики явно объявляют о поддержке многоядерности и параллелизма ...