Да, ошибка (вероятно )связана с библиотеками. Я подозреваю, что поскольку вы дали configure
префикс /usr/local/apache2
, библиотеки, созданные для httpd
, оказались в /usr/local/apache2/lib
, о чем динамический компоновщик не знает.
Есть несколько способов исправить это:
Вместо этого используйте пакет , это облегчит вашу жизнь в долгосрочной перспективе:
sudo apt install apache2
или
Добавить /usr/local/apache2/lib
в конфигурацию динамического компоновщика; создайте файл /etc/ld.so.conf.d/apache2-local.conf
, содержащий одну строку
/usr/local/apache2/lib
и запустите sudo ldconfig
.
или
httpd
с префиксом /usr/local
, чтобы его двоичные файлы оказались в /usr/local/bin
, а его библиотеки — в /usr/local/lib
. (Кстати, запускать configure
от имени root не нужно, да и не следует — настраивать и собирать под обычным пользователем, а устанавливать только под root.)
Хорошо, кажется, я нашел ответ. Я очень-очень удивлен, что такая простая и нужная ИМХО вещь решается так "нестандартно", но такова жизнь...:-)
В любом случае, спасибо telcoM
, который дал мне ссылки, которые ведут к ссылкам и еще ссылкам, и, наконец, позволил найти пакет ttyrpl
, который делает именно то, что я хотел.
Поддержка пакета прекратилась примерно 7 -10 лет назад, и мне потребовалось некоторое время, чтобы адаптировать его к моей версии Linux и необходимым библиотекам, но он работает!
Он делает именно то, что я хотел -собирает выходные данные ttyS0/ttyO0 и сохраняет их в файл. И имеет много навороченных опций, хотя мне они не нужны...:-)
Попробуйте использовать picocom вместо console=/dev/ttyS0. Есть и другие инструменты, но picocom кажется самым простым.
Если вы используете один из этих инструментов, вы можете использовать трубу и тройник на выходе.
picocom /dev/ttyS0 -b 115200 -l | tee my.log
Вы, кажется, упустили один довольно простой факт. Каждая конвейерная программа опирается на тот факт, что она получает три стандартных файловых дескриптора в предварительно -открытом состоянии из любой программы, которая ее вызывает. В большинстве случаев, связанных с конвейерами, вызывающей программой будет командная оболочка.
Эти три файловых дескриптора:
stdin
для краткости. stdout
для краткости. stderr
для краткости. Когда программа не передается по конвейеру или не перенаправляется для чтения/записи файла, все эти три файловых дескриптора обычно указывают на устройство TTY, на котором выполняется текущий сеанс входа в систему. Если программа преднамеренно запущена как демон или фоновый/не -интерактивный процесс, все они могут быть направлены в файл (s )или /dev/null
или, возможно, в какое-то средство ведения журнала.
Сообщения об ошибках обычно выводятся в поток stderr
именно для того, чтобы они не смешивались с, возможно, -выводом конвейерных данных. Но в таких случаях, как ваш, когда вы хотите захватить весь вывод, вам нужно явно указать системе захватывать оба потока.
Если вы хотите передать все выходные данные из вашего myapplication.sh
в канал, вам, возможно, придется сделать что-то вроде этого:
myapplication.sh 2>&1 | logger
2>&1
говорит: "перенаправить файловый дескриптор #2 в то же место, куда идет #1", и тогда вы можете передавать их оба одновременно.
Вы можете сами проверить это с помощью небольшого скрипта, подобного этому:
#!/bin/sh
echo "this is stdout"
echo "this is stderr" >&2
>&2
означает «взять стандартный вывод этой команды и вместо этого отправить его в стандартный поток ошибок».Вероятно, это самый простой способ генерировать вывод stderr
в скрипте.
Теперь, если вы запустите этот скрипт, например ./test.sh | od -t x1z
, чтобы получить его выходные данные в шестнадцатеричной -форме дампа, вы получите это:
$./test.sh | od -t x1z
this is stderr
0000000 74 68 69 73 20 69 73 20 73 74 64 6f 75 74 0a >this is stdout.<
0000017
Таким образом, только вывод stdout
обрабатывался командой od
.
Если вы добавите 2>&1
для объединения обоих потоков, вместо этого вы получите это:
$./test.sh 2>&1 | od -t x1z
0000000 74 68 69 73 20 69 73 20 73 74 64 6f 75 74 0a 74 >this is stdout.t<
0000020 68 69 73 20 69 73 20 73 74 64 65 72 72 0a >his is stderr.<
0000036
Теперь оба вывода были отправлены в конвейер, что и требуется в вашем случае с | logger
.
Ваша вторая командная строка захватывает все, что ваше встроенное устройство получает от терминальной программы, а не то, что встроенное устройство отправляет на терминал:
(stty raw; cat > received.txt) < /dev/ttyO0
Вы сказали, что работаете над встроенной системой, в которой используется параметр ядра console=/dev/ttyO0
, поэтому, по сути, /dev/console
будет последовательным портом, а не графическим дисплеем (, который может даже не существовать во встроенном устройстве ).
Если вы запускаете эту команду на встроенном устройстве, команды в круглых скобках будут выполняться с их стандартным входным потоком(файловым дескриптором #0 или stdin
для краткости ), назначенным для /dev/ttyO0
. Но если вы вводите эту команду через последовательную линию, подключенную к ttyO0
, это то, что, вероятно, будет по умолчанию, поэтому это перенаправление ввода может просто перенаправлять -ситуацию как есть.
Устройство /dev/ttyO0
является прямым представлением UART, подключенного к вашей терминальной программе на другом компьютере. Когда вы читаете из него, вы получаете только то, что вы вводите в программу терминала:нет возможности прочитать какой-либо вывод, который был ранее отправлен в него. И все, что в него записано, идет прямо в терминальную программу на конце последовательного кабеля.
Командная строка Unix на последовательном порту обычно работает по принципу удаленного эха :, чтобы видеть, что вы пишете в терминальной программе,Драйвер TTY во встроенной системе должен отправлять копию каждого символа, который вы набираете, обратно в терминальную программу. Это поведение не является симметричным :программа терминала также не будет отправлять обратно копию всего, что она получает через соединение через последовательный порт.
Драйвер TTY — сложная вещь, потому что наследие Unix требует, чтобы он был способен делать много вещей, -функция удаленного эха — лишь одна из них.
Когда вы используете stty raw
, вы фактически отключаете все обычно -полезные функции драйвера TTY , включая функцию удаленного эха. Таким образом, с этого момента и далее, если что-то явно не читает из /dev/ttyS0
и не записывает его обратно прямо в него, вы не увидите, что вы пишете в терминальной программе.
После выхода из команды stty raw
любой ввод из терминальной программы будет передан команде cat
, которая просто передаст его в свой стандартный вывод, как -при вызове без параметров. Но его стандартный вывод теперь перенаправлен в файл received.txt
. Итак, что происходит, так это то, что только то, что вы печатаете в терминальной программе, записывается в файл до тех пор, пока команда cat
не завершится -, и это закончится только тогда, когда она получит конец -из -символ файла (обычно Control+D).
(Из-за того, что оболочка может выполнять буферизацию, выполняющую перенаправление, вывод в файл received.txt
может отсутствовать, если вы не завершите ввод символом конца -из -файла и/или не наберете более одной строки текста.)
Таким образом, кроме отключения функций драйвера TTY, (stty raw; cat > received.txt) < /dev/ttyO0
во встроенной системе вообще ничего не делает для захвата любого вывода , который записывается в /dev/ttyO0
.Эта команда может использоваться только при устранении неполадок с подключением к последовательному порту :. терминальная программа отправляет на встроенное устройство в самой необработанной форме.
Если вы хотите записывать абсолютно все , что происходит по соединению UART, включая, например,. сообщения о панике ядра, то лучший способ сделать это, вероятно, будет состоять в том, чтобы указать вашей терминальной программе на другом компьютере регистрировать весь трафик. Многие терминальные программы имеют встроенную -эту функцию.
Это связано с тем, что если что-то пойдет не так с ядром, запись чего-либо в файл на диске может оказаться невозможной. Гораздо проще просто отправить текст сообщения об ошибке из UART и быть уверенным, что тот, кто его получит, поймает его.