From: Alexey Morozov <alex-altlinux@idisys.iae.nsk.su> To: ALT Linux Sisyphus mailing list <sisyphus@altlinux.ru> Subject: Re: [sisyphus] Возвращаясь к напечатанному (про .la) Date: Thu, 11 Dec 2003 21:19:51 +0600 Message-ID: <20031211151951.GO14643@pyro.hopawar.private.net> (raw) In-Reply-To: <20031211143042.GA9387@basalt.office.altlinux.org> [-- Attachment #1: Type: text/plain, Size: 4504 bytes --] On Thu, Dec 11, 2003 at 05:30:42PM +0300, Dmitry V. Levin wrote: > > Вот этого, честно говоря, не понял. Точнее, понятно, что такую проверку > > _корректнее_ проводить в числе остальных прочих проверок способностей > > линкера/платформы, но это совсем не _обязательно_. > Как провести инициализацию link_all_deplibs=no в ltmain.sh (а не а > libtool.m4) таким образом, чтобы патч взяли в upstream? На самом деле, там все сложнее. Этот самый link_all_deplibs играет не основную роль (из-за чего, собственно, и патчить приходится). Поэтому дело скорее не в инициализации, а в неиспользовании этого параметра должным образом (скорее всего, в силу ущербности/ошибочности реализации логики) Я трейсил все это дело, в решающий момент (то есть, в этой самой проверке, после которой Ваш патч уводит на else continue), $link_all_deplibs оказывается равным no, причем, даже в случае -static что, впрочем, не мешает libtool'у все равно зацепить $dependency_libs. > > Вообще, мне кажется, в данном случае, слона лучше есть по кусочкам. > > То есть, пропихнуть (дополненный проверкой архитектуры) патч в libtool, > В libtool-1.5-alt-link_all_deplibs.patch с проверкой архитектуры всё > вроде бы нормально. Вероятно, за исключением того, что Вы делаете ее в libtool.m4, что автоматически приводит к необходимости aclocal/autoconf > > в принципе, представляется задачей реальной. > Да, представляется. Продвижение правильных патчей в upstream занимает у > меня время, сравнимое с их изготовлением. :-) Дорогу осилит, и все такое прочее :-). > > > Установить принудительный > > libtoolize --force тоже реально (проблемы могут быть только у > > действительно проблемных пакетов, но эти проблемы, _вероятнее всего_, можно > > продемонстрировать автору безотносительно данной темы), корректно > > написанные программы такую операцию точно переживут (обязаны) > Вашими бы словами... Нет, на самом деле. Мы же исходим из того, что люди вменяемы, правда? :-) > > > На втором этапе, когда патч в libtool _уже_ будет, можно будет > > разговаривать с autoconf'овыми господами на предмет: а не включить ли > > нам такую замечательную фичу, чтобы-де не руками или автоугадавом, а > > "правильно", в числе остальных ./configure'нных проверок способностей > > линкера? > А при чём тут autoconf'овые господа? Разве проверка способностей линкера - это, в конечном итоге, не их вотчина? > > > Я точно знаю, что не все пакеты-пользователи libtool переживут > > > libtoolize --force (что необходимо даже в случае хака в виде патча на > > Я предлагаю составить и огласить их список. Если делать эту операцию > > итеративно, то возни будет явно меньше, чем с вычищением .la отовсюду. > Думаю что больше. Она будет, она будет каждый раз немного другая, но она не потребует моментального пересбора всего и вся. > > > ltmain.sh), а тех, кто выдержит ещё и aclocal с autoconf, будет ещё > > > меньше. > > А вот с этим, видимо, лучше обождать. > Тогда см. вопрос #2. Ну, мне кажется, здесь нет проблемы, если [на первом этапе] проверкой возможностей линкера занимается код, включенный в ltmain.sh. > > > Надо? Нет, правда, если это надо, и если это избавит меня от необходимости > > перебирать те пакеты, для которых мне актуальна статическая линковка - > > я его сделаю. Миграция на другую платформу для девелопмента пока выглядит > > более затратным решением. > У меня нет ответа на этот вопрос. Нет, реально есть приложения, которым вынь да полож libtool-1.4? > За что вы так любите статические библиотеки? :) Мы не любим. Но нам приходится собирать статические (ужас! ужас! _полностью_ статические) приложения, без каких-либо внешних зависимостей. Типа, желание кастомера - закон, и все такое прочее. Но, возвращаясь к нашим баранам: в дополнение к существующей правке на ltmain.sh предлагается также включить туда (в ltmain.sh) код по проверке архитектуры/линкера, и выявить тех, кто не переживет libtoolize --force. Последнее достигается следующими мерами 1. Временным исправлением макроса %configure так, чтобы libtoolize --force запускался вне зависимости от неопределенного __libtoolize 2. Батч-пересборкой _программ_, использующих макрос %configure, с определением, кого расплющило 3. Батч-пересборкой программ, которые напрямую используют ./configure. С этими придется помучаться, но, думаю, счастье возможно, нужно только подумать, как именно сделать. Впрочем, специальную пересборку можно и не проводить, пустив все на самотек: когда понадобится, тогда и пересоберется. Или сломается, тогда и глядеть на него. План? [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-12-11 15:19 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-12-10 16:04 Alexey Morozov 2003-12-10 16:16 ` Dmitry V. Levin 2003-12-10 17:04 ` Sergey S. Skulachenko 2003-12-10 21:20 ` Alexey Morozov 2003-12-11 6:54 ` Sergey S. Skulachenko 2003-12-11 9:22 ` Alexey Morozov 2003-12-11 10:28 ` Alexey Morozov 2003-12-11 12:02 ` Dmitry V. Levin 2003-12-11 13:51 ` Alexey Morozov 2003-12-11 14:30 ` Dmitry V. Levin 2003-12-11 15:19 ` Alexey Morozov [this message] 2003-12-12 14:19 ` [sisyphus] " Alexey Tourbin 2003-12-13 10:19 ` [sisyphus] [JT] " Alexey Morozov 2003-12-15 13:59 ` [sisyphus] " Dmitry V. Levin 2003-12-16 12:16 ` [sisyphus] Обнаружены новые враги народа! (was: Возвращаясь ...) Alexey Morozov 2003-12-16 12:50 ` Dmitry V. Levin 2003-12-16 13:23 ` Alexey Morozov 2003-12-16 13:40 ` Dmitry V. Levin 2003-12-16 14:20 ` Alexey Morozov 2003-12-16 15:59 ` [sisyphus] " Michael Shigorin 2003-12-16 14:27 ` [sisyphus] " Serge Pavlovsky 2003-12-16 14:36 ` Alexey Morozov 2003-12-12 14:57 ` [sisyphus] Возвращаясь к напечатаннонапечатанному (про .la) Serge Pavlovsky 2003-12-12 15:38 ` [sisyphus] " Alexey Tourbin 2003-12-12 16:13 ` [sisyphus] Re: Возвращаясь к напечатаннонапечатаннонапечатанному " Serge Pavlovsky 2003-12-12 16:41 ` [sisyphus][JT] напечатаннонапечатаннонапечатанному Andrey Rahmatullin 2003-12-16 10:02 ` [sisyphus] Re: Возвращаясь к напечатанному (про .la) Michael Shigorin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20031211151951.GO14643@pyro.hopawar.private.net \ --to=alex-altlinux@idisys.iae.nsk.su \ --cc=sisyphus@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Sisyphus discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/sisyphus/0 sisyphus/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 sisyphus sisyphus/ http://lore.altlinux.org/sisyphus \ sisyphus@altlinux.ru sisyphus@altlinux.org sisyphus@lists.altlinux.org sisyphus@lists.altlinux.ru sisyphus@lists.altlinux.com sisyphus@linuxteam.iplabs.ru sisyphus@list.linux-os.ru public-inbox-index sisyphus Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.sisyphus AGPL code for this site: git clone https://public-inbox.org/public-inbox.git