TARGET, HOST и BUILD в autoconf

Разбираюсь с кросскомпиляцией пакета, нашел интересное и понятное объяснение отличий опиций target, build и host в autoconf.
--build: это машина на которой вы компиляете.
--host: машина для которой компилируете.
--target: машина для которой GCC сгеренинует бинарник.

Как указано в GCC documentation (Host/Target specific installation notes):

Если build, host и target одинаковые, это называется «нативная компиляция»(native).

Если build, host одинаковые, а target отличается, это называется: кросс-компиляция(cross).

Если build, host, target все разные, это называется канадская компиляция (canadian), назвали так в честь политической партии канады, у которых видимо обещания с делами сильно расходятся ))

Если target и host одинаковые, а build отличается, то вы используете кросс-компиляцию для сборки нативного бинарника для другой системы. (иногда это называют host-x-host, crossed native, или cross-built native.)

Если build и target одинаковые, а host отличается, то вы используете кросс-компилятор, чтобы скомпилять кросс-компилятор, для машины на которой в данный момент компиляете. (Иногда и такое бывает.)

 

PS. Убил кучу времени пытаясь скомпилить i386 код на amd64 системе. После каждой компиляции проверял полученный бинарник с помощью file. В результате получил заветные:

root@host:/home/serp/sbin# file zabbix_agentd
zabbix_agentd: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=0x80351655fa042fd59e60f87c61433eaf9f713e4d, not stripped

Помогло конфигурирование с помощью:

CFLAGS=»-m32″ ./configure —enable-agent —with-mysql —with-net-snmp —enable-static  —prefix=/home/serp/zabbix_compiled —host=i386

Занимательная археоелогия

Прочитал на хабре статью, автор которой проанализировал исходники DOS 1.1 и WORD 1.1a.  Много интересного для себя открыл. Пересказывать не буду, оригинал можно почитать тут: http://habrahabr.ru/company/pvs-studio/blog/217921/

В книге «Хакеры: Герои компьютерной революции», объясняется, что основное занятие хакеров — это написание инструментов для написания инструментов, для того чтобы делать «правильные вещи». И тут я не опечатался. Прикол в том, что ни один смертный этой работы не ощущает. Далеко не каждый программист способен ощутить, как много эти люди делают для индустрии программного обеспечения. Почему я так подумал? Да элементарно! С какой легкостью СЕГОДНЯ с помощью современного ИНСТРУМЕНТА человек сумел оперативно найти кучу недоработок в немаленькой программе, которую писал не один человек, и не два…

А ведь и сейчас есть такие же хакеры (слово заезженное, поэтому, в современных реалиях имеет несколько искаженный смысл), которые делают инструменты, что бы делать инструменты… Двигающие ту самую Computer Scienсe, но результат работы которых мы сможем ощутить не скоро…

Для того, что бы понять это, почувствовать, нужно много лет. В общем занятие не для любителей славы и известности.

Яков Сироткин — о геномном ассемблере.

Было очень интересно послушать по поводу того, как расшифровывается геном человека. Для тех кому лень, или нет времени — суть вот в чем: 1. Геном (или ДНК) невозможно просто взять и прочитать. 2. Для построения полной цепочки ДНК используются тысячи небольших отрезков по 100 — 200 символов, называемые ридами. 3. Риды взаимно перекрываются, и нет информации о том, из какой части ДНК данный конкретный рид. 4. Риды могут содержать ошибки, например при эксперименте в образц может примешаться ДНК человека, или какой-нить кишечной палочки (руки мыть надо). 5. ДНК человека (готовая цепочка) в состоящая из символов A,G,T,C, занимает больше 3 гигабайт. 6. Исходные данные (набор ридов), для построения цепочки, в сотни раз больше, чем результирующая цепочка. Вот и представьте, что, как и на каком железе нужно делать, что б получить ДНК человека….

Аттракцион невиданной щедрости.

Сенсация! Компания Microsoft открыла исходники DOS v1.1 и v2.0, а также Word for Windows 1.1a. Вклад компании в светлое будущее и OpenSource Community неоценим! )))

Есть предположение, что они просто стесняются открывать код своих продуктов, в подтверждение этой версии, вот такие комментарии нашлись в открытых сырцах:

 $ grep -ri fuck .
    ./Opus/asm/wordgrep.asm:; BP  is used as always, the other registers are free to fuck with.
    ./Opus/asm/wordgrep.asm:	je	another_fucking_out_of_range_jump
    ./Opus/asm/wordgrep.asm:another_fucking_out_of_range_jump:

./Opus/asm/formatn.asm in Word v1.1a:

    ; /* Following comment is preserved verbatim for eternity */
    ; /* Rounding becomes a non-existant issue due to brilliant re-thinking */
    ; /* "What a piece of work is man
    ;	How noble in reason
    ;	In form and movement,
    ;	how abject and admirable..."

    ;		 Bill "Shake" Spear [describing Sand Word] */

