On Fri, Jan 09, 2004 at 03:46:19PM +0600, Alexey Morozov wrote: > On Thu, Jan 08, 2004 at 11:14:57PM +0300, Dmitry V. Levin wrote: > > Что нам даёт удаление всех .la-файлов к разделяемым библиотекам, помимо > > решения основной задачи (недопущение превращения косвенных зависимостей > > в прямые)? Гарантию того, что эти самые косвенные зависимости через > > .la-файлы не попадут в собираемые программы и библиотеки. > Ну, нынаю... Автотест работает, могу свои тесты формализовать и добавить > к стандартным libtool'овским, что еще проверять, чес-гря, не знаю. > Мои тесты, напомню, показали (на depdemo/), что gcc на линковке получает > все те библиотеки, которые потребны ему для данного вида сборки > (то есть, в динамической сборке libl3 НЕ передается, а в статической - > передается). > > Если предложите "плохую" ситуацию, которую надо промоделировать, эту > проверку тоже можно будет отправить в libtool'овые тесты. Если найду, то конечно предложу. > > Тот способ, который вы предлагаете, не даёт такой твёрдой гарантии > > просто потому, что надо в каждом конкретном случае убеждаться, что > > способ применён правильно. > Думаю, нет. libtoolize --copy --force позволяет, с одной стороны, > заменить "неправильные" ltmain.sh на "правильные", а с другой > рубит тех, кто пришел с libtool-1.4 в потрохах. > > aclocal -I `aclocal ...` -I m4 > > позволяет обойти и тех последних. В общем, думаю, в нынешней ситуации > все равно приходится разбираться некоторыми пакетами, причем, с теми, > кто _делает все правильно_. Нет, не приходится. Как правило, достаточно слепой пересборки. > В моём способе разбираться приходится с теми, кто делает что-либо > неправильно. По-моему, альтернатива более здравая. Я, если пороюсь > в здешних архивах, накопаю Ваше письмо о том, что Вы готовы бороться > за правильные решения :-)). Конечно. Не знаю, правда, как отнесутся maintainer'ы на (вообще говоря, правильное) предложение всегда использовать "libtoolize --force". Не знаю, насколько это пройдёт гладко. Поэтому и уверенности нет. > > Чего хочется добиться? Решения этой задачи с лишними зависимостями > > (которые, как мы знаем, могут порождать жуткие проблемы в runtime), не > > вдаваясь в особенности устройства кривизны каждого пакета в Сизифе. > Нет, это неполная постановка задачи. Требуется детализация. В Сизифе очень много кривых пакетов, в которых никому, кроме разве что их maintainer'ов, копаться не хочется. Нужен способ по возможности избежать перелопачивания этого множества кривых пакетов, ибо это может оказаться неподъёмной задачей на данном этапе. > > Как при этом сохранить возможность линковать статические приложения? > > Запаковывать по одному .la-файлу в пакет тоже ведь не очень хочется. > Я предложил бы паковать все. Как раньше, или как-то иначе? > > Я предположил, что их можно просто восстанавливать скриптом при > > необходимости по уже установленным разделяемым библиотекам. > В какой момент? Теоретически, конечно, такая возможность есть, но, > по-моему, это странно: сначала откзываться от какой-либо информации, > потом ее вытаскивать по каким-либо "внешним" факторам. К тому же, > я не уверен, что если в зависимости для _динамических_ библиотек > попадет какая-либо чисто статическая (ну, вообщем-то, такое устроить > можно запросто), то мы не потеряем в этом месте информацию безвозвратно. Неужели такое встречается в реальной практике? -- ldv