Alexei Babich

.

Может, гимор в другом, у меня так было. Короче, когда запускается configure, она начинает проверять всё, что нужно для сборки по шагам. И на определённом шаге не работает препроцессор. У меня он сломался (рукотворно) после того, как я грохнул папки /usr/include/asm /usr/include/linux, в которых находятся некоторые заголовки ядра. Проверь, всё ли хорошо. И вообще, просто напиши программку на С из трёх строчек и попробуй её скомпилировать, так как в configure чёрт ногу сломит. И логи у неё косые.

А пробуй все sd*. Кстати, циферки в конце имени блочного устройства (разделы) не всегда надо использовать: у меня mp3 плеер (правда, корейский, так что не авторитет) работает без таблицы разделов, кажись. Причём, не знаю, полезно или нет это: выдергиваешь его и снова втыкаешь, он переезжает на следующее устройство (скажем, с sda на sdb и так далее). Ядро 2.4.25

Вот он, скрипт: #!/bin/sh cp /mnt/smb/Apocaliptica/From_Out_Of_Nowhere.mp3 ./temp.mp3 NAME='"gggg rrrr"' mp3tool write -a $NAME ./temp.mp3 И вот результат: Error opening file: rrrr Короче, в командной строке работает на "ура", так не пашет наотрез !!

Проблема тупая: есть программка, которая, как и все остальные, принимает аргументы из командной строки. Пример использования такой: $mp3tool write -a 'some_string' ./file.mp3 Эта утилка меняет метаданные в mp3 файле. Когда я так пишу, всё зашибись. Всё зашибись и тогда, когда в строке символов есть пробелы. Можно написать без кавычек, но тогда надо экранировать пробел, вот так: $mp3tool write -a some\ string ./file.mp3 Всё здорово до того момента, когда надо исполнять эту канитель в командном файле, фрагмент для примера: NAME='aaa bbb' mp3tool write -a $NAME ./file.mp3 И вот тут эта гадина начинает возбухать, что файл 'bbb' не найден. Типа, думает, что пробел отделяет опцию. Пробовал и с экранированием, и добавлением в саму переменную кавычек - один хрен не пашет. Обойти использование переменных нельзя, то есть, строка символов не статическая, меняется по мере развития событий. Есть дельные советы ? Если есть, то помогите, плиз. Кстати, проблема не в этой конкретно утилке - lame, например, тоже себя так-же ведёт. Спасибо

http://www.netams.com

binutils 2.15 Кстати, ещё: изначально дистрибутив, который подвергается экспериментам, был RedHat7.3 Он ставит пакет glibc-kernheaders, суть которого содержимое каталогов /usr/include/asm и /usr/include/linux. Я грохнул это дело после сборки компилятора и бинутилок, когда понял, что заголовки от ядра 2.4.18-3 лучше не использовать, когда работает ядро 2.4.25 После этого не захотел работать препроцессор. Я долго мудрить не стал и создал в /usr/include симлинки на соответствующие папки в исходниках ядра. Вроде как в доке на glibc такой путь в каком-то случае рекомендовался... Может, что-то невнимательно читал ?.. Препроцессор успокоился, но что-то сомнение всё равно одолевает.. Вроде как всё правильно...

Я бы с радостью, просто не хотел валить тонну всякого хлама в форум.. Итак, лог в прикреплённом файле. Спасибо всем, кто найдёт время его поглядеть и подумать, что за фигня такая. Кстати, пробовал распаковать glibc-2.2.5 из комплекта RedHat 7.3 и собрать: один хрен ошибка, но уже в другом месте и другая. Ну, блин, классно...

Да там полный терминал писанины. Я могу её сюда вставить, ты лучше скажи: собирал ? Получилось ? Или это в glibc глюк какой-то ???

Дома и на работе пробовал, везде одно и то-же, компилятор не ниже gcc3.3.1.. Какого рожна этой гадине надо ?... Конфигурирую так: ../glibc-2.3.3/configure \ --with-headers=/usr/src/linux-2.4.25/include/ \ --enable-add-ons=linuxthreads \ --prefix=/usr/src/_target Это проскакивает нормально, получается Makefile. Пишу make потом - очень скоро вылетает с ошибкой, много ошибок.. Начинается со строк: In file included from ../sysdeps/unix/sysv/linux/ldsodefs.h:25, from ../sysdeps/unix/sysv/linux/init-first.c:30: ..... И так далее. Кто нибудь вообще собирал эту версию на Линуксе ?

http://webcenter.ru/~intec/alexey/ man cosole_codes