Но больше всего, меня порадовала дискуссия в комментах:

ххх>Скоро портируют на ардуину

yyy>а потом появится PiMS-Dos

zzz>PiS-Dos

Подробности тут: http://habrahabr.ru/post/217081/

Как доходчиво и быстро разобраться что делает команда на bash

Сегодня нашел сайт http://explainshell.com/ всем админам настоятельно рекомендую ознакомиться. Но сразу предупрежу, не во всех браузерах работает, проверяли на firefox 25.0.1 и google chrom 16.0.

Выглядеть должно примерно так:

 

explain

 

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

Джефф Дин из компании Google — это Чак Норрис нашего времени

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

Джефф Дин считается кем-то вроде Чака Норриса. Отличие только в том, что он вовсе не герой боевиков, а инженер-программист компании Google.

Шутки о нём впервые появились на 1 апреля шесть лет назад. Один из коллег Дина по имени Кентон Варда открыл страничку, куда каждый мог добавлять факты о Джеффе Дине. Идею с энтузиазмом подхватили другие разработчики — и вскоре наполнили страничку множеством таких «фактов».

«Я ни с кем никогда не согласовывал это, — говорит Кентон Варда, — просто сделал, потому что подумал, это будет весело и народу понравится. Так всё происходит в компании Google. Но моя маленькая шутка и близко не может сравниться с самыми большими и смешными проектами в корпоративной сети».

«Когда Джефф Дин разрабатывает программу, то сначала создаёт бинарник, а потом пишет исходный код как документацию».

«Джефф Дин однажды не прошёл тест Тьюринга, потому что правильно установил 203-е число Фибоначчи менее чем за секунду».

«Джефф Дин родился 31 декабря 1969 года в 23:48. Ему потребовалось 12 минут, чтобы запустить свой первый счётчик времени».

Джефф Дин даже если захочет, уже не сможет избавиться от имиджа Чака Норриса. Впрочем, его вряд ли заботят такие мелочи. Один из ведущих программистов Google считается соавтором ключевых инфраструктурных систем компании, включая MapReduce, BigTable и Spanner. Читать

Переменные в скриплетах и jstl

Хороший пример поясняющий, как получить доступ к переменной JSP из скриплета, и наоборот:

<%@ page contentType="text/html; charset=UTF-8" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<c:set var="myTest" value="testValue"/>
#1:<c:out value="${myTest}" />
#2:<%=pageContext.getAttribute("myTest") %>

<c:set var="anotherTest" value="anotherValue" scope="request"/>
#1:<c:out value="${anotherTest}" />
#2:<%=request.getAttribute("anotherTest") %>

JSP и include

В jsp есть два вида include.
Первый — <jsp:include page=»uri»/>
Второй — <%@include file=»uri»%>

В книгах и в документации много разного понаписано по этому поводу, чаще всего пишут, что тегом подключается статическая страница, а директивой — страница с jsp. Но это фигня.

Вот самое лучшее объяснение, которое я нашел:

Перед выполнением, jsp страницы компилируются контейнером. После компиляции директивы вида:

<@include file="reuse.html">

при дезассемблировании, получим:

out.write("<html>\r\n");
out.write("    <head>\r\n");
out.write("        <title>reusable</title>\r\n");
out.write("        <meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\r\n");
out.write("    </head>\r\n");
out.write("    <body>\r\n");
out.write("        <img src=\"candle.gif\" height=\"100\" width=\"50\"/> <br />\r\n");
out.write("        <p><b>As the candle burns,so do I</b></p>\r\n");
out.write("    </body>\r\n");
out.write("</html>\r\n");

Читать

Демо для Sega MegaDrive

В прошедшие выходные на демопати EVOKE 2013 была выпущена лучшая в истории Sega демонстрация под эту платформу. Реакция в сообществе настолько бурная, что даже если вы слышали о демосцене лишь краем уха — стоит посмотреть!


Overdrive by Titan — Sega MegaDrive demo

По ссылкам на Pouet вы можете дополнительно проникнутся атмосферой показа через две live-записи — оцените реакцию зала! Сама работа наполнена огромным числом референсов к классическим demo на Amiga, PC и C64.

В основе архитектуры Sega MegaDrive лежат два классических процессора: Motorola 68000 (16bit, 7.61 МГц) и Zilog Z80 (8bit, 3.55 МГц). Последний почти ничем не помогает в конкретном демо, так как используется в режиме совместимости с Master System. Основное ОЗУ консоли — 64 кб.

Всем Сега, пацаны!

Собственно, этим я и собираюсь заниматься

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