Re: libtoolize docs
On Thu, 2005-11-17 at 22:58 +0100, Ralf Wildenhues wrote: > Hi Ross, > > * Ross Boylan wrote on Thu, Nov 17, 2005 at 10:44:03PM CET: > > On Thu, 2005-11-17 at 09:02 +0100, Ralf Wildenhues wrote: > > > * Mike Frysinger wrote on Wed, Nov 16, 2005 at 10:07:16PM CET: > > > > On Wed, Nov 16, 2005 at 12:50:58PM -0800, Ross Boylan wrote: > > > > > Does libtoolize have its own info files? So far, all I've seen is the > > > > > relatively brief description of the man page and libtool's info pages. > > > > > > > > nope ... it does have its own subsection in the libtool info files > > > > though > > > > > > Right. And > > > info libtoolize > > > should get you right to the correct section of those info files. If it > > > doesn't, please state installed Libtool version, its $prefix, $INFOPATH, > > > and whether there exists an updated `dir' file in $prefix/share/info, > > > alongside with libtool.info. > > > > > info libtoolize gets me the man page, which says it was written > > specifically for Debian. This is almost identical to the page on > > libtoolize in the libtool info pages. > > libtool 1.5.20-2 > > > > libtool --config doesn't give me $prefix or $INFOPATH. > > Ah, sorry, I was being too short-worded. > If `which libtoolize` is /usr/bin/libtoolize, then $prefix is /usr. > On the other hand, INFOPATH is an environment variable that changes > the behavior of the 'info' program. You can tell it where to look > for info pages, much as with manpages and MANPATH. I'm not sure if this matters, but prefix is /usr/bin. INFOPATH is empty, but clearly the info file is in the standard place for such things. > > > I do have > > /usr/share/info/libtool.info.gz. However, it is not part of the libtool > > package, and I suspect I put it there myself. > > libtool-doc maybe? Yes. Sorry, I was so sure the info file wasn't in a package that I didn't do a reverse check. > > > I suspect things are reasonable, given the production of local > > documentation on Debian and the fact that Debian tends not to ship info > > files because of licensing issues. > > Yes, I only now (on Debian) noted this myself. You can still get it > with > info libtool 'Invoking libtoolize' Yes, that works here too. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtoolize docs
Hi Ross, * Ross Boylan wrote on Thu, Nov 17, 2005 at 10:44:03PM CET: > On Thu, 2005-11-17 at 09:02 +0100, Ralf Wildenhues wrote: > > * Mike Frysinger wrote on Wed, Nov 16, 2005 at 10:07:16PM CET: > > > On Wed, Nov 16, 2005 at 12:50:58PM -0800, Ross Boylan wrote: > > > > Does libtoolize have its own info files? So far, all I've seen is the > > > > relatively brief description of the man page and libtool's info pages. > > > > > > nope ... it does have its own subsection in the libtool info files though > > > > Right. And > > info libtoolize > > should get you right to the correct section of those info files. If it > > doesn't, please state installed Libtool version, its $prefix, $INFOPATH, > > and whether there exists an updated `dir' file in $prefix/share/info, > > alongside with libtool.info. > > > info libtoolize gets me the man page, which says it was written > specifically for Debian. This is almost identical to the page on > libtoolize in the libtool info pages. > libtool 1.5.20-2 > > libtool --config doesn't give me $prefix or $INFOPATH. Ah, sorry, I was being too short-worded. If `which libtoolize` is /usr/bin/libtoolize, then $prefix is /usr. On the other hand, INFOPATH is an environment variable that changes the behavior of the 'info' program. You can tell it where to look for info pages, much as with manpages and MANPATH. > I do have > /usr/share/info/libtool.info.gz. However, it is not part of the libtool > package, and I suspect I put it there myself. libtool-doc maybe? > I suspect things are reasonable, given the production of local > documentation on Debian and the fact that Debian tends not to ship info > files because of licensing issues. Yes, I only now (on Debian) noted this myself. You can still get it with info libtool 'Invoking libtoolize' By the way, apologies for not having incorporated your months-old documentation patches yet. I really plan to tackle some outstanding doc patches when we've managed to do the 2.0 alpha release.. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtoolize docs
On Thu, 2005-11-17 at 09:02 +0100, Ralf Wildenhues wrote: > Hi Ross, Mike, > > * Mike Frysinger wrote on Wed, Nov 16, 2005 at 10:07:16PM CET: > > On Wed, Nov 16, 2005 at 12:50:58PM -0800, Ross Boylan wrote: > > > Does libtoolize have its own info files? So far, all I've seen is the > > > relatively brief description of the man page and libtool's info pages. > > > > nope ... it does have its own subsection in the libtool info files though > > Right. And > info libtoolize > should get you right to the correct section of those info files. If it > doesn't, please state installed Libtool version, its $prefix, $INFOPATH, > and whether there exists an updated `dir' file in $prefix/share/info, > alongside with libtool.info. > info libtoolize gets me the man page, which says it was written specifically for Debian. This is almost identical to the page on libtoolize in the libtool info pages. libtool 1.5.20-2 libtool --config doesn't give me $prefix or $INFOPATH. I do have /usr/share/info/libtool.info.gz. However, it is not part of the libtool package, and I suspect I put it there myself. I suspect things are reasonable, given the production of local documentation on Debian and the fact that Debian tends not to ship info files because of licensing issues. > Cheers, > Ralf > > > ___ > http://lists.gnu.org/mailman/listinfo/libtool -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 [EMAIL PROTECTED] Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool-1.5.20 -- lt_dlopenext fails to open preloaded module
Hi Peter,
* Peter Breitenlohner wrote on Wed, Nov 16, 2005 at 03:17:00PM CET:
>
> (I) First I have to correct a statement I made earlier.
>
> lt_dlopenext("module"), "module" without ".la" or ".a", DOES succeed to
> locate preloaded static modules, PROVIDED either LD_LIBRARY_PATH points
> to the location of the .la file or lt_dlsetsearchpath() is used with a
> suitable argument.
Yes.
> Yes, there are installed and uninstalled .la files.
> My problem was that in such a situation there is no wrapper script for the
> uninstalled executable and therefore LD_LIBRARY_PATH is not set
> automatically (as it would be for shared libraries/modules).
Ahh, ok.
> It might be useful to add some words about this problem to the libtool
> manual. Reading libtool.info I certainly didn't suspect that either
> LD_LIBRARY_PATH or lt_dlsetsearchpath() might be needed to locate modules
> statically linked into the program.
It might be even more useful to fix this bug! libltdl should not _need_
the .la file at all, neither the .a file.
We have an entry for this on our online TODO list:
http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap
If you feel adventurous to work on a fix, be our guest! ;-)
> (II)
>
> Meanwhile I had a look at the mdemo tests.
>
> (A) libtool/libltdl usage
>
> There are just a few minor and fairly trivial differences.
>
> (1) Out of desparation I added some debug output around lt_dlopen() and
> lt_dlopenext() in order to understand how they succeed or fail.
>
> (2) I use two "loadable" modules with analogous functions (*_LTX_get,
> *_LTX_set, *_LTX_str, and *_LTX_init).
>
> (3) I declare local instead of global variables and use functions (*_get and
> *_set) to access them.
>
> Actually I didn't think about the mdemo tests (and moreover didn't have them
> online on my notebook), otherwise I probably would have taken them as a
> starting point.
OK.
> (B) Layout of package, tests, and install-tests
>
> My demo package contains a program that (pretends that it) can not been
> tested until installed to the final location (without DESTDIR). Trying out
> mechanisms for such a situation (e.g., for perl modules as part of the
> package on non-linux/gnu systems) was actually the main motivation for doing
> all this.
Ah, good idea to do this.
> (III) A tarball demo-1.0.0.tar.bz2 is attached, for whatever it's worth.
> Please fell free to use as you like, except making it publically available.
I've not yet had a chance to take a detailed look, but might ask back
some time later. In case we find useful stuff, would you mind parts
ending up in a testsuite test?
Cheers,
Ralf
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Differnet config for root and non root user
* peto wrote on Thu, Nov 17, 2005 at 09:28:30PM CET: > Dňa Št 17. November 2005 19:46 Tim Rice napísal: > > > > [EMAIL PROTECTED] peto]$ libtool --version > > > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > > > [EMAIL PROTECTED] peto]$ libtool --config |more > Thank you, it works in confif but it does not realy produce shared libraries > yet. my local version in /usr/local was made from sources and MDK vesrion > works but not correctly (with freetype) You might want to try a newer version (1.5.20 is current). 1.4.3 is ancient. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Differnet config for root and non root user
On Thu, 17 Nov 2005, peto wrote: > D??a ??t 17. November 2005 19:46 Tim Rice nap??sal: > > > > [EMAIL PROTECTED] peto]$ libtool --version > > > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > > > [EMAIL PROTECTED] peto]$ libtool --config |more > > > > > > # Libtool was configured on host hp6.mandrakesoft.com: > > > > > > [snip] > > > > > [EMAIL PROTECTED] peto]$ su > > > Password: > > > [EMAIL PROTECTED] peto]# libtool --version > > > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > > > [EMAIL PROTECTED] peto]# libtool --config |more > > > > > > # Libtool was configured on host chello082119109251.chello.sk: > > > > You have 2 different versions of libtool on your system. > > When you "su" you get a different PATH. > > Remove the one you don't want or fix your PATH aftr you "su". > > Thank you, it works in confif but it does not realy produce shared libraries > yet. my local version in /usr/local was made from sources and MDK vesrion > works but not correctly (with freetype) Version 1.4.3 is a bit old. You might want to try 1.5.20. > > > Peter > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Differnet config for root and non root user
Dňa Št 17. November 2005 19:46 Tim Rice napísal: > > [EMAIL PROTECTED] peto]$ libtool --version > > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > > [EMAIL PROTECTED] peto]$ libtool --config |more > > > > # Libtool was configured on host hp6.mandrakesoft.com: > > > [snip] > > > [EMAIL PROTECTED] peto]$ su > > Password: > > [EMAIL PROTECTED] peto]# libtool --version > > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > > [EMAIL PROTECTED] peto]# libtool --config |more > > > > # Libtool was configured on host chello082119109251.chello.sk: > You have 2 different versions of libtool on your system. > When you "su" you get a different PATH. > Remove the one you don't want or fix your PATH aftr you "su". Thank you, it works in confif but it does not realy produce shared libraries yet. my local version in /usr/local was made from sources and MDK vesrion works but not correctly (with freetype) Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Differnet config for root and non root user
On Thu, 17 Nov 2005, peto wrote: > Dear conference, > > During compilation of the OO.org 2.0 in Mandrake 9.0 I found that libtool > 1.4.3 shows > > [EMAIL PROTECTED] peto]$ libtool --version > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > [EMAIL PROTECTED] peto]$ libtool --config |more > > # Libtool was configured on host hp6.mandrakesoft.com: [snip] > [EMAIL PROTECTED] peto]$ su > Password: > [EMAIL PROTECTED] peto]# libtool --version > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > [EMAIL PROTECTED] peto]# libtool --config |more > > # Libtool was configured on host chello082119109251.chello.sk: ^^^ [snip] > > Can anyone recomend me what to do to work libtool as root for shared > libraries > because OO.org 2.0 dmake(nmake) works only as root.,please.. You have 2 different versions of libtool on your system. When you "su" you get a different PATH. Remove the one you don't want or fix your PATH aftr you "su". > > > Thank you for any help as well as finding problem which can be also in path > I look forward hearing from you > > Yours faithfully > > Peter Fodrek > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Differnet config for root and non root user
Dear conference, During compilation of the OO.org 2.0 in Mandrake 9.0 I found that libtool 1.4.3 shows [EMAIL PROTECTED] peto]$ libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [EMAIL PROTECTED] peto]$ libtool --config |more # Libtool was configured on host hp6.mandrakesoft.com: # Shell to use when invoking shell scripts. SHELL="/bin/sh" # Whether or not to build shared libraries. build_libtool_libs=yes # Whether or not to build static libraries. build_old_libs=yes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=no # Whether or not to optimize for fast installation. fast_install=yes # The host system. host_alias=i586-mandrake-linux-gnu host=i586-mandrake-linux-gnu [EMAIL PROTECTED] peto]$ su Password: [EMAIL PROTECTED] peto]# libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [EMAIL PROTECTED] peto]# libtool --config |more # Libtool was configured on host chello082119109251.chello.sk: # Shell to use when invoking shell scripts. SHELL="/bin/sh" # Whether or not to build shared libraries. build_libtool_libs=no # Whether or not to build static libraries. build_old_libs=yes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=yes # Whether or not to optimize for fast installation. fast_install=needless # The host system. host_alias=i686-pc-linux-gnuoldld host=i686-pc-linux-gnuoldld [EMAIL PROTECTED] peto]# " Can anyone recomend me what to do to work libtool as root for shared libraries because OO.org 2.0 dmake(nmake) works only as root.,please.. Thank you for any help as well as finding problem which can be also in path I look forward hearing from you Yours faithfully Peter Fodrek ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: AIX5.x bug in libtool as generated by configure script used by courier-authlib-0.57)
Peter Yes, setting whole_archive_flag_spec='$convenience' fixes the bug. Best regards - Jorgen - Original Message - From: "Peter O'Gorman" <[EMAIL PROTECTED]> To: "Jørgen Moth" <[EMAIL PROTECTED]> Cc: "Libtool" ; "Allan Dukat" <[EMAIL PROTECTED]> Sent: Wednesday, November 16, 2005 1:56 PM Subject: Re: AIX5.x bug in libtool as generated by configure script used by courier-authlib-0.57) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jørgen Moth wrote: | Hi I was requested to forward the following description (and solution) of | an error in the libtool generating part of the configure script used by | the courier people. Please respond to [EMAIL PROTECTED] for any | further information. # Exported symbols can be pulled into shared objects | from archives > # original introduced error when linking | libcourierauth: whole_archive_flag_spec=' ' JM removed the single space Hi, Thanks for the report. It does seem like an error to me too. In branch-1-5 it is ' ', and in HEAD '$convenience', would seem like '$convenience' might be correct. Can you check, please, if setting whole_archive_flag_spec='$convenience' also fixes your bug? Thanks, Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQ3ssa7iDAg3OZTLPAQLMBAP/QnJxSDH42psacIXQTwCWSpOrf3YVnfmL +ABDma1a0LZAjJgOTw0NtGSFzG2uuv4biXzVlIuIlr1+CkOOaIsIdt9ZkgRZhtE4 BIwRFHjoztbroQYCihgA/sMJv4TEY07Pv1Ms/vjzuTQg/cXT6zLySf8eqWjcS3q7 vsqlfp8319w= =HZin -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtoolize docs
Hi Ross, Mike, * Mike Frysinger wrote on Wed, Nov 16, 2005 at 10:07:16PM CET: > On Wed, Nov 16, 2005 at 12:50:58PM -0800, Ross Boylan wrote: > > Does libtoolize have its own info files? So far, all I've seen is the > > relatively brief description of the man page and libtool's info pages. > > nope ... it does have its own subsection in the libtool info files though Right. And info libtoolize should get you right to the correct section of those info files. If it doesn't, please state installed Libtool version, its $prefix, $INFOPATH, and whether there exists an updated `dir' file in $prefix/share/info, alongside with libtool.info. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: unable to infer tagged configuration
Hi Ross, Mike, * Mike Frysinger wrote on Wed, Nov 16, 2005 at 09:25:00PM CET: > On Wed, Nov 16, 2005 at 11:53:24AM -0800, Ross Boylan wrote: > > > > It's odd that CC is used for the C++ compiler. > > dont confuse internal 'CC' with having any particular meaning ... cause > it doesnt have any meaning other than 'this is the compiler for this tag > configuration' > > the C tag config usually has 'CC=gcc' while the CXX tag config usually > has 'CC=g++' Correct. Inside the libtool script, $CC is merely the name for the configured compiler. $LTCC is always a C compiler, OTOH. > > I see why g++-3.3 would be a problem, but I don't see why g++ works. > > g++-3.3 pissed libtool off because when it was scanning the tag configs, > it does a text match, sort of like '$tagCC == $userCC' ... in this case, > libtool ran > C tag config: CC=gcc userCC=g++-3.3 ... "$CC" == "$userCC" -> nope > CXX tag config: CC=g++ userCC=g++-3.3 ... "$CC" == "$userCC" -> nope > no more tags in libtool -> unable to infer tagged configuration Correct as well. libtool has no way of finding out the matching tag to use (i.e., compilation language settings) unless either --tag=... is given or the compiler matches the configured compiler exactly. Note unfortunately we can't make this any better easily: matching only the leading portion will fail for KCC (C++) KCC --c (C) and for users using their C++ compiler to compile C code. > if you're running ./libtool yourself in your Makefile, just make sure > to use '--tag CXX' when dealing with C++ sources and '--tag CC' when > dealing with C sources ... that should handle all the funky compilers a > user at your package Correct as well. The only thing I should add, to avoid your next confusion: libtool will use the *configured* compiler when linking, not the one you give on the command line. Again, if you need that any differently, please reconfigure. You may think: why can't it regocnize that I gave a different compiler on the command line? Well, that is nontrivial to recognize. Think of CC='compile cc' (automake wrapper script) CC='distcc cc' etc. Also, in several cases libtool chooses different rules for linking based upon the compiler with which it was configured. This is necessary in some cases; so it would not be dangerous to change the compiler there. Hope this helps a bit. :) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
