Re: DESTDIR trouble
On Sat, Jul 05, 2003 at 02:09:40PM -0400, Charles Wilson wrote: > Bernd Jendrissek wrote: > > I realise this may be an FAQ candidate, but I haven't gotten any joy out > > of google or the mail.gnu.org archives. > > > > My problem: > > > > I have, say, guile 1.4 installed, with libguile.so.9 in /usr/lib. Now > > I've tried to build guile 1.6.4 with a DESTDIR=foo install, but then > > things get linked with the guile libs *in /usr/lib*! (I think most of > > you should be familiar with the scenario.) So I have new libraries linked > > to the old ones. > > > > I have libtool 1.5 installed, and it *doesn't* work properly with DESTDIR. > > I've seen DESTDIR-related messages in the archives, but they always seem > > to wind down with "this is fixed in 1.5" or something to that effect. > > > Did you see this message? It details what IS and is NOT fixed in 1.5. > with regards to DESTDIR. > > http://mail.gnu.org/archive/html/libtool/2003-05/msg00026.html I had seen it a while back, but I was wondering if it had been "silently" fixed in an as-yet unreleased libtool. > Other than identifying the problem, I don't really know how to correct > the remaining issue. But in this message > > http://mail.gnu.org/archive/html/libtool/2003-05/msg00022.html > > I posted a test case that demonstrates the issue; if anybody can figure > out how to fix libtool, they can test their fix with this small testcase > rather than trying to build guile. :-) Great! (Except that I have to make /usr/lib/libone.so and /usr/lib/libtwo.so symlinks to the real libs, manually.) Hmm, it doesn't even help to export LIBRARY_PATH=/tmp/relinkdemo/usr/lib. I just have to wonder how Red Hat and Debian and all the other distros build their packages. Okay, here's an interesting bit in ltmain.sh: 2631 if test "$linkmode,$pass" != "prog,link"; then 2632 vars="deplibs" 2633 else 2634 vars="compile_deplibs finalize_deplibs" 2635 fi 2636 for var in $vars dependency_libs; do 2637 # Add libraries to $var in reverse order 2638 eval tmp_libs=\"\$$var\" 2639 new_libs= 2640 for deplib in $tmp_libs; do 2641 # FIXME: Pedantically, this is the right thing to do, so 2642 #that some nasty dependency loop isn't accidentally 2643 #broken: 2644 #new_libs="$deplib $new_libs" 2645 # Pragmatically, this seems to cause very few problems in 2646 # practice: 2647 case $deplib in 2648 -L*) new_libs="$deplib $new_libs" ;; Anyway, if I apply this micro patch in destdir-relinklib-demo-1.0.1: diff -u ./libtool.borig ./libtool --- ./libtool.borig Mon Jul 7 09:14:04 2003 +++ ./libtool Mon Jul 7 11:02:59 2003 @@ -2985,7 +2985,7 @@ # Pragmatically, this seems to cause very few problems in # practice: case $deplib in - -L*) new_libs="$deplib $new_libs" ;; + -L*) new_libs="$new_libs $deplib" ;; -R*) ;; *) # And here is the reason: when a library appears more @@ -3003,11 +3003,11 @@ # using -Wl,-lname, so that libtool does not consider it # for duplicate removal. case " $specialdeplibs " in - *" $deplib "*) new_libs="$deplib $new_libs" ;; + *" $deplib "*) new_libs="$new_libs $deplib" ;; *) case " $new_libs " in *" $deplib "*) ;; - *) new_libs="$deplib $new_libs" ;; + *) new_libs="$new_libs $deplib" ;; esac ;; esac I get this: /tmp/destdir-relinklib-demo-1.0.1: LD_LIBRARY_PATH=/tmp/relinkdemo/usr/lib ldd /tmp/relinkdemo/usr/lib/libtwo.so.1.1.1 libone.so.2 => /tmp/relinkdemo/usr/lib/libone.so.2 (0x40002000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40012000) libc.so.6 => /lib/libc.so.6 (0x4001a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) Is there any reason why I shouldn't just apply this patch to my libtool? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
yerli kaliteyi al, issizlik azalsin!
ÝÞSÝZ KALMAMAK ÝÇÝN ÝÞSÝZLERE ÝÞ SAÐLANMASI ÝÇÝN TÜRKÝYE'NÝN KAMPANYASI'NA KATIL! YERLÝ KALÝTEYÝ AL! yatýrýmlar çoðalsýn ÝÞSÝZLÝK AZALSIN! YABANCI MALI ALMA! ÝÞSÝZ KALMA! 1 milyon 200 bin iþyeri kapandý, 9 milyon meslek sahibi insanýmýz iþsiz kaldý! Bugün ülkemizde sanayide ve iþ hayatýnda -iþ bilmezlikten ya da kiþisel beceriksizlikten kaynaklanmayan- seri iflaslarla iþyerleri kapanýyor. Açýk iþletmeler ise sürekli küçülüyor, iþçi çýkarýyor. HER 6.500 DOLARA 1 ÝÞSÝZ! Tüketim mallarý ithalatýna giden her 6 bin 500 dolar, Türkiye'de 1 kiþiyi iþsiz býrakýyor. Son dört yýldaki 60 milyar dolarlýk ithalat yerine 9 milyon kiþiye iþ saðlayabilirdik! ÝÞSÝZLÝÐÝ KENDÝ ELLERÝNLE BÜYÜTME! Azalan yatýrým, çoðalan iþsizliktir. Kaliteli yerlisi varken, yabancýsýný tercih etmek, zaten kýt olan paranýn dýþarý gitmesine yol açmakta, yatýrýmlarý azaltmaktadýr. Bugün Türkiye'de pek çok ürün, dünya standartlarýnda üretilmektedir. Türkiye kaliteyi yakalamýþtýr! YERLÝ KALÝTEYÝ AL! Ýþçiye ücret, memura maaþ olsun! Okul olsun, yol olsun, hizmet olsun! Ýþsizlerimize iþ, bebelerimize aþ olsun! Kampanyanýn gerekçeleri ve destekleyenler listesi www.YABANCI-MAL-ALMIYORUM.com 'dadýr. (Bu ileti 6 milyon Türk Ýnternet kullanýcýsýna gönderildi; kampanya, 300.000 bin yerli üreticiye, sanayi ve ticaret odalarýna, odalara ve birliklere, dört iþçi konfederasyonuna, sendikalarýna, þubelerine, derneklere ve üniversitelere duyuruldu.) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
On 2003-07-06(Sun) 11:08:58 -0500, Bob Friesenhahn wrote: > There is a "catch-22" with this approach in that adding > -L$inst_prefix_dir to the front of the linker search path may cause > the wrong dependency libraries to be used, which is just as bad as > picking up the wrong target library. The approach is reasonably safe > for a DESTDIR install since one may assume that the existing libraries > in $inst_prefix_dir are related to the current build, but is dangerous > for a normal user install. Hi bob, I would disagree quite _strongly_ for this, since DESTDIR install is not expected to be used for normal user install; if user wants to install stuff into some private area (say under $HOME), they would use configure --prefix=/some/other/path, and install software into other paths directly, without staging install. Isn't staging install intended for packaging only? For several _YEARS_, packagers for software were very troubled because of not-completely-working staging install. I really hope this issue can be sorted out, once and for all. Abel > Although special tweaks may be applied for a DESTDIR install, the > library paths should be as the user specified for a normal install. > > Bob > == > Bob Friesenhahn > [EMAIL PROTECTED] > http://www.simplesystems.org/users/bfriesen > -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
On 2003-07-06(Sun) 11:08:58 -0500, Bob Friesenhahn wrote: > There is a "catch-22" with this approach in that adding > -L$inst_prefix_dir to the front of the linker search path may cause > the wrong dependency libraries to be used, which is just as bad as > picking up the wrong target library. The approach is reasonably safe > for a DESTDIR install since one may assume that the existing libraries > in $inst_prefix_dir are related to the current build, but is dangerous > for a normal user install. Let me illustrate more: For normal user install, my patch has no effect -- since $inst_prefix_dir is never used in normal install, no prepending of staging library path is done during library relinking. For staging install, the staging lib path is always prepended to the whole list of libraries and lib paths, thus picking up the correct libraries. Abel > > Although special tweaks may be applied for a DESTDIR install, the > library paths should be as the user specified for a normal install. > > Bob > == > Bob Friesenhahn > [EMAIL PROTECTED] > http://www.simplesystems.org/users/bfriesen > -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
>>> "R" == R I P Deaddog <[EMAIL PROTECTED]> writes: [...] R> For several _YEARS_, packagers for software were very troubled because R> of not-completely-working staging install. I really hope this issue can R> be sorted out, once and for all. One way to address the "once for all" part would be to write a test case. [...] -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
540 Modelos de Cartas Comerciais
As cartas comerciais, têm grande importância na administração de qualquer empreendimento, pois uma parte significativa das transações mundiais se realiza por esse meio. A carta é o instrumento que faz a conexão entre os negociantes. A ERC (Equipe de Redação Comercial) lança o "CD MODELOS DE CARTAS COMERCIAIS 2003", que sana suas dúvidas na elaboração de todos os tipos de cartas e documentos empresariais: agradecimentos, atestados e declarações, avisos, cartas de cobrança, cartas em inglês, comunicados, convites, contratos, propostas, empregos, solicitações e pedidos, telegramas, cartas por e-mail, etc. O CD contém mais de 540 modelos de Cartas Comerciais e inúmeras técnicas de Redação Comercial. Indicado para: secretárias em geral, gerências, Rh, executivos, estudantes, empresas de toda ordem, etc. O custo deste CD é ínfimo em relação ao que poderá gerar no aperfeiçoamento da comunicação de sua empresa. Acesse-nos para mais detalhes e pedido, em: http://www.cdcartascomerciais.cjb.net Ps: para não receber esta mensagem novamente acesse: http://www.removeremail.cjb.net ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Using libtool together with the ${ORIGIN} soname variable
I'm using libtool to create plugin libraries for a program I'm working on.
These plugins are named without the lib prefix, that's all fine and it works
great.
However, I need these plugins to be in the same directory as where the main
executable resides, and I cannot install them into one of the $blah/lib
paths or add the current path to LD_LIBRARY_PATH.
So I went searching for some way to get win32-like DLL behaviour (eg. first
doing a search for DLL's in the current directory), but then for Linux.
I've found how to get such functionality at the following page:
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-PathToEXE&forum=totd&id=-1
I can now use this ${ORIGIN} variable to load those plugins from the same
directory as where the main executable lives.
To my knowledge, this is only possible when building the software by hand,
though.. (or using a custom makefile, but that's not an option)
When I try to specify this soname using libtool (adding it to the LDFLAGS
primary, eg. -Wl,-soname -Wl,{ORIGIN}/mylibname.so) it gets overridden by
the libtool script, which also uses it to set the so name.
So my question is; is it possible to somehow put this {ORIGIN} variable in
there and make libtool use it?
Or perhaps some way to turn off this soname setting from libtool?
Thanks,
Richard
_
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
On 2003-07-07(Mon) 23:03:24 +0200, Alexandre Duret-Lutz wrote: > R> For several _YEARS_, packagers for software were very troubled because > R> of not-completely-working staging install. I really hope this issue can > R> be sorted out, once and for all. > > One way to address the "once for all" part would be to write a > test case. Does this mean that things are more likely to be corrected if test cases are added? Abel > > [...] > > -- > Alexandre Duret-Lutz -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
Alexandre Duret-Lutz wrote: R> For several _YEARS_, packagers for software were very troubled because R> of not-completely-working staging install. I really hope this issue can R> be sorted out, once and for all. One way to address the "once for all" part would be to write a test case. I don't think this ia test case that can be made part of the testsuite, unfortunately. The problem is, you ONLY see the problem if all of the following are true: 1) you have multiple dependent constructs in a single project -- e.g. a sharedlib and an executable that depends on it, or two sharedlibs where one depends on the other, etc. 2) you are doing a DESTDIR install 3) you have PREVIOUSLY done a "real" install -- so that the sharedlib on which the second construct depends already exists in the "final" destination. Then, relinking will pick up the pre-existing sharedlib in the "final" location, rather than the one in the DESTDIR. In order to make #3 true, you have to muck with things "outside" of the testsuite tree...which kinda violates the whole premise of self-contained testing. But, if anyone would like to give it a try, they are welcome to adapt any of the following standalone testcase if it is useful. http://mail.gnu.org/archive/html/libtool/2003-05/msg00022.html --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
On Tue, 8 Jul 2003, Abel Cheung wrote: > On 2003-07-07(Mon) 23:03:24 +0200, Alexandre Duret-Lutz wrote: > > R> For several _YEARS_, packagers for software were very troubled because > > R> of not-completely-working staging install. I really hope this issue can > > R> be sorted out, once and for all. > > > > One way to address the "once for all" part would be to write a > > test case. > > Does this mean that things are more likely to be corrected if test cases > are added? Yes, of course. Without minimal tests which exercize the necessary operations, the libtool maintainer is forced to assume that his changes are correct, or needs to test with a large variety of existing packages in order to ensure that the updates are correct prior to commit. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: DESTDIR trouble
Bernd Jendrissek wrote: I get this: /tmp/destdir-relinklib-demo-1.0.1: LD_LIBRARY_PATH=/tmp/relinkdemo/usr/lib ldd /tmp/relinkdemo/usr/lib/libtwo.so.1.1.1 libone.so.2 => /tmp/relinkdemo/usr/lib/libone.so.2 (0x40002000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40012000) libc.so.6 => /lib/libc.so.6 (0x4001a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) Is there any reason why I shouldn't just apply this patch to my libtool? Um, I think there is a reason -- I think that this patch could cause non-DESTDIR patches to pick up incorrect dependencies. We don't want to rob peter to pay paul, here. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
On 2003-07-07(Mon) 19:49:08 -0500, Bob Friesenhahn wrote: > > Does this mean that things are more likely to be corrected if test cases > > are added? > > Yes, of course. Without minimal tests which exercize the necessary > operations, the libtool maintainer is forced to assume that his > changes are correct, or needs to test with a large variety of existing > packages in order to ensure that the updates are correct prior to > commit. As Charles has explained, this one is not easy to write test cases, even though I can provide tens of real world examples how libtool failed to handle. I'm starting to looking into the tests, but don't know when I can finish it, while real world cases can readily be given. Abel > > Bob > == > Bob Friesenhahn > [EMAIL PROTECTED] > http://www.simplesystems.org/users/bfriesen > -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
On Mon, Jul 07, 2003 at 08:42:14PM -0400, Charles Wilson wrote: > Alexandre Duret-Lutz wrote: > > > > > R> For several _YEARS_, packagers for software were very troubled because > > R> of not-completely-working staging install. I really hope this issue can > > R> be sorted out, once and for all. > > > > One way to address the "once for all" part would be to write a > > test case. > > I don't think this ia test case that can be made part of the testsuite, > unfortunately. > > The problem is, you ONLY see the problem if all of the following are true: > > 1) you have multiple dependent constructs in a single project -- e.g. a > sharedlib and an executable that depends on it, or two sharedlibs where > one depends on the other, etc. > > 2) you are doing a DESTDIR install > > 3) you have PREVIOUSLY done a "real" install -- so that the sharedlib on > which the second construct depends already exists in the "final" > destination. > > Then, relinking will pick up the pre-existing sharedlib in the "final" > location, rather than the one in the DESTDIR. > > In order to make #3 true, you have to muck with things "outside" of the > testsuite tree...which kinda violates the whole premise of > self-contained testing. I imagine the testsuite could demand that destdir-relink-demo's libone and libtwo are already installed. If not, the test case just exits with code 77 - the test can't run. AC_CHECK_LIB(one, one_set_global_int_var, [true], [exit 77]) > But, if anyone would like to give it a try, they are welcome to adapt > any of the following standalone testcase if it is useful. > http://mail.gnu.org/archive/html/libtool/2003-05/msg00022.html ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
