Re: libtool 2 and dsohowto's comments?
* Gary V.Vaughan wrote on Sun, Sep 05, 2004 at 05:15:03PM CEST: > On 4 Sep 2004, at 21:51, Tero Niemela wrote: > > >>>http://people.redhat.com/drepper/dsohowto.pdf *snip* > >Section 2.2.6 is all about libtool and its > >-export-symbols option. It ends with: > > > >"The only reason this method is mentioned here is that > >there is hope libtool will learn about converting the > >export lists into the anonymous version maps we have > >seen in the previous section when the GNU linker is > >used. > >At that point libtool will become useful. Until then > >relying on its -export-symbols options is misleading > >at best." > > Ah, I see the paper has revved since I last downloaded (and grown > by 12 pages in size!). Yes, those comments are perfectly reasonable. But current Libtool does use -version-script on linux if ld supports it.. > The -export-symbols option isn't at all fully featured yet, and even > without taking Uli's comments into account needs some work post > libtool-2.0. ..so this comment about Libtool is not true (any more?). Sure there are many other interesting things mentioned in that article. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool release plans for the next few weeks
* Gary V. Vaughan wrote on Fri, Sep 17, 2004 at 09:12:04PM CEST: > Daniel Reed wrote: > > What is branch-1-5's current role? > > 1.5 is winding down its status as stable branch. > > > There have been patches checked in as > > of the 13th; will there be a 1.5.9 release? > > There are no concrete plans to make another release from branch-1-5 at the moment. > > > If so, can Ralf's patch (which corrects RH#55176) be applied to branch-1-5? > > If you point me at the thread in the mail archives, and it backports easily, > I'll apply it. Please don't forget the `random cruft' http://lists.gnu.org/archive/html/libtool-patches/2004-09/msg00125.html either. ;-> Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: compile problem
Alexandre Duret-Lutz writes: "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: Gary> But for a project built with `make -j', we still need AM_PROG_CC_C_O Gary> and _LT_COMPILER_C_O to understand each others' locks :-( Seems so. I thought it was not needed because when AM_PROG_CC_C_O decides `compile' is required, it is also used when compiling libtool objects. However perhaps I was wrong, because `compile' does something only for *.o and *.obj files, it is a no-op for *.lo files. This is one problem (one I even haven't noticed yet). Maybe we need to tell AM_PROG_CC_C_O about *.lo files. To makes matter worse, because AM_PROG_CC_C_O horribly overwrites CC, it's not clear to me whether AM_PROG_CC_C_O LT_INIT is equivalent to LT_INIT AM_PROG_CC_C_O It looks like Libtool's `-c -o' check would not give the same answer. I haven't dug all this; I think Ralf W sent some mail about it, but I haven't flushed all my mails yet. Note that my conclusions were partly wrong because of several reasons: - I tried with the wrong order of AC_PROG_CC and AM_PROG_CC_C_O (this is fortunately solved now) - My first tests were done overwriting config.cache variables in a non-safe manner: Whether Libtool's _C_O test succeeds or fails depends partly on whether AM_PROG_CC_C_O was run before (and with what output). More complicating: Right now the tests do not use the same method to check, which means (and yes, this actually happens!) that either one can fail or succeed, and you have to actually look at all the possibilities. I especially don't like the Libtool check because it greps for compiler warnings instead of checking for the right output file. Warnings could have very different cause. But another issue I did find out: While Automake makes sure that all automake'n Makefiles use `compile' in the case of a bad compiler, Libtool has no way of making sure all compilations of `foo.c' are employed using `libtool'. This makes it impossible for libtool to guard against # This is part of a non-Automake Makefile libfoo.la: foo.lo bar: foo.o I agree it would be better to set down a common lock scheme, although that really should not hold any release. In this case you *must* make sure that whenever Automake detects a bad compiler `C', Libtool detects `compile C' as a good compiler, in order to prevent deadlock. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Issues with dlopen and compile of modules...
* Chris Bowlby wrote on Thu, Oct 21, 2004 at 10:00:33PM CEST:
> Hi All,
>
> I've been working on a project for some time now and am working into the
> system a means of creating dynamic modules that will need to be loaded via
> dlopen (will use libltdl once I've got my initial testing done - for
> portability reasons), my sample code is as follows:
>
> #include
> #include
>
> #include
>
> void main(void) {
> void (*test_function) (int &);
See below.
> void *handle;
>
> handle = dlopen("libtest/libtest.la", RTLD_NOW);
This will not work. lt_dlopen can open .la files, dlopen can only open
the corresponding shared objects, most likely called libtest.so (or
similar with version numbers) on your system.
> if (!handle) {
>cerr << dlerror() << "\n";
This will not work in ISO C++.
using namespace std;
or similar will be necessary.
>exit(EXIT_FAILURE);
Better include stdlib.h (or, FWIW, cstdlib) for exit().
> }
>
> // test_function = dlsym(handle, "test_fun");
>
> dlclose(handle);
> }
>
> There are two issues that I've come up with, during compile time with the:
>
> test_function = dlsym(handle, "test_fun");
>
> uncommented it complains about:
>
> test.cxx: In function 'void main(void)':
> test.cxx:17: ANSI C++ forbids implicit conversion from 'void *' in
> assignment
This has nothing to do with libtool, and everything with C++ type
safety. You have to cast the return value of dlsym to the correct type.
> The second issue is that dlopen (when I get the system to compile the
> program by commenting out the dlsym line) complains that libtest/libtest.la
> is not of the right format, I'm compiling it using:
>
> lib_LTLIBRARIES: libtest.la
Typo: you want
lib_LTLIBRARIES = libtest.la
> libtest_la_SOURCES = test.cxx
> libtest_la_LDFLAGS = -module
The last and (to me) most interesting issue: apart from the fact that in
C, already conversion from void pointer to function pointer is
undefined, is there any ISO C++ reason against conversion to a C++
function pointer (like test_function above)? I don't think so, but I'm
not really sure.
Regards,
Ralf
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: gnu vs bsd make
* Patrick Welche wrote on Thu, Oct 28, 2004 at 06:29:27PM CEST: > I just came across a difference between between GNU make and BSD make: > *snip* > > In otherwords, we need $(var)/bar as the dependency for success > with bsd make. Why is this relevant to libtool? > > In bootstrap "make" is called 3 times, which might end up being a > non-GNU make and AFAIK we don't say "you must use gnu make" anywhere > - do we? AFAIK no. > If make = bsd make, then > > make: don't know how to make stamp-vcl. Stop > > which the attached trivial patch fixes. I haven't looked for other > instances.. Thanks for the report. I'm checking this in on branch-2-0 and HEAD, fixing also the instances you missed. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: pthreads in libtool'd shared library...
* Chris Bowlby wrote on Fri, Oct 29, 2004 at 06:59:16PM CEST: > Hi All, > > I've been building a standard library for an application that I'm working > on and noticed that once I started to attempt to work in threads the > linking stage seems to have dropped the link to libc_r.so, as shown in the > compiler details below: > > /bin/bash ../../../libtool --mode=link g++ -g -O2 -L/usr/local/lib > -L/usr/lib -L/usr/compat/linux/lib -o libtest.la -rpath > /usr/local/data_cop/lib -module -Wsymbolic test.lo -lc_r -lcrypt -lpq > -lcipher > g++ -shared -nostdlib /usr/lib/crti.o > /usr/lib/crtbeginS.o .libs/test.o -L/usr/local/lib -L/usr/lib > -L/usr/compat/linux/lib -lcrypt -lpq -lcipher -lstdc++ -lm -lgcc > /usr/lib/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,libtest.so.0 -o > .libs/libtest.so.0 *snip* > > If we look at the first part, the -lc_r is compiled into it, but once it > creates the libtest.so.0 file, it forgets that I need to have that there, > is there a parameter that I need to set somewhere in the configure.ac > script or Makefile.am file so that libtool picks up that I need the > pthreads library linked in? Try using -pthread instead of adding -lc_r directly (who adds it?). If that's not the right answer, then it's because I'm stabbing in the very dark -- you do not state neither the Libtool version you use nor any slight detail about the system this happens on, unfortunately. Not that I know whether I could help you then. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: pthreads in libtool'd shared library...
* Chris Bowlby wrote on Sun, Oct 31, 2004 at 02:42:51AM CET: > > Thanks for the help, but seemed to have no effect, I'm building this on a > FreeBSD 4.10-STABLE box, with libtool version 1.5.8. > I was not adding the -lc_r parameter itself, automake/configure did that > for me during the compile process. So far, each time I compile and try to > execute the command, I get the following error: > > ./test > /usr/local/test/lib/libtest.so: Undefined symbol "pthread_create" > *snip* > > So I can tell right off that the pthread library (in this case it should be: > /usr/lib/libc_r.so.4 > > It's got to be something I'm missing in the linkage process, the current > Makefile.am looks like: > > lib_LTLIBRARIES = libtest.la > > libtest_la_SOURCES = test.cxx > libtest_la_LDFLAGS = -module -Wsymbolic -pthread Try adding -no-undefined. Should fail at library link time then. Did you check that the `-pthread' option is really passed to the compiler? I don't have FreeBSD available to test (and no experience with it), but online docs suggest it to be sufficient. More random thoughts: try putting -pthread as very last thing on the libtool --mode=links -o libtest.la ... cmdline. Try the g++ link line (which libtool generates) by hand and try to see what's necessary to fix it. BTW, -Wsymbolic is not mentioned in the online docs. Is that the same as -Bsymbolic? > #libtest_la_LDFLAGS = -version-info > $(ABI_CURRENT):$(ABI_REVISION):$(ABI_AGE) No need to remove the version-info. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: pthreads in libtool'd shared library...
* Chris Bowlby wrote on Mon, Nov 01, 2004 at 05:37:33PM CET: > At 02:44 PM 10/31/2004, Ralf Wildenhues wrote: > > >Try adding -no-undefined. Should fail at library link time then. > > This had no effect on the compiler, it still managed to compile with out > issue. This seems to be a separate issue. I'm not looking at that now. > >Did you check that the `-pthread' option is really passed to the > >compiler? I don't have FreeBSD available to test (and no experience > >with it), but online docs suggest it to be sufficient. > > The -pthread parameter was being passed to the compiler: > > /bin/bash ../../../libtool --mode=link g++ -g -O2 -L/usr/local/lib > -L/usr/lib -L/usr/compat/linux/lib -o libtest.la -rpath > /usr/local/data_cop/lib -module -Wsymbolic -pthread -no-undefined > test.lo -lc_r -lcrypt -lpq -lcipher > g++ -shared -nostdlib /usr/lib/crti.o > /usr/lib/crtbeginS.o .libs/test.o -L/usr/local/lib -L/usr/lib > -L/usr/compat/linux/lib -pthread -lcrypt -lpq -lcipher -lstdc++ -lm -lgcc > /usr/lib/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,libtest.so.0 -o > .libs/libtest.so.0 *snip* > > >More random thoughts: try putting -pthread as very last thing on the > > libtool --mode=links -o libtest.la ... > >cmdline. Try the g++ link line (which libtool generates) by hand > >and try to see what's necessary to fix it. > > Changing the location of where -pthread was, did not help either. But, > having said that I added -lc_r to the list of parameters and it solved the > problem, but that only worked when I added it to the raw g++ command. > It still seems that libtool is auto-dropping the -lc_r (Which we can see in > the list of parameters to be added to the command line to g++) > preventing it from compiling properly. Even adding it to the LDFLAGS part > for the sake of testing, libtool stripped it out: Yes. I know it's doing this. There is a reason for this as well, I think, has to do with multiple instances of the same library being pulled in in some occasions. > /bin/bash ../../../libtool --mode=link g++ -g -O2 -L/usr/local/lib > -L/usr/lib -L/usr/compat/linux/lib -o libtest.la -rpath > /usr/local/data_cop/lib -module -Wsymbolic -pthread -no-undefined > test.lo -lc_r -lcrypt -lpq -lcipher > > This is the call libtool makes, as we can see -lc_r is part of the > parameter list here, but: > > g++ -shared -nostdlib /usr/lib/crti.o > /usr/lib/crtbeginS.o .libs/test.o -L/usr/local/lib -L/usr/lib > -L/usr/compat/linux/lib -pthread -lcrypt -lpq -lcipher -lstdc++ -lm -lgcc > /usr/lib/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,libtest.so.0 -o > .libs/libtest.so.0 > > g++ never actually sees it. ACK. > >BTW, -Wsymbolic is not mentioned in the online docs. Is that the same > >as -Bsymbolic? > > -B is a path related parameter, -W was mentioned on the dlopen related > pages so that when I link in my .so library, it already know's about > symbols in the executable, that might be global. This is only a temporary > solution until I can clean any of those ones out, and really just to help > me get the application written faster. Once I've got it written, I'll be > doing a code review that will clean that requirement out. Ok, I know a workaround: Add -pthread to the LDFLAGS for the executable you eventually create (either progname_LDFLAGS or AM_LDFLAGS in that directory). I'm attaching a test case for the other developers. This fails on Linux as well, is unfortunately not very portable yet (and would most probably need acx_pthread.m4 or some adaptation of that). Help is quite welcome, maybe someone wants to turn it into a testsuite test? I know too little about the problem to be able to suggest a solution. For a full solution I guess it's necessary to add more information in the .la file.. > >> #libtest_la_LDFLAGS = -version-info > >> $(ABI_CURRENT):$(ABI_REVISION):$(ABI_AGE) > >No need to remove the version-info. > > Actually, I got an error when trying to use this line: > libtool: link: CURRENT `' is not a nonnegative integer > libtool: link: `::' is not valid version information > *** Error code 1 > > and I had not had the chance to look into that yet, was planning on doing > that later, but if you can suggest a fix that would be great.. Looks like the variables ABI_CURRENT, ABI_REVISION and ABI_AGE are just not set. This is a separate issue. Regards, Ralf pth_example.tar.gz Description: GNU Zip compressed data ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Building all static
* Bill Moseley wrote on Tue, Nov 02, 2004 at 03:33:02PM CET: > On Tue, Nov 02, 2004 at 12:39:10PM +, Gary V. Vaughan wrote: > > $ libtool --help --mode=link | grep static > > -all-static do not do any dynamic linking at all > > -static do not do any dynamic linking of libtool libraries If you do that with branch-2-0, give some weeks before the then-uncovered bugs have settled. (I'm just thinking that without further changes all tests are going to test something different now :-) Besides, it's a clear change of published interface (this doesn't mean I'm for or against the change. Just needs to be marked VERY VERY big. Users of former Libtool-type `-static' will need to use libtool --version in order to differentiate old and new behavior, and so on. Ugly. How many packages/people use this? How many people have called other autotools names because of interface changes?) > > > > 2) Is there a "standard" way to run configure that should build a > > > completely static binary? > > > > Assuming libtool is doing all your linking: > > > > ./configure LDFLAGS='-all-static' > > $ ./configure --prefix=$HOME/static LD_FLAGS='-all-static' >/dev/null && make > install >/dev/null Is that a mail-only typo? You used LD_FLAGS instead of LDFLAGS. But then, configure will most likely fail soon, before libtool is even involved -- the compiler will see -all-static and barf. There's been discussion about this on this list about Libtool-specific environment variables and -Xlinker stuff. However, I do not know a general approach to your setting. I'd just do configure LDFLAGS=-static make LDFLAGS=-all-static but that's obviously a hack. A general solution to this problem is needed. *big snip* > > > Unless someone shouts me down, then according to the principle of least > > surprise, I'm inclined to change the semantics to: > > > > -static do not do any dynamic linking at all > > -lt-staticdo not do any dynamic linking of libtool libraries > > As long as "libtool libraries" is clear. Well, the term is defined in the manual. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Building all static
* Gary V. Vaughan wrote on Tue, Nov 02, 2004 at 04:33:45PM CET: > Bob Friesenhahn wrote: > > On Tue, 2 Nov 2004, Gary V. Vaughan wrote: > > > > This seems like a particularly bad idea to me. What is the value of > > changing existing documented libtool behavior? > > Consistency, and user expectation. Looking through the archives I see the > repeated question of why -static still links shared libraries for libtool, > but not when linking with the compiler driver or system linker: I think that if there were a way to specify options to `libtool --mode=link' on the configure line, then probably many people could settle with -all-static. Anyway you do it, users cannot at the moment use both possibilities, because one of them will not pass configure tests. /That/ is the main problem. Guess you could even map that to --enable-all-static or something like that (ugly, I know). Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: error with inter-library-dependencies
* Christoph Wellner wrote on Wed, Nov 03, 2004 at 03:08:02PM CET: > > I have a problem with libtool-1.5.6, when I want to start my compiled app, > I get an error-message, that some libraries are not found: > > /home/chwellner/nmm2_sarge/apps/clic/.libs/lt-clic: error while loading > shared libraries: libnmmutils.so.0: cannot open shared object file: No > such file or directory > > when I call ldd on the binary, I get the following output: > > ldd .libs/lt-clic > *snip* > > before we used libtool 1.4.2a on debian woddy, but after upgrading to > debian sarge with libtool 1.5.6 we get the error mentioned above. > > Does someone have an explanation or solution to this problem? Hmm, maybe not enough information, but some ideas on what could've gone wrong .. ideas: Could you try using current Libtool branch-2-0? Maybe libtool--gary--1.0--patch-49 has to do with the problem. Does linking work using installed versions of the libraries? Note that here it might currently be important that you install libraries in the correct order. Not automatically installing interdependent libraries in the correct order is a yet-unsolved Automake/Libtool problem. Further ideas/inquiries: Does it work when building with `make LDFLAGS=-static' or `make LDFLAGS=-all-static'? You could post some relevant Makefile.am parts, or, even better, a small example reproducing this problem (I see that this might prove non-trivial). Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Library search path and cross-compilation
Hi Sasayama, * Sasayama wrote on Tue, Nov 09, 2004 at 05:26:52AM CET: > I'm trying cross-compilation of libtoolized packages and have problems. > > First, libtool searches /lib, /usr/lib, and /usr/local/lib for .la files > instead of implicit library directories for cross-compilation, and fails > to link unless I specify those directories explicitly. > > Second, since the .la files specify the library directories in the > target environment, they must be modified for successful > cross-compilation. This requires me to maintain two versions of a .la > file, one for target and the other for host. > > Third, if I have worked around the second problem, libtool sometimes > embeds host directories in the run path which is wrong in the target > environment. > > Is there any idea to solve them? Or does a newer developer version > already has support for cross-compilation? I have version 1.5.10 now. Cross-compilation support is still quite bad in Libtool, as you've had to learn the hard way. I think it's a worthwhile goal, however, and would be happy to see patches improving on that matter (while not removing otherwise necessary functionality). | [-- Attachment #2: tte_sasayama.vcf --] Please do not use binary attachments in mailing lists -- thank you. (Might help you get through more spam filters.) Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
Hi Peter, * Peter Ekberg wrote on Tue, Nov 09, 2004 at 01:33:29PM CET: > Hello! > > There is no exception from the GPL in m4/ltoptions.m4, like > there is in the other lt*.m4 files in that directory. Is > that an oversight or is this file only needed for backwards > compatibility or something like that? Not only this file: also missing the exception are m4/argz.m4 m4/ltversion.m4 (is this short enough so it doesn't need any license?) libltdl/Makefile.am libltdl/configure.ac libltdl/loadlers/Makefile.am which are used with `libtoolize --ltdl'. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Peter O'Gorman wrote on Tue, Nov 09, 2004 at 02:46:09PM CET: > I just want to get some possibilities out there into the ether. Feel free > to add more bits/say which bits are silly. branch 2.0: missing arches: If possible, we need more `make check' reports. Am working on two. Somebody needs to fix MinGW. I would like to see one arch which has no dynamic linking but still passes the relevant libltdl preopen tests. Anyone? > Post 2.0: > > 1. Generate a libtool.m4 from a bunch of individual file, one per platform, > to make the job of a "platform maintainer" easier and make it easier to add > new platforms. Will this increase or lessen total code? > 2. Generate some "platform specific" shell functions with config.status, > for example, there is no need to have the C source code for the wrapper > script on non-windows platforms, this will make the generated libtool > script smaller and easier to follow, maybe a little faster too? Sure. > 3. Try and recruit some people to translate the docs? I could care less. Improve current docs first (they are not bad, but a little outdated in places). Second be determined to keep docs current (like: don't accept a patch for a new feature without accompanying docs). Third convince someone (else) to translate. > 4. Fix threads. Big ACK. As Bob stated, they might prove nasty. > 5. Think about speed, compile mode needs to be as fast as possible, can it > be faster than it is? Sure. Bob suggested extending ltmain.c some time ago. :) 6. Versioned libraries. Although this is not very portable yet, it is a concept which IMHO needs support. Many people ask for it. 7. Change libltdl interface: add separate functions for function pointers. This will allow porting to systems where function pointers are incompatible with data pointer C-wise. 8. Support cross-compilation correctly. 9. Support multilibbing. 10. More testcases. Faster test suite. Please submit test cases for stuff that does not work. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Gary V. Vaughan wrote on Tue, Nov 09, 2004 at 04:37:38PM CET: > Ralf Wildenhues wrote: > > 10. More testcases. Faster test suite. Please submit test cases for > > stuff that does not work. > > I was thinking about this myself while working on Autotestifying things. > I think there is a lot of room to build our testcases without resort to > autoreconfing a whole project. These tests are good too, but I think > that a lot of the things we want to test are in libtool alone, so we > ought to be able to write a Makefile that calls $(top_builddir)/libtool > directly to perform various build tests in a source tree... > > I plan to tackle this as I rewrite the testsuite post-2.0. Great. While we're at the testsuite: the current HEAD new testsuite does not source atconfig (at least in the VPATH case), so $abs_top_builddir is not set, so $LIBTOOLIZE is bogus. Do we need to have the complicated setup where the Makefile generation rules for `testsuite' are in the toplevel, but the testsuite dir is `tests'? Also the results of $LIBTOOLIZE and autoreconf and configure in AT_BOOTSTRAP are not checked (on purpose?). Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Missed that one reading the first time.. * Gary V. Vaughan wrote on Tue, Nov 09, 2004 at 03:24:25PM CET: > > 3. Try and recruit some people to translate the docs? > > I think there is already a GNU translation project to take care of that. > We just need to figure out what the process is :-) > > 3.5. While we are there, maybe internationalise libltdl? Please don't. If you do, make it possible to have zero(!) overhead for ltdl users if they choose not to make use of the translation capability. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Ralf Wildenhues wrote on Tue, Nov 09, 2004 at 04:29:37PM CET: > * Peter O'Gorman wrote on Tue, Nov 09, 2004 at 02:46:09PM CET: > > I just want to get some possibilities out there into the ether. Feel free > > to add more bits/say which bits are silly. > > branch 2.0: > > I would like to see one arch which has no dynamic linking but still > passes the relevant libltdl preopen tests. Anyone? Decide whether we also allocate the slist* prefix in libltdl; document the resulting namespace requirements or wrap under lt_*. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Alexandre Duret-Lutz wrote on Wed, Nov 10, 2004 at 09:53:37AM CET: > >>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: > > Bob> Automake can at least keep its part of the house in order by ensuring > Bob> the correct library install order within the same Makefile. It does > Bob> build the libraries in the correct order, assuming that LDADD has been > Bob> used properly. > > I'm afraid I'm lost. I understand these two paragraphs as > > 1. dependencies are inherited at link time > 2. libraries are already built (hence linked) in the correct order > > So when are the incorrect dependencies registered? At relink-time? > Can't those of link-time be used? > > Bob> One approach which could be used is for libtool to support a mode > Bob> where it is provided with a list of all the .la files for libraries to > Bob> be installed, and libtool returns a re-ordered list which is ordered > Bob> by increasing dependency. Automake would then use this to order its > Bob> installation of libtool libraries. Efficient implementation of this > Bob> capability in bourne shell sounds quite challenging. > > Not only that, but also supporting a arbitrary installation > order of libraries in multi-Makefile projects. Just to throw in random ideas: Let libtool output Makefile snippets in .libs/Makefile.libdep at link time, providing dependency information based on what it knows then. `make' is the canonical program to deal with topological sorting. Let make use these at install time, maybe through a generated script or some other mechanism (so that the Automake-generated Makefiles do not have to depend on .libs/Makefile.libdep to exist). No, I have not thought this through. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Gary V. Vaughan wrote on Wed, Nov 10, 2004 at 02:25:11PM CET: > Peter O'Gorman wrote: > > Gary V. Vaughan wrote: > > >>> Post 2.0: > > > >>> 1. Generate a libtool.m4 from a bunch of individual file, one per > >>> platform, to make the job of a "platform maintainer" easier and make it > >>> easier to add new platforms. > >> > >> Seems like a good idea, but I think it will prove difficult in > >> practice -- unless we redo the way we have written all the macros. > >> > >> I think that it is a good enough idea to be worth discussing some more > >> though. How do you envision the architecture for parsing and using the > >> platform chunks? No idea, just a comment: /If/ you go through all the pain to redo the platform chunks, and also change ltmain implementation, don't make it so everything has to be changed twice. [ xslt .. ] > > Gah, perl? Blech. XML? Bah! Choke... > > *snip* > There... I've got it off my chest, and feel much better now :-) /me agrees on everything you said except about perl. > Libtool already depends on C, so we don't need to resort to Perl. We can > always prototype something in Perl, and then before we forget what all > those strings of puntuation do, we should convert it to Shell and/or C. Why prototype in perl what you can write in shell (or other) right away? > I think that porting ltmain to C or a byte-compiled language of some sort > is definitely a win all round, so we can probably come up with an > implementation in whatever language ltmain gets rewritten in eventually. > > I *do* think your idea fantastic idea btw... I guess the ball is in my > court to figure out how we might do it without Perl and xslt now :-/ That'll > teach me! :-o My vote: against everything but shell and C for ltmain. For the rules, make might prove fine (except that the portable set is quite limited). I'd do C++ (with STL), but that's out of the question portably-wise. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Gary V. Vaughan wrote on Wed, Nov 10, 2004 at 05:37:19PM CET: > Ralf Wildenhues wrote: > > * Gary V. Vaughan wrote on Wed, Nov 10, 2004 at 02:25:11PM CET: > >>Gah, perl? Blech. XML? Bah! Choke... > > > >>There... I've got it off my chest, and feel much better now :-) > > > > /me agrees on everything you said except about perl. > > Just curious... Do you mean that you disagree with my perl rant? Kind of. Perl readability depends on both the eye of the beholder and the mind of the writer. But I strongly agree on all the other cruft. > >>Libtool already depends on C, so we don't need to resort to Perl. We can > >>always prototype something in Perl, and then before we forget what all > >>those strings of puntuation do, we should convert it to Shell and/or C. > > Or that you think prototyping in Perl is dumb? Nope. I rather think that it won't give libtool much that shell cannot. Use more shell functions. > > Why prototype in perl what you can write in shell (or other) right away? > > I think there is value in prototyping in HLL to work out algorithmic > issues before writing the real implementation in a LLL for speed. Arguably, > ltmain.sh is our HLL prototype. Except that it seems to be a good idea > to separate platform details from rules at this point, so we probably need > another prototype now :-l Why can't this separation be done in ltmain.sh? > > My vote: against everything but shell and C for ltmain. For the rules, > > make might prove fine (except that the portable set is quite limited). > > I'd do C++ (with STL), but that's out of the question portably-wise. > > > Gah, C++? Bleh! > > > Kidding! > > Sure, introducing another dependency is only a good idea if there are > definite tangible benefits. I've enumerated a few, but probably not > enough to make it an obvious choice. Of course, the person who implements > it gets the casting vote ;-) /me runs away quickly. :) Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Ralf Wildenhues wrote on Wed, Nov 10, 2004 at 10:09:08AM CET: > * Alexandre Duret-Lutz wrote on Wed, Nov 10, 2004 at 09:53:37AM CET: > [ library dependencies and `make install' ] > > > > Not only that, but also supporting a arbitrary installation > > order of libraries in multi-Makefile projects. > > Just to throw in random ideas: > Let libtool output Makefile snippets in .libs/Makefile.libdep at link > time, providing dependency information based on what it knows then. > `make' is the canonical program to deal with topological sorting. > > Let make use these at install time, maybe through a generated script or > some other mechanism (so that the Automake-generated Makefiles do not > have to depend on .libs/Makefile.libdep to exist). More specific: Let config.status create Makefile snippets .deps/lib.Po (take another name that does not conflict; I'm not sure about .deps or .libs yet) per LTLIBRARY, just as it does for compile dependency generation. Each `libtool --mode=link' fills in the dependencies as a side-effect, just like depcomp does. All paths in there are relative to $top_builddir. We could add an option `-MT .deps/lib.Po -MD -MP -MF' to libtool for outputting this information. :-) Now two (at least) options for Automake: - Put all actual installation rules (one per LTLIBRARY, maybe this can be improved) in $top_builddir/Makefile.in, include all snippets from there. This unfortunately breaks executing `make install' in a subdir (because the rules are only in the top_builddir (but `make install' from a subdir was most likely broken in this package anyway because of the ltlibrary dependencies). For non-recursive Makefiles this is the right way. I think this can be made almost as fast as the current process (without dependency information). - Put each rule in its dir's Makefile.in, let libtool add rules like cd $builddir && $(MAKE) inst-ltlibLIBNAME to the snippet in .deps. This will be *slow*. What's the expected number of libraries per package? About programs: You just install them all after installing all the libraries. Can we expect users of the Automake subpackage feature to separate their library dependencies by hand? As in: subpkg1 needs to be installed before subpkg2, both before main? Seems reasonable to me. I have more time next week, maybe I can put something together then. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Scott James Remnant wrote on Wed, Nov 10, 2004 at 04:43:48PM CET: > On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: > > > 6. Absorb the functionality of the aberration called pkg-config. Libtool > > already has all the information it needs, we just need to teach it (or > > maybe a subsidiary script) to spit out link flags after poking around > > in a dependency chain of .la files. > > > There's actually a couple of things pkg-config does that Libtool doesn't > currently do. pkg-config's main job can be summed up simply as enabling > parallel-installed -dev packages. > > Principally it provides the right -L and -l flags to link libraries, we > can get this from Libtool. An an improvement would then be only > providing the dependency -l flags on platforms that need it, and not on > Linux for example. I've so far been unaware of the reason why libtool does not set link_all_deplibs to `no' on linux, as you put in the Debian package. Can anybody point me to a reason/docs/thread explaining this? > However it *also* provides the right -I flags to point at the include > files. A GTK+ application will '#include ' for example > and require -I/usr/include/gtk-2.0 to actually be able to find that (or > -1.0, -3.0, etc.) That's a good feature. Dunno whether I want that (or it can even be) in a .la file or not. But letting libtool output both information might prove valuable. Absorbing pkgconfig in libtool in a way that each pkgconfig user must use libtool will pave way for quote some resistance, I'd expect. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
[ slightly reformatted ] * Bob Friesenhahn wrote on Wed, Nov 10, 2004 at 08:31:15PM CET: > On Wed, 10 Nov 2004, Noah Misch wrote: > >On Wed, Nov 10, 2004 at 12:28:24PM -0600, Bob Friesenhahn wrote: > >>The problem is that Automake does *not* know the dependency graph of > >>each object. Within one Makefile, this is possible (and mostly > >>supported) but most projects depend on SUBDIRS to recurse though > >>subordinate Makefiles so there is no full dependency graph of each > >>object. The build is dependent on careful ordering by the developer > >>rather than Makefile dependencies. > > > >Thanks for the correction. > > > >If Automake descends into SUBDIRS to install in the same order it > >does to build and uses `make' dependencies to ensure proper ordering > >within each SUBDIR, then the products should relink/install in the > >correct order. Right? > > That would be my assumption as well. The current library install > mechanism does not ensure that libraries are installed in the same > order that they are built. This statement seems to me to imply that Automake should be able to do the job on its own, without any additional information from libtool, given the library dependencies are stated correctly in the Makefile.am's. So, can the user not enforce inter-Makefile dependencies through the use of `libfoo_la_DEPENDENCIES = sub/libbar.la' ? > A problem exists in that if a library is already installed on > the system, it may be used by accident, either at build time, or at > install time. This masks serious build/install ordering issues. Yes. > Package developers usually already have the library installed on the > system so they may not see the failure in their environment, but > end-users do. 'make distcheck' helps significantly with discovering > these problems. BTW, this topic shouldn't have any extra issues in the cases of staged installs (checked by `make distcheck') and cross-compilation, right? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
I've been away for a few days.. * Gary V. Vaughan wrote on Sun, Nov 14, 2004 at 09:44:19PM CET: > Scott James Remnant wrote: > > >They're both trying to deal with platforms like Solaris that don't have > >a needed-following link loader. > > That's a good idea, if we know the linker can find deplibs without > help, we should take advantage of that to shorten the link line! > Please add it to TODO. Seconded (or thirded, or whoever also wants this). On systems where deplibs are handled by the linker, libtool should give the advantage back to the user. IMVHO this is actually increasing the value of libtool, because it allows the user to make use of the features of the underlying system. Just let the docs explicitly tell that the non-implicit dependencies on other systems will lead to more work for the end-user there. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 01:11:26PM CET: > Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Sun, Nov 14, 2004 at 09:44:19PM CET: > >>Scott James Remnant wrote: > >> > >>>They're both trying to deal with platforms like Solaris that don't have > >>>a needed-following link loader. > >> > >>That's a good idea, if we know the linker can find deplibs without > >>help, we should take advantage of that to shorten the link line! > >>Please add it to TODO. > > > >Seconded (or thirded, or whoever also wants this). > >On systems where deplibs are handled by the linker, > >libtool should give the advantage back to the user. > >IMVHO this is actually increasing the value of libtool, > >because it allows the user to make use of the features > >of the underlying system. Just let the docs explicitly > >tell that the non-implicit dependencies on other systems > >will lead to more work for the end-user there. > > No need for that. It should all be transparent to the user. > Libtool will continue to use its long deplib link lines unless > it knows that the host platform can follow deplibs on its own, > in which case it only adds the direct dependencies to the > link line, and trusts the linker to find the deplibs. So will libtool do The Right Thing in all circumstances, given the tiny patch to enable link_all_deps=yes on linux and whatever other system has this linker feature? The patch that is in Debian's libtool? If yes, the why in the world are we not using it? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Peter O'Gorman wrote on Tue, Nov 09, 2004 at 02:46:09PM CET: > I just want to get some possibilities out there into the ether. Feel free > to add more bits/say which bits are silly. > > Post 2.0: glibc HEAD NEWS has: | | Namespaces in ld.so are implemented. DSOs can be loaded in separate | namespaces using the new function dlmopen(). This feature is of course, | like most other dynamic loading functionality, not available in statically | linked applications. Implemented by Ulrich Drepper. I have not yet looked at the exact semantics. But we can look if we can support this (and maybe also add the semantics to ltdl-preopened libtool libraries). Furthermore, wrap | New functions `dladdr1' and `dlinfo' in provide more ways to | interrogate the dynamic linker, compatible with the Solaris interface. because in some cases ltdl can provide some of the additional information. Actually, I haven't looked at the specs, so maybe all we need to do is nothing/just use the new functions if they are available. After all, Libtool is GNU software, and should work nicely on GNU systems, right? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
* Sean Dague wrote on Thu, Nov 11, 2004 at 09:45:40PM CET: > The issue I reported a couple weeks ago is still there. We have now tracked > down based on a number of versions of libtool to figure out what works and > what doesn't. > > libtool 1.4.x - all versions work that we've tried > libtool 1.5.2 - works > libtool 1.5.6 - doesn't work > libtool 1.5.10 - doesn't work > > The end of the logs are included at the end of this email (on libtool 1.5.6): First: Your build is not VPATH clean, because you are doing a lot of symlinking by hand in several Makefile.am's. First, you should be using $(LN_S) together with AC_PROG_LN_S for symlinks, second you should link to $(srcdir)/relpath/$@ instead, third you should probably instead just be using AC_CONFIG_LINKS and be happy that you don't have to care about this yourself. All explained in Autoconf docs. Apart from these changes, `make distuninstallcheck' is the first part of `make distcheck' to complain, and it complains about some files which `make uninstall' misses to remove. This is with the HEAD branch as well as branch-1-5 of libtool. So, can you try either the patch from http://lists.gnu.org/archive/html/bug-libtool/2004-10/msg00170.html and possibly branch-2-0 from CVS? Please tell us your findings. > What is most interesting is that the > /home/sdague/tmp/am-dc-21838//home/sdague/openhpi/openhpi-1.9.3/ directory > doesn't exist at all on my system. That seems to be created very late in > the make distcheck processing, but why it isn't there I'm not sure. I /think/ this has nothing to do with your problem (though I cannot be sure, as I haven't understood what went wrong), and is fine because `make distcheck' is attempting a DESTDIR install. BTW, you did not mention your system at all, neither whether you are doing a VPATH build or not. All of this would have been helpful (still is if the problem remains unsolved), also whether or not an installed version of your package exists on your system or not. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET:
> >Bob Friesenhahn wrote:
> >>
> >>This solution does not seem to support the case where an actual
> >>dependency exists but is not registered in the library (because the
> >>user didn't supply it) so that the dynamic link loader doesn't know
> >>about it?
>
> Good point. We really ought to check the library registered
> dependencies against the .la deplibs and only drop the deplibs
> common to both, since we know the linker will pick those up.
> I guess that means looking through the dependency tree of .la
> files to find matches.
I don't think so. If there is a real dependency, then we want it to be
noticed. Look:
libA -> { libB, libC }
libB -> libC
Now libB is rewritten to not need libC any more (imagine it provides
low-level stuff like glib). If we do not listen to what the user tells
us, we end up with a broken installed library libA.
> Also, what do we do about -rpath? We still need to encode the
> runtime path to even the dropped deplib directories so that the
> same library we linked with is picked up at runtime.
Erm, is this not handled in the depending library? (I have no idea,
really, but I hoped this would be so.)
> >>If libone or libfour contain weak symbols, what happens?
>
> I have no idea! Scott?
Me neither.
Regards,
Ralf
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Howard Chu wrote on Mon, Nov 15, 2004 at 10:29:04PM CET: > Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET: > > >>Also, what do we do about -rpath? We still need to encode the > >>runtime path to even the dropped deplib directories so that the > >>same library we linked with is picked up at runtime. > > >Erm, is this not handled in the depending library? (I have no idea, > >really, but I hoped this would be so.) > > This is definitely a sticky problem. We do builds that "install" to a > path that is different from their actual, final destination. I'm finding > that the rpath handling at various stages of a build tries to be too > smart for its own good. E.g., I have a build tree in my home directory > for a number of packages in ~/BLD, the ultimate destination is /opt/foo, > and everything is staged into ~/BLD/opt/foo. For files in the resulting > package that contain embedded RPATH/RUNPATHs, I only want "/opt/foo" > present in the binary, but I find a lot of instances of > "/home/hyc/BLD/opt/foo" that I have to squash by manually relinking. This sounds to me like a genuine bug in Libtool, *not* a structural limitation that cannot be overcome. Can you be bothered to provide a testcase which exposes this failure? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET: > > >+2004-03-28 Scott James Remnant <[EMAIL PROTECTED]> > >+ > >+* ltmain.in: The dynamic link loader on some platforms is able to > >+correctly traverse dependency trees, therefore when $link_all_deplibs > >+is set to 'no' don't add the contents of dependency_libs to the > >+link line to link a program. > >+* m4/libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [linux*]: Linux is one > >+of those platforms, set link_all_deplibs to 'no' for both C++ and > >+other compilers. > >+* NEWS: Updated. > > Bob's second point needs addressing first, IMHO. I think the > -rpath stuff will come out in the wash provided we are careful. > > Either way, this is a deep change for HEAD only. Actually, because of the problem Daniel described in [EMAIL PROTECTED], I would consider this a bug in current libtool. If you use .la files, the problem exists, if you directly link to the .so, it doesn't. The failure might be silent. Sounds like a bug to me. BTW, precisely because Debian has used this for a long time, I think this change will have less problems than some of the other recent changes (versioned libtool installs come to mind). Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
[ slightly reordered your answers for ease of consistent answers ] * Sean Dague wrote on Tue, Nov 16, 2004 at 05:56:11PM CET: > On Mon, Nov 15, 2004 at 04:20:05PM +0100, Ralf Wildenhues wrote: > > * Sean Dague wrote on Thu, Nov 11, 2004 at 09:45:40PM CET: > > > The issue I reported a couple weeks ago is still there. We have now > > > tracked > > > down based on a number of versions of libtool to figure out what works and > > > what doesn't. > > > > First: Your build is not VPATH clean, because you are doing a lot of > > symlinking by hand in several Makefile.am's. > > Yes, we are doing this because there is a need to build test cases which use > our real code, and the symlink solution seemed to be the most workable. Sure, the idea seems fine to me. > > BTW, you did not mention your system at all, neither whether you are > > doing a VPATH build or not. All of this would have been helpful (still > > is if the problem remains unsolved), also whether or not an installed > > version of your package exists on your system or not. > > Excuse my ignorance, but I'm not sure of what a VPATH build is. Where the build tree is different from the source tree. (It's called that way because the necessary `make' feature has to do with the VPATH make variable). Example: Your source is in /tmp/openhpi/. I do: $ mkdir /tmp/build-openhpi && cd /tmp/build-openhpi $ ../openhpi/configure -C $ make Actually, to find such and other dependency bugs quickly, I replaced the `make' with: $ make -j2 distcheck > > First, you should be using $(LN_S) together with AC_PROG_LN_S for symlinks > > Agreed, making that change now > > > second you should link to $(srcdir)/relpath/$@ instead > > Also agreed, making that change now Watch out. You link to some built sources and some non-built sources. When trying your code, I replaced the link-setting snippets with something like $(REMOTE_LIB_SOURCES): if test ! -f $@ -a ! -L $@; then \ if test -f ../$@; then \ $(LN_S) ../$@ $@; \ else \ $(LN_S) $(srcdir)/../$@ $@; \ fi; \ fi so that they would still work regardless where the file-to-link-to was found. Also, note that this is safe only if $(REMOTE_LIB_SOURCES) contains only target names in the current directory (also explained in Autoconf docs). > > third you should probably instead just > > be using AC_CONFIG_LINKS and be happy that you don't have to care about > > this yourself. All explained in Autoconf docs. > > I'll look into that possibility as well, though wouldn't that require > centralizing all linking code to configure.ac, instead of letting the > Makefile.am deal with it locally? Yes. This is arguably a deficiency. However, first it replaces each snippet as above to one short line, second you probably could move it into a separate .m4 file where you define a macro which you then use in configure.ac. I don't know if the latter is worth the effort. > > Apart from these changes, `make distuninstallcheck' is the first part of > > `make distcheck' to complain, and it complains about some files which > > `make uninstall' misses to remove. This is with the HEAD branch as well > > as branch-1-5 of libtool. > > > > So, can you try either the patch from > > http://lists.gnu.org/archive/html/bug-libtool/2004-10/msg00170.html > > and possibly branch-2-0 from CVS? Please tell us your findings. > > I will check it out and report my results. Great! > The system I am running on is Mandrake Linux 10.1 on x86 (we've seen the > failure with FC3 as well). > > There is not and installed version of the libraries on my system. Good to know. If this thread gets more application-dependent and less libtool-dependent, we should probably move to some openhpi-related list (Cc: me then, please, as I don't read any of those). Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Jacob Meuser wrote on Tue, Nov 16, 2004 at 08:00:28PM CET: > On Tue, Nov 16, 2004 at 03:01:06PM +, Scott James Remnant wrote: > > On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote: > > > > > On Mon, Nov 15, 2004 at 03:45:10PM +, Scott James Remnant wrote: > > > > It does assume that all library dependencies are registered, yes. This > > > > has never been a problem, because we've never found any Libtool-produced > > > > library that doesn't have all dependencies registered. > > > > > > > > If this isn't the case, and at one time Libtool never registered all of > > > > the dependencies, we should check for that. Otherwise I don't see the > > > > need -- we can assume sanity from our own output. > > > > > > for a long time, libtool did not handle -pthread properly. > > > > > It still doesn't, the current situation is a botch that produces the > > right results but does it in the wrong way. Libraries should record > > what compiler/linker flags they need (-pthread is not a dependency > > library). > > record how? in the dependency_libs section of an .la file? you seem > to be saying no, so then where? It's already in HEAD. Stored in inherited_linker_flags. > > > I can point to at least a few .la files on my system that do > > > not have -pthread or even other required libraries registered. > > > > > I'd be quite shocked if the current version of Libtool produces > > libraries with -pthread in dependency_libs; I specifically wrote the > > patch to prevent that, because it causes a lot of problems. > > if -pthread is needed but missing, then I get errors about missing > symbols, much like if a library is missing from the link command. Note that the patch in HEAD is not a complete solution to the problem. It's not portable/right in general to only compile a library thread-safe and not the entire application, or even compile against different thread implementations (one library against one, the other against another). All this probably cannot be solved by libtool, but some possible problems can be warned about (this is not yet implemented). Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Jacob Meuser wrote on Wed, Nov 17, 2004 at 01:07:20AM CET: > On Tue, Nov 16, 2004 at 11:00:34PM +, Scott James Remnant wrote: > > On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote: > > > On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote: > > > > Actually, I'd say the opposite is true ... the LONGER link line, > > > > produced by the current Libtool, is what allows people to get away with > > > > this because Libtool puts more stuff into the link line. > > > > > > > > A shorter, more concise, link line actually forces people to make sure > > > > they *do* link anything they require themselves, rather than relying on > > > > Libtool to do the right thing for them. > > > > > > but where does the problem show up? on !Linux, because Linux will > > > "do the right thing". > > > > > No, on Linux ... because Linux does the right thing and causes the > > applications to break; whereas Libtool does the wrong thing and links > > the application directly with half the libraries on the system. > > from my understanding, correct me if I'm wrong, Can you also be bothered to read [EMAIL PROTECTED] again? For archive users, that is message http://lists.gnu.org/archive/html/libtool/2004-11/msg00319.html > on Linux, to the linker, all library deplibs do not need to be > specified ACK. > on other systems, to the linker, all library deplibs do need to be > specified. On some other systems. > libtool is to handle this transparently, just specify the library, > and, if needed, libtool will add the deplibs. That's what libtool does for every system right now, not only if needed. Scotts keybuk-linux-deplibs.patch would change this behavior on linux. > am I right so far? I think so. > so when libtool fails to complete the deplibs (I still haven't seen > any explanation for what happens when one of the deplibs is a > non-libtool library), where is there breakage? not on Linux, because > it doesn't need the deplibs anyway. No breakage. Developer education: "There exist other systems with linkers that need dependencies explicitly specified." This education method is not foolproof, however, thus the proposed change. > how would linux cause the application to break if there was a deplib > explicitly specified? Read the message above. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Patch for Portland compiler support
Hi Jeff, * Jeff Squyres wrote on Wed, Nov 17, 2004 at 03:00:22PM CET: > > Some of the consumers of our software use the Portland Group compilers > (http://www.pgroup.com/). Libtool 1.5.x doesn't seem to recognize > these compilers, and therefore doesn't always do the Right Things. Libtool doesn't know about Portland's compilers at all (so far). > I have *barely* dived into the libtool source, but I have come up with > a patch for the current CVS branch-1-5 that seems to make libtool do > the Right Things for pgcc on Linux (I didn't try for an analogue on the > CVS trunk for the 2.x series). Could this patch be considered for > future releases of Libtool? Actually, I'm wondering about the name. There has once been a pentium gcc, abbreviated pgcc as well. How unfortunate :( I don't know how much the pentium gcc is still in use, but the fact that this one is not meant deserves at least a comment within the m4 snippet. Looking at its webpage, it looks pretty dead, though. (Fortunately, gcc on linux understands all the variable values you've submitted so far. We might just get away with it anyway.) But certainly there will be more problems with pgcc? What about pgf77 and pgCC? Could you or one of your consumers be bothered to try branch-2-0 of libtool (1.9f will do fine as well) and report us more possible problems its testsuite reports (VERBOSE=x output for failed tests is good), so that we can support it right, not only halfway? (This is the more interesting for you since we won't bother much with libtool-1.5 any more as soon as 2.0 is out). Do you/your consumers use pgcc on Windows? That's probably going to be a whole different (and scarier) story. Other than that, we love ChangeLog entries. :) > --- libtool.m4 19 Sep 2004 12:13:50 - 1.314.2.50 > +++ libtool.m4 17 Nov 2004 13:54:58 - > @@ -4952,6 +4952,11 @@ > _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' > _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static' > ;; > + pgcc*) > + _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' > + _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic' > + _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' > +;; >ccc*) > _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' > # All Alpha code is PIC. > > Please forgive me if this patch is egregiously wrong -- if it is, any > advice on making it Right would be tremendously appreciated! Looks good. The branch-2-0 equivalent would be similar -- just grep for ccc in libtool/m4/libtool.m4. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
* Sean Dague wrote on Wed, Nov 17, 2004 at 06:07:55PM CET:
> On Tue, Nov 16, 2004 at 06:32:51PM -0800, Jacob Meuser wrote:
>
>
> > /home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so
> > doesn't yet exist?
>
> Nothing exists in _inst except directories, as this phase of make distcheck
> is happening after it has done make uninstall on the _inst directory.
Thanks for this hint. I know now what the problem is.
One of the bugs that will hit on cross-compile. Just need to find out
where the buggy code is:
What I overlooked until now: The error occurs only in the DESTDIR
install, not in the regular one. The failure is here (last few lines of
the log Sean made available online):
/bin/sh ../libtool --mode=install /usr/bin/install -c libopenhpi.la
/home/sdague/tmp/am-dc-28498//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpi.la
libtool: install: warning: relinking `libopenhpi.la'
(cd /home/sdague/openhpi/openhpi-1.9.3/_build/src; /bin/sh ../libtool
--mode=relink gcc -g -O2 -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -Wall -Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes -Wpointer-arith -Wformat=2 -Wformat-security
-Wformat-nonliteral -Wno-format-y2k -Wcast-qual -Wcast-align -Werror
-D_GNU_SOURCE -D_REENTRANT -fexceptions -g -O2 -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -Wall -Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes -Wpointer-arith -Wformat=2 -Wformat-security
-Wformat-nonliteral -Wno-format-y2k -Wcast-qual -Wcast-align -Werror
-D_GNU_SOURCE -D_REENTRANT -fexceptions -o libopenhpi.la -rpath
/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -L../utils -version-info 10:3:9
-export-symbols ../../src/hpi.sym config.lo domain.lo event.lo alarm.lo
hotswap.lo lock.lo plugin.lo plugin_static.lo init.lo safhpi.lo session.lo
oHpi.lo ../utils/libopenhpiutils.la -lltdl -pthread -lgthread-2.0 -lglib-2.0
-lm -lpthread -inst-prefix-dir /home/sdague/tmp/am-dc-28498/)
echo "{ global:" > .libs/libopenhpi.ver
cat ../../src/hpi.sym | sed -e "s/\(.*\)/\1;/" >> .libs/libopenhpi.ver
echo "local: *; };" >> .libs/libopenhpi.ver
gcc -shared .libs/config.o .libs/domain.o .libs/event.o .libs/alarm.o
.libs/hotswap.o .libs/lock.o .libs/plugin.o .libs/plugin_static.o .libs/init.o
.libs/safhpi.o .libs/session.o .libs/oHpi.o
-L/home/sdague/tmp/am-dc-28498//usr/lib -Wl,--rpath
-Wl,/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -L/usr/lib
-L/home/sdague/openhpi/openhpi-1.9.3/_build/utils
-L/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -lopenhpiutils -lltdl -pthread
-lgthread-2.0 -lglib-2.0 -lm -lpthread -Wl,-soname -Wl,libopenhpi.so.1
-Wl,-version-script -Wl,.libs/libopenhpi.ver -o .libs/libopenhpi.so.1.9.3
/usr/bin/ld: cannot find -lopenhpiutils
collect2: ld returned 1 exit status
libtool: install: error: relink `libopenhpi.la' with the above command before
installing it
The line starting with
| gcc -shared
contains
| -L/home/sdague/openhpi/openhpi-1.9.3/_inst/lib
which is wrong. It should contain
| -L/home/sdague/tmp/am-dc-28498//home/sdague/openhpi/openhpi-1.9.3/_inst/lib
Who finds the culprit?
Ralf
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: Patch for Portland compiler support
* Jeff Squyres wrote on Wed, Nov 17, 2004 at 06:30:27PM CET: > Actually, before I attempt the LT 2.x patch, how does this look for the > 1.5 patch? I checked pgcc, pgCC, pgf77, and pgf90, both in the 1.5 > test suite (I assuming that configuring LT with CC=pgcc [etc.] and then > "make check" is what is necessary?) and with a small sample automake Yes, that should be fine. > package that I made explicitly for testing porpoises. All seems to be > working properly. Great! > Could someone who is Wise in the Ways of Libtool tell me if this patch > looks ok? I did [at least] one questionable thing: in the Linux linker > section, I had to check for pgf77 or pgf90, because, contrary to the PG > documentation, pgf77 and pgf90 need an additional "-fpic" in their > linker command to create a shared library properly. Is this necessary for just a regular shared library or for a shared module (that can be loaded with dlopen)? If the former, then I think your patch is ok. Glancing at libtool.m4, there are a number of cases where it's necessary, maybe we should put them in a separate variable, like pic_link_flag or so. That'll only be for libtool HEAD, though. > I'm also CC'ing the PG support team to see if they have any input. They should update their documentation. :-) > Here's the revised patch (including some fixes from this morning; based > on tests, not the PG documentation ;-) ): Note that branch-2-0 tests are somewhat more challenging, esp. on the Fortran front. I might want to wait with applying this patch until you get to those (in case you find out more necessary stuff there). Other than that, I'll take the patch. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool 2.0 in autoconf tests
* Sander Niemeijer wrote on Thu, Nov 18, 2004 at 01:54:12PM CET: > > I have send this question to the list about a month ago, but > unfortunately, there hasn't been an answer yet, and the release of > libtool 2.0 is not that far away (right?). Hmm. We need to at least wait for the copyright issue to settle, I guess. Other than that, a cursory search of my mail archives of the libtool lists show up on the order of 10-20 unresolved problems, yours being one of them (might as well post a TODO list for 2.0). It's good you bring it up again, it's an important problem from a user's point of view. > I have some self written autoconf tests that check for linking shared > libraries against some specific other libraries (these other libraries > should be available as shared libraries or we might have a PIC problem. > That is what my tests checks for). For this I had to create a variant *snip* I agree with your view of things. I think we should allow this to be done. Gary, you did the whole bootstrap reorganization. Is anything close to this possible? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool 2.0 in autoconf tests
* Sander Niemeijer wrote on Mon, Nov 22, 2004 at 11:00:13AM CET: > > > >The practice: > > > >If you think about what it is you need to know in these terms, you > >should be able to figure out what libtool will do by looking at the > >results of the LT_INIT configure time tests. If you can't, then try > >to express your problem in those terms on this list, and we will be > >able to figure it out for you -- and maybe make a new macro that rolls > >that condition case up to help make it easier to figure out next time; > >and maybe notice that there is something in ltmain.sh that needs to be > >parameterised to make it possible. It might be worth adding some notes > >about this to libtool.texi, where we can later collect additional notes > >that walk through some examples to help future users get into the right > >mindset. > > I hope it is clear that I only want to perform a test that checks > whether a certain library is available and whether it is possible to > link this library against another shared library (which means it should > be a shared library itself). Now, of course, in theory I could write > such a test without performing an actual link or without making use of > libtool. This, however, would mean I would have to add a _lot_ of > knowledge to my test in order to have it work on many platforms with > many compilers/linkers. Knowledge which is usually already available in > the linker (i.e. just trying to link will usually tell you whether it > works or not) and/or the libtool script. Not even considering the > practical points here, even from a theoretical standpoint duplicating > knowledge is _not_ a good idea. > > Now suppose I would use the knowledge provided by libtool are you then > suggesting that libtool should have _two_ interfaces that I should use? > One for use from makefiles (i.e. the libtool script) and one to use > from the configure script (some undocumented combination of lt_ > variables and ltmain.sh)? If this is it, then so be it and I will try > to rewrite my autoconf test to use the lt_/ltmain.sh combination for > libtool 2.0, > but libtool 2.0 surely won't get my vote for the > best-design-of-the-year-award. C'mon Gary, two questions: is it *possible* to provide the old behavior without too much pain? Would that destroy some cool abstraction or some really fundamental thing? Or are you just waiting for a patch to do this? (ok, that was three questions now). Sander, please don't start implementing such a thing *yet*. I don't think going this route is a good idea, but at least I think you should wait until we are through with it. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Convincing Automake to support libtool
* Alexandre Duret-Lutz wrote on Sun, Nov 21, 2004 at 07:20:01PM CET: > >>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: > > Bob> What I have now learned the hard way is that aclocal ignores the > Bob> AC_CONFIG_MACRO_DIR([m4]) definition in configure.ac. > > IMHO it's a bug in whatever let you think aclocal would honor > AC_CONFIG_MACRO_DIR to way you thought. It certainly isn't the > Automake manual. > > See also > http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00097.html Gary, can we revert libtool--release--2.0--patch-67 or fix it? This is a major pain for people when testing branch-2-0. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Convincing Automake to support libtool
* Gary V. Vaughan wrote on Mon, Nov 22, 2004 at 03:19:13PM CET: > Ralf Wildenhues wrote: > > * Alexandre Duret-Lutz wrote on Sun, Nov 21, 2004 at 07:20:01PM CET: > >>>>>"Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: > >> > >> Bob> What I have now learned the hard way is that aclocal ignores the > >> Bob> AC_CONFIG_MACRO_DIR([m4]) definition in configure.ac. > >> > >>IMHO it's a bug in whatever let you think aclocal would honor > >>AC_CONFIG_MACRO_DIR to way you thought. It certainly isn't the > >>Automake manual. > >> > >>See also > >> http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00097.html > > > > > > Gary, can we revert libtool--release--2.0--patch-67 or fix it? > > This is a major pain for people when testing branch-2-0. > > The automake-1.4 compatibility patch? Why, what is wrong with it? Brother. I meant libtool--release--2.0--patch-68. Where's the coffee? Sorry for the noise, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Trying to run 2.1a test suite
Hi Jeff, * Jeff Squyres wrote on Tue, Nov 23, 2004 at 08:12:43PM CET: > I'm working on the Portland Group compilers patch for both the libtool > CVS HEAD and the 1-5 branch (both are attached), and as suggested, am > trying to run the "make check" test suite against the CVS HEAD (it > passes on the 1-5 branch). > > However, "make check" does not appear to be running properly at the > head (or, more specifically, I can't get it to run right). I've > attached the testsuite.log.pgi and testsuite.log.gnu file to show what > I mean (trying to use both the Portland and GNU compilers, > respectively). It seems like some paths are incorrect, and it can't > find some subdirectories. Yes. The HEAD testsuite is somewhat borked at the moment. The branch-2-0 testsuite, however, should be running just fine. I hoped you would be using that (would have saved you some grief). Now if you would just try to apply your HEAD patch to branch-2-0 and the test suite doesn't complain, I'll commit your patches. If you're short on time, it should be sufficient to run all the f77* tests -- their behavior changed the most. Report SKIPs as well as FAILs, please. *snip* > Both testsuite logs show the same kinds of failures. > > Am I doing something wrong? (similar behavior occurs with gcc/g++/g77) Nope, as far as I can tell. We need to fix the HEAD testsuite. Sorry for the inconvenience. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
RFC: proposal for indirect deplibs
This is a draft on how to proceed with the link_all_deplibs problem. The idea is to expose the complexity portably to the user. The rationale is that people get bitten by this complexity anyway, so there is little gain in hiding it. At the same time, systems without needed-following linker should not be penalized. Please comment/flame/improve/whatever. If approved, I will rewrite this to be part of HEADs documentation. Regards, Ralf Libtool and inter-library dependencies == Definitions: direct dependency: A program or library has a direct dependency on a library, if it depends on some interface that library provides, see node Interfaces for a more thorough description. indirect dependency: A program or library has an indirect dependency on a library, if it does not depend on any interfaces of the library itself, but some intermittent dependency library depends on such an interface. needed-following linker: A system with a needed-following linker has a means to record dependencies on other libraries within a library (based on the soname of the dependency library), and a linker that uses this information to load dependent libraries. Solaris and Linux are examples of this, [ prominent counter-example ]. [ Do I have to define soname? Should I use a different word? ] Before Libtool version 2.2, the handling of inter-library dependencies has ignored the fact that some system linkers are smart enough to figure out the library dependencies of dependent libraries themselves, and always linked in all dependencies into the output. This has lead to subtle problems on such systems when dependent libraries are recompiled against different versions of its dependencies. Multiple versions of a library may be linked in the same output, resulting in a broken link. [ insert example from Scott ] On the other hand, on systems without a needed-following linker, it is necessary to explicitly list all dependent libraries. Libtool is smart enough to find these dependencies itself if all dependent libraries are libtool libraries (i.e., with accompanying .la files). Since this is often not the case, portable linking needs to specify these indirect dependencies. In order to allow to distinguish direct and indirect dependencies, `libtool --mode=link' has two options, `-direct-deplibs' and `-indirect-deplibs'. The semantics are as follows: - If none of these options are given, all libraries listed on the command line are treated as direct dependencies. - The options can be given as often as necessary and hold for the following arguments. - All dependencies picked up from libtool libraries (.la files) are treated as indirect dependencies. - If a library is mentioned (or picked up) as both direct and indirect, it is treated as direct dependency. - On systems with needed-following linker, all direct dependencies are encoded in the output. On all other systems, all [ non-system? ] dependencies are encoded in the output. [ TODO: Insert example here ] On systems with needed-following linker, users are frequently tempted to not include indirect dependencies in the link line at all. Be warned, however, that this is not portable, because it will generally fail on other systems. Only if your direct dependencies are guaranteed to be libtool libraries (.la files), e.g. because they are built as part of your software package as well, does omitting their indirect dependencies work on such systems. Example: [ maybe it's not such a good example ] libltdl.la depends on libdlloader.la, libdlloader.la may depend on libdld, depending on the system. Since both libltdl.la and libdlloader.la are built within the same package and thus guaranteed to both be libtool libraries, it is ok to omit `-ldld' from the link line of libltdl.la. Open questions: - Is it possible to find out in all cases which things actually mean the same library? - Is it necessary for the previous question to be answered yes? Also on systems without needed-following linker? - Is this really backwards-compatible? I think so, libtool-1.5 and newer seem to ignore `-indirect-deplibs' and `-direct-deplibs'. - Can it be implemented with reasonable effort? ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: RFC: proposal for indirect deplibs
* Thien-Thi Nguyen wrote on Wed, Nov 24, 2004 at 11:53:25AM CET:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
>[definitions]
>
> my head is already swimming because "dependent", "dependency" and
> "dependence" all are very subtly different and have different
> meanings in different contexts.
OK. Let's clean this up.
> i like the term "upstream" and "downstream" because a moment's
> thought in comparison w/ the real-world (physical) motion of water
> shows what is upstream affects what is downstream, but not the
> other way around.
>
> unfortunately, i have no suggestion on how to adapt these terms to
> things that are mutually-dependent.
Let's see. The analogy to a class hierarchy fits somehow (with the
exception of mutual dependency). So, what about:
- base library
- derived library (one that depends on `base')
- mutual dependent libraries (I was hoping I could avoid this term).
- direct vs. indirect base library
example: libA -> { libB, libC }, libB -> { libC, libD }
then libD is indirect base of libA, and libC direct base of libA.
Conversely, libA is directly derived from libB and libC, and
indirectly derived from libD.
Does that make more sense? A rewritten draft, amended by a few more
examples, is at the end of this mail.
> as for the rest of the text, IIUC you are proposing a way to
> explicitly distguish direct from indirect. how about also
> distiguishing between "fatal-indirect" and "non-fatal-indirect"?
> (i presume lack of direct is always fatal.)
What exactly do you mean with these terms? (I have a vague idea
but would rather like to know a precise definition.)
I am trying to allow
- libraries to have as few dependencies as possible
- while still being portable to all kinds of systems.
The advantage of the former is only felt on systems like linux or
solaris (and then only with shared libraries, of course).
Since it is in general impossible to find out which library dependencies
are directly or indirectly derived by looking at the source
Thanks for your feedback!
Regards,
Ralf
Libtool and inter-library dependencies
==
Definitions:
direct base library:
A program or library has a direct base library, if it depends on some
interface that base provides, see node Interfaces for a more thorough
description.
Example:
If you use cos() in your program or library, then libm is a direct
base library, and your program/library is directly derived from it.
indirect base library:
A program or library has an indirect base library, if it does
not depend on any interfaces of the library itself, but some
base library of the program depends on such an interface.
Example:
A program makes no use of any math routines itself, but uses a library
libalgorithms, which uses the cos() function. Then libm will be a
indirect base library of the program, but a direct library of
libalgorithms. Conversely, libalgorithm is directly derived from libm,
but your program is indirectly derived from libm.
needed-following linker:
A system with a needed-following linker has a means to record
dependencies on other libraries within a library (based on the soname of
the dependency library), and a linker that uses this information to load
all base libraries. Solaris and Linux are examples of this,
[ prominent counter-example ].
[ Do I have to define soname? Should I use a different word? ]
Before Libtool version 2.2, the handling of inter-library dependencies
has ignored the fact that some system linkers are smart enough to figure
out the base libraries of base libraries (recursively) themselves, and
always linked in all base libraries into the output.
This has lead to subtle problems on such systems when base libraries are
recompiled against different versions of its bases. Multiple versions
of a library may be linked in the same output, resulting in a broken
link.
[ insert example from Scott ]
On the other hand, on systems without a needed-following linker, it is
necessary to explicitly list all base libraries, direct as well as
indirect. Libtool is smart enough to find all base libraries of libtool
libraries. But often, base libraries are not produces by libtool on
such systems. So portable linking needs to specify these indirect
base libraries.
In order to allow to distinguish direct and indirect base libraries,
`libtool --mode=link' has two options, `-direct-deplibs' and
`-indirect-deplibs'. The semantics are as follows:
- If none of these options are given, all libraries listed on the
command line are treated as direct bases.
- The options can be given as often as necessary and hold for the
following arguments (thus, order is important).
- All bases picked up from libtool libraries (i.e., the information
found in the dependency_libs variable in .la files) are treated as
Re: Trying to run 2.1a test suite
* Jeff Squyres wrote on Wed, Nov 24, 2004 at 02:18:14PM CET:
> Ah -- excellent! I think someone said this ("work in the branch-2-0
> branch"), but I ignored it and worked on the trunk because I foolishly
> assumed that they were effectively the same
We are in the process of rewriting the testsuite.
That's what caused it to temporarily not work.
> (note to self: your own
> development practices are not the same as everyone else's! ;-) ).
Depends on whether you can do everything yourself or divide up the work
areas cleanly between developers or not. Things only break when doing
large, invasive changes. (With a little luck, this breakage will be
gone after just a couple more of Gary's patches).
Regards,
Ralf
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
FYI: Patches for Portland Group (aka "pgi") compiler support
* Jeff Squyres wrote on Wed, Nov 24, 2004 at 02:31:26PM CET:
> (I figured I'd start this in a different thread so that it would be
> easy to find when searching; the patches are identical to what I
> submitted before, but in the interest of tying this all up in one
> thread...)
Good idea.
> I've attached 2 patches to libtool.m4 -- one for branch-1-5 and one for
> branch-2-0 -- that add support for the Portland Group pgcc, pgCC, and
> pgf77 compilers to Libtool. Both pass their respective test suites.
> The 2-0 patch ended its test suite with:
>
>
> All 115 tests passed
>
Thank you very much for testing.
I've checked in the following, slightly different patch (the C++ and F77
drivers don't name-collide with `pentium gcc', those were named pg++ and
pg77 respectively), adding ChangeLog, THANKS and NEWS entries.
The patch below is against branch-2-0, the ones against HEAD and
branch-1-5 are analogously derived from Jeff's patches.
Cheers,
Ralf
2004-11-24 Jeff Squyres <[EMAIL PROTECTED]>
* m4/libtool.m4 [linux] (_LT_COMPILER_PIC, _LT_LINKER_SHLIBS,
_LT_LANG_CXX_CONFIG), NEWS, THANKS: Support for Portland Group
(aka "pgi") compilers.
Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.168.2.9
diff -u -r1.168.2.9 NEWS
--- NEWS22 Nov 2004 21:22:12 - 1.168.2.9
+++ NEWS24 Nov 2004 14:43:35 -
@@ -1,6 +1,7 @@
NEWS - list of user-visible changes between releases of GNU Libtool
New in 1.9h: 2004-??-??; CVS version 1.9g, Libtool team:
+* Support for Portland Group compiler on Linux.
New in 1.9f: 2004-10-23; CVS version 1.9e, Libtool team:
* Calculate dllsearchpath correctly for wrapper scripts on cygwin.
Index: THANKS
===
RCS file: /cvsroot/libtool/libtool/THANKS,v
retrieving revision 1.36.2.1
diff -u -r1.36.2.1 THANKS
--- THANKS 22 Oct 2004 07:15:30 - 1.36.2.1
+++ THANKS 24 Nov 2004 14:43:35 -
@@ -75,6 +75,7 @@
Frank Ch. Eigler [EMAIL PROTECTED]
H.J. Lu [EMAIL PROTECTED]
Ian Lance Taylor [EMAIL PROTECTED]
+ Jeff Squyres [EMAIL PROTECTED]
Joel N. Weber II [EMAIL PROTECTED]
Joseph Beckenbach III[EMAIL PROTECTED]
Kenneth Albanowski [EMAIL PROTECTED]
Index: m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.125.2.13
diff -u -r1.125.2.13 libtool.m4
--- m4/libtool.m4 22 Nov 2004 15:53:04 - 1.125.2.13
+++ m4/libtool.m4 24 Nov 2004 14:43:35 -
@@ -3082,6 +3082,12 @@
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
+ pgCC)
+ # Portland Group C++ compiler
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
+ ;;
cxx)
# Compaq C++
# Make sure the PIC flag is empty. It appears that all Alpha
@@ -3329,6 +3335,13 @@
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
+ pgcc | pgf77 | pgf90)
+# Portland Group compilers (*not* the Pentium gcc compiler,
+ # which looks to be a dead project)
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
+;;
ccc*)
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
# All Alpha code is PIC.
@@ -3599,7 +3612,12 @@
linux*|tpf*)
if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null;
then
-_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs
$compiler_flags ${wl}-soname $wl$soname -o $lib'
+tmp_archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags
${wl}-soname $wl$soname -o $lib'
+ # Portland Group f77 and f90 compilers require an additonal -fpic
+ if test "$CC" = "pgf77" -o "$CC" = "pgf90"; then
+ tmp_archive_cmds="$tmp_archive_cmds -fpic"
+fi
+ _LT_TAGVAR(archive_cmds, $1)="$tmp_archive_cmds"
case `$LD -v 2>&1` in
*\ [01].* | *\ 2.[[0-9]].* | *\ 2.10.*) ;; # catch versions < 2.11
*\ 2.11.93.0.2\ *) supports_anon_versioning=yes ;; # RH7.3 ...
@@ -5100,6 +5118,14 @@
_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
_LT_TAGVAR(whole_archive_flag_spec,
$1)='${wl}--whole-archive$convenience ${wl}--no-whole-archive'
;;
+ pgCC)
+# Portland Group C++ compiler
+_LT_TAGVAR(archive_c
Re: Relocatable libraries with libtool--can I do it?
* Paul Smith wrote on Thu, Nov 25, 2004 at 01:18:48AM CET: > Hi all. I'm having a severe problem with libtool-ized packages, of > which there are more and more these days, in my environment. I'm > wondering if anyone here can suggest how I should proceed; whether > there's something in libtool that will help me, or whether libtool needs > enhancements, or what. Libtool probably needs a little enhancement and some bugfixing. > My environment involves running in an x86 host running Linux, and > cross-compiling everything for a different target. A few extra things > about this are (a) that we do not use chroot or any similar technology, > and (b) the entire thing needs to be completely relocatable at any > time. Only one question for now (I don't know enough about the problem space yet), concerning notation: _Relocatable_ IMHO is a package which can be installed (literally copied to) in /usr or /usr/local without any difference. You do not really need *relocatable* libraries, right? You only do staged installs (by using DESTDIR), and all you ever move around is the staging area. The place where the library will find itself at the time it is used by ld.so is fixed from the very beginning, right? This is a significant simplification and required from libtool's point of view. Can we agree on this notion of relocation and staging? It corresponds to what the Autotools manuals use. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: RFC: proposal for indirect deplibs
Hi Scott, everybody else, * Scott James Remnant wrote on Fri, Nov 26, 2004 at 07:32:39AM CET: > On Wed, 2004-11-24 at 10:19 +0100, Ralf Wildenhues wrote: > > > needed-following linker: > > A system with a needed-following linker has a means to record > > dependencies on other libraries within a library (based on the soname of > > the dependency library), and a linker that uses this information to load > > dependent libraries. Solaris and Linux are examples of this, [ > > prominent counter-example ]. > > > I always consider Solaris the prominent counter-example, though my > information may be out of date. Can you demonstrate which versions of > Solaris do and don't have link-loaders that follow NEEDED? > > It may be that they fixed it, but didn't add appropriate NEEDEDs to some > of their shipped libraries. We'll need to take this into account if > that's the case. Actually, I don't have a clue about Solaris, I merely thought I saw a statement to that extent somewhere. I'll go and check. > > This has lead to subtle problems on such systems when dependent > > libraries are recompiled against different versions of its dependencies. > > Multiple versions of a library may be linked in the same output, > > resulting in a broken link. > > [ insert example from Scott ] > > > Generally it's not a "multiple versions may be linked" problem, because > you have that exact same problem when you don't link them all. They > still both get loaded into the address space. ACK. Thanks for mentioning this (Bob also did this before). > The problem is when you have a SONAME change in a low-level library > (such as libpng) in a very large stack (such as GNOME or KDE). The > low-level library is only being used by the libraries that link it, yet > you have to recompile the entire desktop environment to move to the new > library as everything directly linked it. > > By only linking the actually declared dependencies, you only need > recompile the libraries that declare dependencies on libpng itself. ACK. Thanks everybody else for the numerous comments. I think I should have some time this weekend to address most of the ideas and post an updated RFC. Generally, I agree with the notion that only one label per relationship may not be sufficient, also thinking about Bob's comments convinced me that it's necessary to go the most conservative default route (i.e., unless library packages actively change their configuration, libtool will do the same as before). I was hoping to be able to avoid different notions of API- and ABI-compatibility, and I think that should be possible by using a very strict notion of indirect derivation only. Independent of this, I regard this topic as quite undecided, and would only push for advancing libtool in that direction if we can reach a consensus about this. Stay tuned, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: real short TODO summary
* Peter O'Gorman wrote on Sat, Nov 27, 2004 at 04:14:46PM CET: > > Support dlmopen dladdr1 and dlinfo in libltdl [I totally disagree with > this one Ralf, libltdl is a portability library, none of these functions > enhance portability in any way] Just throw this out then! I just mentioned them because I saw them. BTW, I still think dlinfo could maybe help resolve the `cross compile on linux problem' in part, mentioned in Daniel Reed's RFC (and part of this problem in libtool is linux-specific). But I have not looked at it yet. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: RFC: proposal for indirect deplibs
* Albert Chin wrote on Fri, Nov 26, 2004 at 10:09:31PM CET: > On Wed, Nov 24, 2004 at 10:19:44AM +0100, Ralf Wildenhues wrote: > > Before Libtool version 2.2, the handling of inter-library > > dependencies has ignored the fact that some system linkers are smart > > enough to figure out the library dependencies of dependent libraries > > themselves, and always linked in all dependencies into the output. *snip* > > So, if we do what you want, libtool behaves different depending on the > platform. As in: On systems without shared libraries, it links statically instead of shared. Difference between platforms: Update derived objects after every change instead of after every interface change. Or in: On systems without dlopen mechanism, libltdl emulates it using dlpreopen. Difference between platforms: similar as above. My proposal: On systems with "smart linker": for every interface change, only update the set of libraries and programs exposed to this change. (That is, if we can come up with a sane set of semantics.) > Is that really what we want? I don't know. Convince me to the contrary. To me, the idea does not look out of line. If libtool really were to implement the same semantics on all platforms, it'd have to do static linking only. Well, you don't need libtool for that. (Yes, I've probably been the only person in years trying to actually use libtool on a static-only platform). What's more, there is precedence here: Debian's libtool makes use of link_all_deplibs=no. I would like something much more conservative than this overall trust in library authors, but something better than having libtool guess what ultimatively cannot be guessed. Actually, I also believe that it's a good thing to support the enhanced features that a GNU system (which GNU libtool is part of) can offer, if (and only if) we can support them in a portable, backward-compatible and smoothly-declining (does this word make sense?) fashion. E.g., I'd like versioned symbols as well, but they seem to be impossible to realize while fulfilling the last mentioned property. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: RFC: proposal for indirect deplibs
* Gary V. Vaughan wrote on Sat, Nov 27, 2004 at 07:47:35PM CET: > Ralf Wildenhues wrote: > >* Albert Chin wrote on Fri, Nov 26, 2004 at 10:09:31PM CET: > > > >My proposal: On systems with "smart linker": for every interface > >change, only update the set of libraries and programs exposed to > >this change. (That is, if we can come up with a sane set of > >semantics.) > > I'm right behind you for this one, and think that it would be a huge > value add for libtool-2.2 -- as long as we heed the caveats pointed > out by Bob. OK. > >What's more, there is precedence here: Debian's libtool makes use of > >link_all_deplibs=no. I would like something much more conservative > >than this overall trust in library authors, but something better > >than having libtool guess what ultimatively cannot be guessed. > > s/precedence/precedent/ (prod me if you hate having your grammar > corrected, like wot I do, and I'll stop it) On the contrary. See below. > >Actually, I also believe that it's a good thing to support the > >enhanced features that a GNU system (which GNU libtool is part of) > >can offer, if (and only if) we can support them in a portable, > >backward-compatible and smoothly-declining (does this word make > >sense?) fashion. E.g., I'd like versioned symbols as well, but > >they seem to be impossible to realize while fulfilling the last > >mentioned property. > > "degrading gracefully" is the term I have always used. Thanks a lot. I sat here for minutes trying to think of this expression. Literally. And after I couldn't get any helpful clues from dict.leo.org, I reckoned I'd just send it anyway, people will understand. But yes, I do very much appreciate being corrected for language/spelling and stuff. How else should I get rid of my mistakes? > Open Source > is almost always an evolutionary process, so we can only take it one > step at a time... best of all, if we step out of line, it is usually > easy to get back on track and try again with something else :-) ACK. And it's all been words so far only, I won't think of implementation until afterwards (can you tell I'm not a physicist?). You know what: I think I did it. I got static linux-dietlibc working here, except for some minor details. Took long, found ugly bugs, hate the fact that I was not stubborn enough to apply the libltdl `clean parsing' patch back then. Will have to wait until tomorrow, though, booze is waiting. Cheers, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: another 1.5 release
* Daniel Reed wrote on Fri, Dec 03, 2004 at 12:36:24AM CET: > On 2004-11-30T11:31-0500, Daniel Reed wrote: > ) for multilib to be made available in branch-1-5 (possibly by incorporating > ) .multilib2 into 1.5.12). > > It's looking like I may be able to get current Libtool into the final RHEL 4 > release. Great! How much time do you have left? > Is there any chance .multilib2 can be incorporated into 1.5.12? As written, > it simply causes libtool to ask gcc to find .la files if gcc is in use. It > should have no impact on non-gcc builds and should not cause any files to be > missed (the original behavior is used if gcc is unable to find a requested > file). The general idea looks fine to me. Unless other libtool distro maintainers disagree, I'd like to see this in branch-1-5 (and then in branch-2-0 and HEAD as well). Technical issues with the patch: - Why is, after your patch, $found set twice before searching (is there a reason for this)? - You search -print-file-name with all extensions before searching other paths with all extensions. I think this is ok, but am not totally convinced. - What about other compilers on linux? I know icc knows -print-file-name= in version >= 8.0 (but, depending on whether it sees the option `-no-gcc' or not, it will be detected as gcc anyways). I'm pretty sure pgi compilers do not understand this switch. Regards, Ralf -- I'll not be reading mail regularly for the next few days. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: another 1.5 release
* Scott James Remnant wrote on Fri, Dec 03, 2004 at 10:06:01AM CET: > On Thu, 2004-12-02 at 18:36 -0500, Daniel Reed wrote: > > > Is there any chance .multilib2 can be incorporated into 1.5.12? As written, > > it simply causes libtool to ask gcc to find .la files if gcc is in use. It > > should have no impact on non-gcc builds and should not cause any files to be > > missed (the original behavior is used if gcc is unable to find a requested > > file). > > > Do you have a copy of the patch to be considered? I think it's http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00123.html at least that's the one I was referring to. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: portland compiler, convenience libraries and templates
* Markus Christen wrote on Thu, Dec 02, 2004 at 07:24:23PM CET: > Markus Christen wrote: > > >problem: > >linking a program to a library (shared or static) built from a > >convenience library fails if the convenience library contains template > >functions : unresolved reference. > > (of course when using the portland compiler ;-) > > anyway, already some follow-up: > > what needs to be done is using > --one_instantiation_per_object > for all .cc files in the libraries, then before building the final > library, do a > pgCC --one_instantiation_per_object --prelink-objects $CXXFLAGS $LDFLAGS *.o > on all objects. > this will create additional object files in a directory Template.dir It may be necessary to also specify the directory with --template-dir .. > then, when building the library, all the additional object files need to > be added as well > ar cru normal objects, convenience libraries Template.dir/*.o > > [ > if i ar cru ' d the convenient library objects from Template.dir/ into > the convenience library, and then only added the rest to the real > library, i still get unresolved references... > ] I don't understand this. Can you explain by showing what you meant with this? > if i do this manually, the prog compiles. Same issue. > if anybody could put this into something that libtool can do > (automatically) (maybe with writing some automake hooks or whatever?), i > would be glad... If nobody beats me to it, I will look into this sometime next week. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
RFC: indirect deplibs v2
I haven't come as far as I would have liked (rpath discussion is very incomplete still), and I won't be responding for the next couple of days, but here's my current version of the RFC (pasted info plus texinfo source attached) for you to tear apart. Thanks for all your valuable input so far, more feedback greatly appreciated. Regards, Ralf 10 Inter-library dependencies * First, we define a set of terms to use later. A program or library has a "direct base library", if it depends on some interface that base provides (see *Note Interfaces:: for a more thorough description). If you use `cos' in your program or library, then `libm' is a direct base library, and your program or library is directly derived from it. The program or library depending on the base library will be called "derived program or library", or short "derived object". (1) An object has an "indirect base library", if it does not depend on any interfaces of the library itself, but some base library of the object depends on such an interface. A program makes no use of any math routines itself, but uses a library `libalgorithms', which uses the `cos' function. Then `libm' will be a indirect base library of the program, but a direct library of `libalgorithms'. Conversely, `libalgorithm' is directly derived from `libm', but your program is indirectly derived from `libm'. A library "exposes a base library" if it possibly causes a derived library or program to rely on an interface of that base. In example above, if `libalgorithms' is to be used with a header file `algorithms.h', which contains `#define mathop(angle) cos(angle)' then the algorithms library exposes the math library. In general, the notion of exposure is not detectable automatically. The following guide can be given: Whenever library headers require exposing external interfaces to sources of derived objects, for example because they require inclusion of base library headers or include these headers themselves, the base library should be considered exposed to derived code. These are not the only possibilities, however. A system with a "needed-following linker" has a means to record both dependencies on other libraries based on the soname of the base library, and rpaths in which those other libraries are to be searched. It also has a linker that picks up both the soname as well as the rpath information to load all base libraries at runtime. For example, the Linux linker does all of this. (2) (3) Before Libtool version 2.2, the handling of inter-library dependencies has ignored the fact that some system linkers are smart enough to figure out the base libraries of base libraries (recursively) themselves, and always linked in all base libraries into the output. Whenever a lowlevel library changes its interface (soname), this requires recompiling of all derived objects. If most of the derived objects do not make use of the lowlevel interfaces in any way, this is suboptimal on systems with a needed-following linker. It should suffice to recompile the directly derived objects (which itself do not change their interface). On systems without needed-following linker, recompilation of all derived objects is necessary. In order to allow for portable linking using libtool, there are a few flags which can be added to the link line in order to specify the dependency information: The available options are `-exposed-libs', `-private-libs', `-direct-libs' and `-indirect-libs'. These options behave like two types of switches and hold for the base libraries listed to the right of the option, until encounter of another switch of the same type. Libtool and calculates from the information given on the command line together with the information gathered from base libraries two sets: A set of libraries to be directly linked to, and a set of libraries which are considered exposed to derived objects. These sets are then recorded in the output. (4) Speaking in terms of the directed, generally not acyclic, graph underlying inter-library dependencies: library dependency corresponds to reachability along a path, direct dependency corresponds to a path of length one, and exposure is an edge attribute. The notion of a "valid graph" then imposes certain connectivity conditions when inserting new vertices (which corresponds to creating derived object), namely: directed paths of length two require a shortcut if the second edge of the path has the exposure attribute. (5) The semantics are as follows: * If none of the options are specified on the command line, all base libraries are considered direct and exposed. Similarly, all bases picked up from unadorned libtool libraries (i.e., the information found in `.la' files lacking exposure or directness information) are treated as direct, exposed base libraries. (6) * The switches can be given
Re: another 1.5 release
* Bob Friesenhahn wrote on Sat, Dec 04, 2004 at 12:18:47AM CET: > On Sat, 4 Dec 2004, Peter O'Gorman wrote: > >Bob Friesenhahn wrote: > > > >>Profound changes like this should not be introduced in a bug-fix branch. > > > >So do you think it is okay for HEAD? I think Daniel would at least have > >something to say to QA if it were applied to HEAD. It would also allow for > >some testing before being backported to a release branch. > > It is certainly much safer and wiser to make such changes to HEAD. > It supports proving that the changes don't break for GCC users on > other platforms without placing a stable release branch at risk. The > reason for stable release branches is so that minor releases may be > made without requiring re-testing the software on all supported > platforms. The 2.0 branch has not yet produced a release so it is > still feasable to alter a feature although our focus needs to be to > get 2.0 out the door since it has been gestating for over a year. > > I believe that we should adhere to Albert Chin's advice that compiler > feature tests should be restricted to libtool.m4. OK, how 'bout this: We make a new config variable `shlibpath_cmd', determined in libtool.m4 (_LT_LINKER_SHLIBS) to be either empty or invoke the tag-dependent compiler to find the file in its path. This will then be used in ltmain the way Daniel proposes. For HEAD, we can try to set shlibpath_cmd on as many systems as possible, and for branch-1-5, we either - propose for him to use a patch only enabling this for gnu-linux/gcc - or also integrate this restricted patch into branch-1-5 ourselves. For branch-2-0, let's see. Issues I'm not sure with yet: Do we have to worry about unnormalized paths? Example: $ gcc -print-file-name=libc.so.6 /lib/../lib64/libc.so.6 $ gcc -print-file-name=libxml2.la /usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64/libxml2.la Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
multilib2 patch (was: another 1.5 release)
* Daniel Reed wrote on Fri, Dec 03, 2004 at 05:20:36PM CET: > On 2004-12-03T08:33+0100, Ralf Wildenhues wrote: > > ) Technical issues with the patch: > ) - Why is, after your patch, $found set twice before searching (is there a > ) reason for this)? > > Libtool seems to use the state "$found = no" (the literal check "$found != > yes") for the dual use of failure and success with non-Libtool library. I > added a third state of "$found = unknown" to mean failure "so far" in the > search and kept "$found = no" to mean its original meaning. Libtool never > checks for "$found = no", only "$found != yes", so this should not cause a > behavior change outside of the search code. After a little testing.. ..maybe it's not the right way to do it after all.. :( Setup: I have a custom-built gcc in a nonstandard directory on a x86_64 with linux (fedora core 3). `g++' iself is 64bit (which shouldn't matter at all), but it should be able to produce 32 and 64 bit code.[1] Before as well as after your change, the first part of the search algorithm finds the libstdc++.la which belongs to the 32bit version and shortcuts your second part. Linking tests/tagdemo/libfoo.la fails happily. I *can* get it to work if I put the -print-file-name stuff at the beginning of the search.. This needs further testing (besides putting the actual -print-file-name logic into libtool.m4), I fear. Help wanted. Regards, Ralf [1] The fact that it's a development version shouldn't matter in this regard, I think. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: debugging/developing libraries, library is installed under the same name in 2 different version
* Hebenstreit Michael wrote on Thu, Dec 09, 2004 at 10:37:20AM CET: > > I a problem and hope you can help me. I tried to debug a kde/korganizer > library in my home-dir, having installed the same package on the (linux) > system. This leads to the following situation > > standard library: /opt/kde/lib/libkcal.so.2.0.0 > > library with debug > information: /home/heb/temp/kde-pim-3.3.1/lbkcal/.libs/libkcal.so.2.0.0 > > programm to be > debuged: /home/heb/temp/kde-pim-3.3.1/korganizer/.libs/lt-korganizer > > According to the output of libtool at compile/link-time > /home/heb/temp/kde-pim-3.3.1/korganizer/.libs/lt-korganizer > is linked to the correct library > /home/heb/temp/kde-pim-3.3.1/lbkcal/.libs/libkcal.so.2.0.0 > > (even the "--rpath" statements are included). > > Unfortunetly the "ldd" has "/opt/kde3/libs" first in line, and during > run-time > uses /opt/kde/lib/libkcal.so.2.0.0 Helpful information (please use copy and paste) includes the - system used (OS, hardware, distribution) - link line and produced output (`libtool --mode=link...') $ objdump -p .libs/lt-korganizer $ ldd .libs/lt-korganizer $ ldd .libs/libcal.so > The easiest way to prevent this is to generate a link > > /home/heb/temp/kde-pim-3.3.1/korganizer/.libs/libkcal.so -> > /home/heb/temp/kde-pim-3.3.1/lbkcal/.libs/libkcal.so.2.0.0 > > focing the ldd to take the correct library. No, what you did should Just Work[tm]. > Is there a simple way to use automake/libtool to circumvent this problem? > > libtool used: > - > ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19) Hmm, this is a development release, and a quite old one. Did you build this yourself, or is there a software distributor who packs this into a release? Can you perchance try again with either released 1.5.10 or unreleased current branch-2-0? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: make distcheck
* Bill Moseley wrote on Thu, Dec 09, 2004 at 08:21:27PM CET: > Could someone explain what these are telling me -- and more > importantly, if they are indication of a problem? > > [EMAIL PROTECTED]:~/swish-e$ make distcheck >/dev/null > libtool: install: warning: remember to run `libtool --finish > /home/moseley/swish-e/swish-e-2.4.3/_inst/lib' > libtool: install: warning: `libswish-e.la' has not been installed in > `/home/moseley/swish-e/swish-e-2.4.3/_inst/lib' A dependent library (of the library or program being installed) has not been installed yet. This occurs when using -dry-run or installing multiple libraries in the wrong order. In the latter case, it poses a potential problem since the first to-be-installed library might be relinked against the old installed dependent library (if an old installation was present). > BTW - This isn't about libtool, but one odd thing that happens once in a > while is "make distcheck" will sometimes abort and leave a bunch of > read-only files so that subsequent "make distcheck" runs fail. Do other > people experience the same thing? As Bob already noted, installing multiple libraries in the correct order is an Automake/Libtool problem not yet adressed. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: 2 non-libtool libs want to start
* Ross Boylan wrote on Thu, Dec 09, 2004 at 09:22:34PM CET: > I have two libraries, both of which want to be the one that starts. I > assume they both define main, though I have not verified that. Both are > 3rd party, non-libtool, libraries. The C `main' function is defined in these libraries? Please verify this (use nm or objdump or whatever libtool uses as $NM). I really don't know if this works portably. > First, I'd like to verify that libtool can work with non-libtool > librariers. The docs seem to imply that. Yes, that should generally work. > Second, is there any kind of general help libtool can offer for this > problem? On Linux, fiddling with the order of the libraries on the link > line was adequate to control which one got control. I am porting to > Apple's OS-X, and have not been so fortunate there. Could you be more specific? What did you do and what happened? The best thing would be to provide a small test example. We could put that in libtool's test suite and let exposure show if it works on other platforms. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool --silent based on MAKEFLAGS?
Hi Martin,
* Martin Waitz wrote on Fri, Dec 10, 2004 at 02:50:42PM CET:
>
> next request:
>
> could libtool take a look at MAKEFLAGS and automatically use --silent
> mode when 's' is included in the make flags?
That sounds like a good idea -- in principle.
> At the moment I'm unconditionally using libtool --silent to make
> 'make -s' usable. It would be nicer if libtool would handle that
> automatically.
>
> An alternative would be to implement short options (make -s an alias
> to --silent and ignore all other short options) and use
> 'libtool -$(MAKEFLAGS)', but I don't really like that.
Nope. MAKEFLAGS can have more than one possible format (either the
options like given on the command line, or just the letters
corresponding to those options) according to XSI. GNU Make does the
latter and also adds possible long options and other variable settings
afterwards, so we want to treat that correctly as well.
I'm not sure how to reliably distinguish between both forms without any
forking. But here's a try with just a subshell.
Because the user has to be able to override this, we now need an option
to undo this. And we need to adjust some tests to use this, because
they check the output of libtool.
Two things I'm unsure about:
- whether `-v|--verbose' was or is in use w.r.t libtool. Should I
use that rather than --no-silent?
- interaction between `-n|--dry-run' and silence.
Should --dry-run imply --no-silent?
(One could imagine just trying to syntax-check with --dry-run
--silent; in some future version of libtool).
OK to apply (to HEAD only, this is a new feature)?
Are there any packages that rely on the old behavior?
Regards,
Ralf
* config/ltmain.m4sh (func_make_s): New function to detect
`make -s'. Use before parsing the command line so that new
option `--no-silent' can override it.
* NEWS, doc/libtool.texi (Invoking libtool): Mention it.
* tests/link.test, tests/link-2.test, tests/objectlist.test,
tests/quote.test: Adjust to use --no-silent so `make -s check'
does the right thing.
Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.175
diff -u -r1.175 NEWS
--- NEWS29 Nov 2004 21:18:26 - 1.175
+++ NEWS10 Dec 2004 16:36:09 -
@@ -6,6 +6,7 @@
* Fix libltdl on static platforms.
* Support for linux-dietlibc (`diet' as well as `diet-dyn', separately).
* Shell optimizations which break use of the stdin file descriptor in libtool.
+* libtool now honors `make -s' (MAKEFLAGS). Use --no-silent to override.
New in 1.9h: 2004-??-??; CVS version 1.9g, Libtool team:
* Libtool versions can now be parallel installed, except that only one
Index: config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v
retrieving revision 1.34
diff -u -r1.34 ltmain.m4sh
--- config/ltmain.m4sh 9 Dec 2004 17:59:15 - 1.34
+++ config/ltmain.m4sh 10 Dec 2004 16:36:09 -
@@ -38,6 +38,7 @@
# --mode=MODE use operation mode MODE
# --preserve-dup-deps don't remove duplicate dependency libraries
# --quiet, --silentdon't print informational messages
+# --no-silent print informational messages (default)
# --tag=TAGuse configuration variables from tag TAG
# --versionprint version information
# -h, --help print short or long help message
@@ -393,6 +394,24 @@
exit $EXIT_SUCCESS
}
+func_make_silent ()
+{
+ ( has_s=false
+ set x $MAKEFLAGS
+ case $2 in
+s* | [^-]*s* ) # single-letter options within the first word (eg. GNU Make)
+has_s=:
+;;
+ esac
+ case $MAKEFLAGS in
+-s | *\ -s | -s\ * | *\ -s\ * ) # hyphenated options (eg. BSD Make)
+has_s=:
+;;
+ esac
+ $has_s ) && opt_silent=:
+ : # work around bash bug
+}
+
# Parse options once, thoroughly. This comes as soon as possible in
# the script to make things like `libtool --version' happen quickly.
{
@@ -427,6 +446,8 @@
;;
esac
+ func_make_silent # set first to allow cmdline override
+
# Parse non-mode specific arguments:
while test "$#" -gt 0; do
opt="$1"
@@ -479,6 +500,10 @@
opt_silent=:
;;
+ --no-silent) preserve_args="$preserve_args $opt"
+ opt_silent=false
+ ;;
+
--tag) test "$#" -eq 0 && func_missing_arg "$opt" && break
preserve_args="$preserve_args $opt $1"
func_enable_tag "$1"# tagname is set here
Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.185
diff -u -r1.185 libtool.texi
--- doc/libtool.texi23 Nov 2004 09:37:06 - 1.185
+++ doc/li
Re: documentation comments
Hi Ross, First, thanks for your reports (and also your long reply to my deplibs RFC; I'm afraid I won't have too much time working on that for a while, but eventually someone will get to it). * Ross Boylan wrote on Thu, Dec 09, 2004 at 11:02:06PM CET: > It would be good if the documentation (I'm looking at 1.5.6.) were > clearer on the setup of libtool and its requirements. In previous > discussion on this list, I've learned that autoconf is required. I've > just discovered a little more is necessary too (at least install-sh, > which can be produced by automake). automake should not be required. This is a bug, I think. I don't know if I can attack this right away, please don't hesitate to ping us again in a couple of weeks on this issue if we forget to look at it. > Also, it could be clearer that you don't actually distribute a libtool > with your package, but have it generated on the build machine by > configure. In particular, I found this confusing: > > 5.3 Configuring libtool > === > *snip quoted content* > - > "when you distribute libtool with your own packages" meant, to me, that > the file libtool would be part of my package. The line 'libtool must be > "configured" before it can be used' also suggested there was some file > that configure acted upon, rather than one that it created. The > statement that "Libtool adds its own tests to your 'configure' script" > similarly suggests that libtool exists before configure (I realize this > is sort of true, though it applies to the maintainer machine). Good point! How do you like this instead: 5.3 Configuring libtool === Libtool requires intimate knowledge of your compiler suite and operating system in order to be able to create shared libraries and link against them properly. When you install the libtool distribution, a system-specific libtool script is installed into your binary directory. However, it is also possible to set up your software package in such a way that everything required for libtool to work is distributed along with it (*note Distributing::). In this case, it is not the `libtool' script which is distributed along with your package, but the machinery to generate this script for the operating system and compiler used to compile your package eventually, since now the knowledge for all compiler suites and all operating systems needs to be wrapped up. This machinery reuses the GNU "configure" approach: `configure' runs a number of tests for system features, then generates the `Makefile's (and possibly a `config.h' header file), after which you can run `make' and build the package. For libtool, a few more tests are added to your `configure' script in order to generate a libtool script for the installer's host machine. The generation of the `libtool' script then happens as well at the end of the `configure' run. Is that any clearer? > Now, back to the issue of required programs and packages. > > Documentation section 5.4, Including libtool in your package, > lists a bunch of required files, and recommends running libtoolize. (It > also does say not to include libtool itself). Having done all this, I > put the project on a new system and ran configure. It failed because > install-sh was absent. We need a testcase for this. And a fix. > So at least that file is necessary. I did >automake --foreign --add-missing > which added 3 files (though I did get some complaints from it). Things > then worked. This should not be necessary. I think. > Finally, section 5.1, Writing `Makefile' rules for libtool, does say "If > you want to use libtool in a regular `Makefile' (or `Makefile.in'), you > are on your own." Since I am trying to use libtool without automake, > this could be taken as a general warning and disclaimer. Even if that > was the intent, it would be nice to add the information mentioned above > for those who aren't using automake. I would like to address this in a separate mail, sometime later, ok? Maybe together with the other bug you mentioned above. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: predep_objects & postdep_objects with Intel 8.1
[ slightly reordered ] * Gary Kumfert wrote on Fri, Dec 17, 2004 at 12:17:17AM CET: > On Thu, 16 Dec 2004, Gary Kumfert wrote: > > > > I'm tracking down an issue between Intel 8.1 and libtool 1.5.10. > > It seems that libtool adds and crtbeginS.o crtendS.o files to > > the link line for shared libraries... then icpc does the same.. > > then ld complains about multiply defined symbols! Eeek! Wait.. > > Shouldn't libtool (or libtool.m4) detect these object files > > already appear in the link line and not add them directly? hmm > > Interestingly libtool (correctly) does not insert crtbeginS.o and > > crtendS.o into shared library link lines with icc or ifort. > > Why icpc? hmm. What does $ ./libtool --config | grep with_gcc say? > > Here's some of the differences in what Intel 7.0, 8.0, and 8.1 > > pass to ld. Note that the differences between 8.0 and 8.1 seem > > to be significant! In particular 8.1 seems to use GNU's crtbeginS.o and > > crtendS.o. 7.0 & 8.0 seems to rely on intel's crtxi.o and crtxn.o files > > instead. I believe it's even more complicated than that. It might also depend on how ICC was installed -- whether to its provided or GNU libstdc++, and whether the latter was found by ICC at installation time (maybe that's what you are seeing). I haven't had a chance to look how Libtool fares with all of this. (BTW, multi-file interprocedural optimization and template libraries provide more opportunity for failure, feel free to go wild if you have time to look at this and cure possible problems. :-) > > I admit that I don't really understand what low-level linker trickery > > these files accomplish. (A pointer to some literature would be helpful.) Runtime initialization and termination for the library/program given. No, I can't give you a good answer on this, but there are bits of information to be found in the gcc and ld manuals (info files), and http://en.tldp.org/HOWTO/Program-Library-HOWTO/miscellaneous.html#INIT-AND-CLEANUP http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl17?a=view and links therein are quite informative. If you'd like to see how complicate this stuff can get, browsing around http://www.lnf.infn.it/computing/doc/aixcxx/html/complink/concepts/cushrlib.htm is fun. > I think I found the problem. When I upgraded with libtoolize. > "libtoolize -f -c" it copied things like config.guess, config.sub, > and ltmain.sh correctly into my AC_CONFIG_AUX_DIR. > > But, it did *not* update my libtool.m4 in AC_CONFIG_MACRO_DIR. > After copying by hand, I saw that indeed the version of icpc is > checked and different flags are selected. Does that mean all your other problems above are gone now? I haven't looked at them yet because of this statement. > Wasn't libtoolize supposed to update the libtool.m4 file? I'll leave this question for somebody else to answer. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: link_all_deplibs=yes
* Albert Chin wrote on Fri, Dec 10, 2004 at 10:55:14PM CET: > >From config/ltmain.m4sh (applies to 1.5 as well): > ... *snip* > ... > > Why enforce this only when $linkmode=prog? Why shouldn't the deplibs > additions in the above apply when creating libraries? > > I'm trying to build kde-3.3.1 on AIX 5.2 and because deplibs isn't > added to link when $linkmode=prog, library linking is failing with > unresolved symbols (because the dependency libs from dependent .la > files aren't being included in the command-line). In released non-patched Libtool, there is no scenario or system in which link_all_deplibs is set to `no'. I think everybody pretty much agrees that the current implementation of link_all_deplibs in libtool is not very smart and leads to problems (as you had to find out the hard way). That is one reason I started writing the deplibs RFC: To get rid of link_all_deplibs and replace it with something sensible. What was your question again? Who patched your Libtool? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool --silent based on MAKEFLAGS?
* Peter O'Gorman wrote on Sun, Dec 12, 2004 at 02:29:30PM CET: > Ralf Wildenhues wrote: > > | So, how about this? Let's have Automake include $(LIBTOOLFLAGS) in > | their libtool invocation. The user can then use > | LIBTOOLFLAGS=--silent > | > | What do you think? > > Forgetting the rest of you mail for the moment, why involve automake? Is it > a bad idea to have libtool look for a LIBTOOLFLAGS environment variable? IMHO yes. From libtool's point of view, there's nothing needed besides the command line. Other build tools can easily add support for this as well. One additional bonus is you don't have to worry about precedence -- it's the job of the tool calling libtool. Just my opinion (and by no means set in stone). Regards, Ralf (please remember the rest of my mail eventually) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: When/why did FC become an unsupported tag ???
Hi Gary, * Gary Kumfert wrote on Sat, Dec 18, 2004 at 01:23:06AM CET: > > My configuration needs C, C++, Java, Python, F77, and F90 > (called "FC"). Wow! > Why did support for FC disappear from libtool.m4 in my > "upgrade" from 1.5.4 to 1.5.10? Erm. Support for Python and FC has, to the best of my knowledge, never been part of official libtool releases (you are not by chance speaking about Automake?). Did you used some distro-patched versions before? It would surely be a huge win to support these languages, however, so such patches would be most welcome with me! Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool convenience library on x86_64
* Bill Jones wrote on Mon, Dec 20, 2004 at 08:59:40PM CET: > I am trying to link a shared library against a libtool convenience > library on an AMD opteron with libtool 1.5.10, automake 1.9, autoconf > 2.59, and gcc-3.2.2 (SuSE Linux). If I use the normal method, that > works fine under RedHat on Intel x86 (32 bit) and MinGW, I get the > following error when linking my shared library: > > relocation R_X86_64_32 can not be used when making a shared object; > recompile with -fPIC > > If I explicitly specify the "-fPIC" flag as part of my convenience > library CFLAGS and rebuild it, then all links fine. My concern here is > if some later compiler does not support "-fPIC". I am counting on > libtool to figure this stuff out for me. Sure. Something like --with-pic could serve as bad temporary workaround. > I have read Daniel Reed's posting to [EMAIL PROTECTED] entitled "disable > nopic on x86_64 and s390* (was: Re: GNU Libtool 1.5.8 released.)" and it > looks like you simply turned off this test. Is this to be actually > fixed at some point? Is there a work around for using libtool > convenience libraries in building shared libtool libraries? D*mn, you're right, we didn't fix the problem, just the symptoms. Hehe, looking back, there was this discussion where, IIRC, Alexandre Oliva fought against setting deplibs_check_method to pass_all for linux. It's actually wrong to do so, and we have to fix this. Please remind us in a couple of weeks if we haven't fixed this, it's kind of an intricate issue, and probably needs some discussion (plus, right now everyone seems to be short of time). Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: OSF versioning and large current/revision/age
Hi Tim,
* Tim Mooney wrote on Sun, Dec 19, 2004 at 06:55:18PM CET:
>
> I just built atk-1.9.0 (part of gtk+) on Friday, and ran into an issue
> with versioning that's making me wonder what kind of problems we may
> encounter in the future.
>
> Atk's ABI hasn't changed in quite a while, and because of the way it (and
> many other GNU/GNOME packages) increments library versioning, the shared
> library is created (by libtool) with a libtool invokation that includes:
>
> -version-info 900:0:900
>
> First, based on inspection of ltmain.in (from 1.5.10), it looks like
> libtool doesn't currently handle current/revision/age values with four
> or more digits. That's probably going to be a problem for projects like
> atk.
Yep.
Does anybody know whether using four-digit version numbers is portable
(or, to put the other way round: was there a technical reason for three
digits)? As this impacts every system libtool supports, this has very
far-reaching implications. A survey would be necessary before changing
this.
> Second, on platforms that use OSF-style versioning, that -version-info
> argument results in a library creation command line that's almost 11K in
> length; 90% or more of that command line length relates to the
>
> test -n "900.900.0:0.0:1.0:.:899.0:900.0" && \
> -set_version 900.900.0:0.0:1.0:.:899.0:900.0
>
> This results in an IVERSION field in the shared library that's more than
> 5K in length. At least on Tru64 (I'm not sure about other platforms
> that use OSF-like versioning, such as IRIX) that's not a problem for the
> loader or the executable itself, but it is excessive. ;-)
Yep.
> Rainer Orth had a good overview of osf versioning vis-à-vis libtool in a
> message to the list a couple years ago:
>
> http://lists.gnu.org/archive/html/libtool/2002-06/msg00027.html
>
> There was a short thread a couple months later, relating to his patch
> waiting to be applied:
>
> http://lists.gnu.org/archive/html/libtool/2002-08/msg00044.html
>
> At the end of that thread, I asked a question that seems to be relevant
> again (still): Why is libtool using both SONAME-style versioning *and*
> internal versioning, for platforms like Tru64 and IRIX?
Erm, changing this would break compatibility.
The best we could do would be to make this a Libtool option.
But other than that, offering the other way looks like a decent idea,
the discussions you mention do not seem to imply otherwise.
> Does anyone have any recollection of why that decision was made?
I'll leave this..
> The archives are silent about it. I also don't understand why a ".0"
> is being appended to each and every interface ( ${iface} ) that's part
> of $verstring.
..and this for someone more knowledgeable than me to answer.
> In any case, I generally espouse following a particular UNIX flavor's
> conventions for building and installing software, but in the particular
> case of libtool and osf-style versioning, I've long been concerned that
> we might be heading for trouble. libtool's concepts of current, age,
> interface, et. al. don't mesh particularly well with IVERSION-style
> versioning, IMHO.
>
> I'm considering patching libtool so that it *optionally* uses *just*
> soname versioning, similar to Solaris. That way, the person that's
> actually building software with libtool can decide if they want libtool to
> use the IVERSION field and the soname, or just soname.
If the other maintainers agree, we might adopt this.
> I've only partially been following the thread about libtool and MAKEFLAGS,
> but it looks like there's a possibility of some kind of $(LIBTOOLFLAGS) that
> could be passed to libtool on the command line to control other optional
> behavior. I had been considering an environment variable that libtool
> would check and parse, but if other optional behavior control is going to
> be via command-line flags, it would seem best if my patch piggybacked on
> that work.
No, I don't think this is a sensible way to go. IMVHO it would seem
much more appropriate to add a new option to LT_INIT and maybe as well
provide this as a configuration option (not sure about the latter).
Comments appreciated.
Regards,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: unrecognized option `--tag=CC'
Hi pete, * pete wrote on Tue, Jan 04, 2005 at 01:46:41AM CET: > Can someone please tell me why I keep getting this error? > libtool: unrecognized option `--tag=CC' Unreproducable here. > What info do you need? An example command line including full output. > libtool --version > ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: unrecognized option `--tag=CC'
[ reordered for readability ] * pete wrote on Tue, Jan 04, 2005 at 01:05:24PM CET: > On Tue, 2005-01-04 at 10:42 +0100, Ralf Wildenhues wrote: > > * pete wrote on Tue, Jan 04, 2005 at 01:46:41AM CET: > > > Can someone please tell me why I keep getting this error? > > > libtool: unrecognized option `--tag=CC' > > > > Unreproducable here. Shame on me for this typo. :( > > > What info do you need? > > > > An example command line including full output. > > /bin/sh ../libtool --mode=link --tag=CC gcc -O2 -g -Wall -o irrecord > irrecord.o dump_config.o config_file.o hw-types.o ir_remote.o > hw_default.o receive.o transmit.o > libtool: unrecognized option `--tag=CC' > Try `libtool --help' for more information. (These few lines would've been sufficient information, BTW.) In your first message, you wrote: > > > libtool --version > > > ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) This is your system's installed libtool script, whereas the package you compiled uses its own provided libtool script (which is created during configure). Please show the version of that -- it's likely much older. As your build also shows (I've deleted that because I could've guessed it), the automatic rebuilding rules call `automake' again, which is likely much newer than the shipped ltmain.sh. Automake creates the rules that contain `--tag', and the old libtool does not understand this. Solution is to either not change the files of the package (so autoconf and automake are not triggered), or use AM_MAINTAINER_MODE to prevent this, or to libtoolize again, update the m4 macros (in aclocal.m4) and then autoreconf. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: unrecognized option `--tag=CC'
Hi Alexandre, * Alexandre Duret-Lutz wrote on Tue, Jan 04, 2005 at 03:24:48PM CET: > On Tue, Jan 04, 2005 at 02:10:14PM +0100, Ralf Wildenhues wrote: > > > > As your build also shows (I've deleted that because I could've guessed > > it), the automatic rebuilding rules call `automake' again, which is > > likely much newer than the shipped ltmain.sh. Automake creates the > > rules that contain `--tag', > > Automake outputs --tag only if the libtool.m4 file used supports them. > So this indicates mismatch between libtool.m4 and ltmain.sh. Yes, you're right. I did not mean to blame Automake, just try to explain what happens. Apparently not too well. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: unrecognized option `--tag=CC'
* pete stagman wrote on Tue, Jan 04, 2005 at 07:12:28PM CET: > > I'm at work now but will try it when i get home. > > >From here I downloaded the package and extracted it. The ltmain.sh file > contained: > # Constants. > PROGRAM=ltmain.sh > PACKAGE=libtool > VERSION=1.4.3 > TIMESTAMP=" (1.922.2.111 2002/10/23 02:54:36)" > > So if I just do a > ./configure > make > won't that create the same libtool and the same error? No. `make' should not cause automake nor autoconf nor libtoolite to be called (unless you modified some source files, for example configure.in). Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: unrecognized option `--tag=CC'
Please don't reply above quotes -- thank you. * pete wrote on Tue, Jan 04, 2005 at 11:11:48PM CET: > On Tue, 2005-01-04 at 20:00 +0100, Ralf Wildenhues wrote: > > * pete stagman wrote on Tue, Jan 04, 2005 at 07:12:28PM CET: > > > > > > >From here I downloaded the package and extracted it. The ltmain.sh file > > > contained: *snip* > > > So if I just do a > > > ./configure > > > make > > > won't that create the same libtool and the same error? > > > > No. `make' should not cause automake nor autoconf nor libtoolite to be > > called (unless you modified some source files, for example > > configure.in). > > removed directories, untarred package, ran the script > Still get the same error, I looked through the script to see if it > changes any files, it renames a bunch and moves the directories, but it > doesn't look like it edits the configure.in or anything. Please notify the package author about the broken setup. As a workaround, you can update ltmain.sh by running libtoolize with the appropriate options for the package before starting the script (your bugreport shows that the libtool m4 macros are updated by aclocal, so you don't have to deal with that). Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: whole_archive/-r
Hi Christopher, * Christopher Mason wrote on Tue, Dec 21, 2004 at 05:12:00PM CET: > > Two questions: I haven't fully grokked the issue regarding your first question. Hope somebody beats me to it.. Your second question consist of several questions: > 2) Is there a way to stop libtool from doing -nostdlib nastiness? In general it's necessary to avoid nuplicate symbols. (I think.) > Or indeed from hard coding library paths in general? In general it's necessary to avoid that, when executed, your program will work (i.e., use the right libraries linked to, and find them at all). > (It seems to sometimes change my -lfoo into .../foo.so and sometimes > not; I assume this is related to not being able to include static libs > in .so's, but I can I turn it off on sane platforms)? This doesn't > work well when doing -m32 on 64 bit platforms; it hard codes the link > paths for the 64 bit libraries, when if it just passed -lfoo > everything would "just work." This is a different problem. Take a look at sys_lib_search_path_spec, those paths are not hardcoded into the output (because the linker will look there by default). You have most likely been hit by a problem which shows up much on multiarch platforms: libtool fails to sanitize paths before comparing: E.g, linking against /usr/lib/libfoo.la will work without the path hardcoded, but against /usr/lib/../lib64/libfoo.la will fail. We need to fix this. The implications are not too easy to oversee, however, and quite a bit of code in libtool is impacted. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: on SunOS "grep -e" fails
Hi Elmar, * Elmar Rudigier wrote on Thu, Jan 13, 2005 at 03:31:22PM CET: > > Using libtool on SunOS causes a lot of masseages like: > Usage: grep -hblcnsviw pattern file . . . > grep: illegal option -- e > grep: illegal option -- L > grep: illegal option -- / > grep: illegal option -- o > grep: illegal option -- p I'm quite surprised to see this. > It seems, that libtools is expecting GNU grep. No. > On SunOS grep, which is installed in /usr/bin, doesn't accept the option > '-e'. But there is another grep installed on the system (in /usr/xpg4/bin), > which accept this option. > > Maybe it's possible to check if which grep accepts this option? That should already be done (i.e., the xpg4 version should be chosen automagically). > [EMAIL PROTECTED] sauxy2 557$ uname -a > SunOS sauxy2 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Fire-280R > [EMAIL PROTECTED] sauxy2 558$ libtool --version > ltmain.sh (GNU libtool) 1.5.2 (1.1220.2.60 2004/01/25 12:25:08) Please update to at least 1.5.10 and report whether the problem is fixed. If not so: how can I easily reproduce this problem? Which Autoconf version do you use? If <2.54, try to see if the problem goes away after upgrading to a newer Autoconf (if that is possible). In any case, if the problem persists after Libtool upgrade, I'd like to see a shell trace of a libtool run where this happens (`libtool --debug' or `$CONFIG_SHELL -x libtool'). Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: on SunOS "grep -e" fails
* Bob Friesenhahn wrote on Thu, Jan 13, 2005 at 04:53:43PM CET:
> On Thu, 13 Jan 2005, Ralf Wildenhues wrote:
> >
> >>On SunOS grep, which is installed in /usr/bin, doesn't accept the option
> >>'-e'. But there is another grep installed on the system (in
> >>/usr/xpg4/bin),
> >>which accept this option.
> >>
> >>Maybe it's possible to check if which grep accepts this option?
> >
> >That should already be done (i.e., the xpg4 version should be chosen
> >automagically).
>
> The xpg4 version is not in the Solaris default path, therefore, it is
> unlikely to be noticed by autoconf.
Well, new enough Autoconf checks for {,e,f}grep in /usr/xpg4/bin as
well, and checks for -e and acceptance of long lines. But I failed to
see that this check is in 2.59b only, not 2.54.
(I checked this now on a Solaris machine :)
Is there an easy way to replace AC_PROG_EGREP with a better version in
libtool.m4 iff Autoconf's version is not good enough?
We can hardly force Libtool users to Autoconf 2.59b.
I don't think we can fix all calls to {,e,f}grep and $EGREP, because
some of the arguments are user input (but I only checked briefly).
Elmar wrote that a Libtool update fixed this, but I still think that
together with old Automake this failure could possibly show up
somewhere.
Regards,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: partial linking
[ reply to two bug reports ] Hi Andreas and ÐÑÑÐÐÑÑÐÐÐ, I hope that is the right way to address you (this is the first time I use cut'n'paste with UTF-8 proper, plus I can barely decipher cyrillic). * ÐÑÑÐÐÑÑÐÐÐ ÐÑÐÐ ÐÐÐÑÑ wrote on Thu, Jan 13, 2005 at 01:48:06PM CET: > > Am I right, that there is no way to pass additional linker flags when > doing partial linking? Yes, as of now. Consider it a bug. > I try > ./libtool --mode=link g++ -Xlinker - -o a.o b.o > > And anyway it produces > ld -r -o a.o b.o > > Btw, it doesn't show "-Xlinker", "-XCClinker" and "-Wl," options in > help screen when invoking > libtool --help --mode=link Another bug. * Andreas Fenkart wrote on Sun, Jan 09, 2005 at 01:36:39AM CET: > > I have a question regarding partial linking. I found a thread earlier on > this list, namely here. > > http://lists.gnu.org/archive/html/libtool/2004-12/msg00249.html > > Unfortunately there was no answer on doing partial linking the right way. > The answer given suggests adding dummy functions and reference them from > elsewhere in the code. That's exactly what I try to avoid. > > This is what I do > $(LIBTOOL) --mode=link g++ -o $(OBJDIR)/intermediate.lo/\ > $(OBJS:.o=.lo) > $(LIBTOOL) --mode=link g++ -o $(LIBDIR)/$(LA_LIBFILENAME) \ > -rpath $(INSTALLLIB_DIR) \ > $(OBJDIR)/intermediate.lo > > Unfortunately this fails, because the intermediate.lo is not a textfile > describing where the PIC object is found, but the PIC object itself. No > object is placed into the .libs directory, which libtool usually does when > building *.lo files. Another bug in libtool. > I read the code(libtool-1.5.10) and I'm willing to add the necessary bits to > create a proper .lo file. (Basically just copy-paste from the compile-case). > I'm just asking myself if the current behavior is on purpose, or an > oversight. > Anybody out here who can tell me how partial linking was thought to be used > in the first place. If you ask me, intermediate.lo file should be a text file, and intermediate.o and $objdir/intermediate.o the two partially linked objects. If you have time: Patches to all these bugs are very welcome. If you decide to patch against branch-1-5, however, I would very much like to also see a forward port to branch-2-0/HEAD (the latter two are very similar). Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Cray X1 port
Hi Gary, * Gary Kedziora wrote on Thu, Jan 13, 2005 at 11:38:55PM CET: > > Has anybody attempted a port to the X1? I guess not, but unless UNICOS has changed much recently, all that should be needed would be to add a _LT_TAGVAR(ld_shlibs, $1)=no under some suitable $host_os pattern matching (branch-2-0/HEAD notation) to libtool.m4. Actually, no is the default. If you have access to a X1, you can run the Libtool testsuite and report FAILures here (rerun them with VERBOSE=x). If you have some knowledge about it (even pointers to docs are good!), tell it here, or even better, read info '(libtool.info)Information sources' and then fill in the necessary bits into libtool.m4 and ltdl.m4. What's not working? Is it maybe just config.guess that needs an update (what does it print?). It's late (read my mail backwards for the right order of things). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
FYI: libtool.m4 correction
Hi Guido, * Guido Draheim wrote on Fri, Jan 14, 2005 at 04:54:27AM CET: > # Add /usr/xpg4/bin/sed as it is typically found on Solaris > # along with /bin/sed that truncates output. > for lt_ac_sed in $lt_ac_sed_list /usr/xpg4/bin/sed; do > - test ! -f $lt_ac_sed && break > + test ! -f $lt_ac_sed && continue >cat /dev/null > conftest.in >lt_ac_count=0 > > On one of my build hosts the loop will break before > any good sed is being found even that there is one > good sed later in the path. The current cvs version > will break if any directory item in $PATH does not > contain an sed candidate. Well, only if as_executable_p is nonfunctional in the loop before the one you posted, and your Autoconf is not new enough to have AC_PROG_SED. Of course, the former is our failure to use it correctly, and the latter just hides the bug for many users. > > rpm -q libtool > libtool-1.5.8-3 > > savannah cvsweb shows the same line. Longstanding? Sure, I guess most Libtool developers use quite modern Autoconf, so this macro is not used by them at all. Thanks for your report. I've checked in the following patch against all three branches. Regards, Ralf 2005-01-14 Guido Draheim <[EMAIL PROTECTED]> (tiny change) * m4/libtool.m4 (AC_PROG_SED): Don't break test loop early. Index: m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v retrieving revision 1.153 diff -u -r1.153 libtool.m4 --- m4/libtool.m4 12 Jan 2005 12:57:32 - 1.153 +++ m4/libtool.m4 14 Jan 2005 09:19:30 - @@ -5970,7 +5970,7 @@ # Add /usr/xpg4/bin/sed as it is typically found on Solaris # along with /bin/sed that truncates output. for lt_ac_sed in $lt_ac_sed_list /usr/xpg4/bin/sed; do - test ! -f $lt_ac_sed && break + test ! -f $lt_ac_sed && continue cat /dev/null > conftest.in lt_ac_count=0 $ECHO $ECHO_N "0123456789$ECHO_C" >conftest.in ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: link_all_deplibs
Hi Christoph, * Christoph Wellner wrote on Fri, Jan 14, 2005 at 04:07:21PM CET: > > i have trouble starting my application since I get undefined references. > As source I determined the variable "link_all_deplibs_CXX" wich is > explicitly set to 'no' in libtool.m4. > I'm running libtool-1.5.6 under debian Sarge and the problem is, that the > libtool.m4-file is different from the one that comes with the > libtool-distribution from the homepage. Yes. Debian is AFAIK the only distribution that ever sets link_all_deplibs to no on linux. > My question is, can I set the value of "link_all_deplibs_CXX" by hand, eg > as option in the commandline? You can either change `libtool.m4' and/or whereever the package you are talking about stores its m4 macros then rebuild the package or you can change generated `libtool' -- look for all instances of link_all_deplibs=yes and set them to `unknown' or `no' (one at the beginning and several ones at the end, one for each language -- search for ### BEGIN LIBTOOL TAG CONFIG: CXX ). You could also tell us what specific problem you have encountered, so we can warn against it or help you (the Debian maintainer usually reads this list as well :) or maybe just fix the package you are trying to build. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: link_all_deplibs
Hi Christoph, * Christoph Wellner wrote on Sat, Jan 15, 2005 at 01:11:37PM CET: > On Fri, 14 Jan 2005 16:26:22 +0100, Ralf Wildenhues > <[EMAIL PROTECTED]> wrote: > >* Christoph Wellner wrote on Fri, Jan 14, 2005 at 04:07:21PM CET: > >> > >>i have trouble starting my application since I get undefined references. > >>As source I determined the variable "link_all_deplibs_CXX" wich is > >>explicitly set to 'no' in libtool.m4. > >>I'm running libtool-1.5.6 under debian Sarge and the problem is, that > >>the > >>libtool.m4-file is different from the one that comes with the > >>libtool-distribution from the homepage. *snip* > > well, I think the problem is on my side. The problem is the following: > I habe libraries libA and libB and my application app. app uses functions > from libA and libB, and libA uses functions from libB. So I linked libA > against libB and my app against libA. This worked fine, but now I get > undefined references, unless I also link libB against app. If you install libA as libtool library (i.e., libA.la is installed as well), then this should work. libA.la should contain the information that it depends on libB, that is, if you supplied that at the time of creating libA.la. Even if libtool does not state it in its documentation as of now: If your application directly uses libB (as opposed only through the use of libA), then you should list libB in the application's link line as well. Even if only for documentation purposes. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 2 and dsohowto's comments?
Hi Peter, * Peter O'Gorman wrote on Sat, Jan 15, 2005 at 01:40:54PM CET: > Ralf Wildenhues wrote: > > > >But current Libtool does use -version-script on linux if ld supports > >it.. > > I just noticed this check in libtool.m4 while looking for something else. I > think that it should also be used for ELF based *bsd when using GNU ld, > shouldn't it? I guess so. Can you be bothered to hack up a patch? What about other systems with GNU ld? > Sorry for awakening a really old thread :) No problem. I still wished for a stable way to index old messages better, though. lists.gnu.org's indexing has changed before, its URLs can't be inferred by Message-ID alone (I'd really like that!), on the other hand I'd consistently work with a bug-tracking system only if it is possible to work by mail alone. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: link_all_deplibs
* Christoph Wellner wrote on Mon, Jan 17, 2005 at 11:31:39AM CET: > On Fri, 14 Jan 2005 16:26:22 +0100, Ralf Wildenhues > <[EMAIL PROTECTED]> wrote: > > > >You could also tell us what specific problem you have encountered, so we > >can warn against it or help you (the Debian maintainer usually reads > >this list as well :) or maybe just fix the package you are trying to > >build. > > can I set the link_all_deplibs-variable by command-line? eg with --tag? > Because patching system-wide libtool-files is not really an alternative ;) > We don't want to tell the users, who are using our software , that they > first have to patch libtool.m4 in order to biuld our code. No, you can't. But you can fix that easily in your software, just as I have described in the other message. If you are unsure, show how libA, libB, and program are built. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: link_all_deplibs
Christoph, * Christoph Wellner wrote on Mon, Jan 17, 2005 at 03:38:42PM CET: > > Well, libA.la contains the information that it depends on libB. But I > still get the linker-error. > > Perhaps it is important, that the libs are not 'installed' but stil in the > directory-tree of our source-code. \ > > Just to make myself clear: > compiling and the linking after the compile works. but when I want to > start the application, it claims about missing librariy libB, wich is > definately build and part of our package. ldd says in the 1st line, that > it can't find libB, but in the 2nd line, it says, that libB is located in > directory xy. So, it seems, that the linker finds the lib correctly, but > does not update the paths. This is all not helpful. Please read[1]. Please provide a small recipe how we can reproduce what you are doing, or at least post the rules you use to create your libraries and programs, i.e., Makefile or Makefile.am snippets. Your description lacks way to much information -- post real information, cut and paste rather than copy by hand, be concise, report your system (you have only revealed the operating system, not the architecture), read [1] again, cut and paste the *exact* commands that fail, together with their output. Regards, Ralf [1] http://www.lecb.ncifcrf.gov/~toms/bugs.html ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Install of libtool module on AIX 4.2 does not work.
Hi Gary,
* Gary Kumfert wrote on Sat, Jan 15, 2005 at 02:04:55AM CET:
>
> There aren't two types of shared libraries... there's shared
> and there's dynamic (or "run time linked" in AIX speak. hence -brtl.)
This I can mostly agree with.
> Even then, the switch doesn't *really* care about the type... just the
> suffix in the filesystem. (Below is an exercise I just did
> to confirm this.)
This I must respectfully disagree with. See below.
> The bigger issue in Peter's question, I thought was:
> why should he (or me, or my customers for that matter) have to know
> to configure with "LDFLAGS=-brtl" in the first place?
> The point of libtool is to hide such platform-specific details.
I would love to simplify things here -- and in any way, I see the need
to either do that or at least update Libtool documentation on the joys
encountered on AIX, so the user knows what to do.
> (I concede that its not easy since AIX has a unique mapping of
> the 3 linkage concepts [static, shared, dynamic] onto the two
> file suffices [*.a, *.so]. OTOH, I suppose IBM figures its a
> novel feature of ELF that all shared libraries can be dynamically
> loaded.)
>
> Requiring LDFLAGS=-brtl at configure time is IMHO a bit
> heavy-handed. In my own build, I don't want -brtl to show up
> *everywhere* only certain places.
> I'd much rather specify it my makefiles using a
> platform-independent libtool option, and let libtool intuit
> that its "-Wl,-brtl" on AIX, and "" elsewhere.
When? Under which circumstances would it make sense?
What does portable software that does this on AIX do
on other systems which do not allow so many choices?
> P.S. For all kinds of nitty-gritty's, I recommend
> http://www.ibm.com/developerworks/eserver/pdfs/aix_ll.pdf
Thank you very much for this pointer.
> P.P.S. Now for the exercise which builds a lib*.a and then renames
> it lib*.so to indicate -brtl really is a filename thing,
> not a library-type issue.
>
> > cat foo1.c
> #include
> foo() {
> printf("foo1\n");
> }
>
> > cat foo2.c
> #include
> foo() {
> printf("foo2\n");
> }
>
> > cat main.c
> int main() {
> foo();
> }
>
> > xlc -g -c foo1.c
> > ar cru libfoo.a foo1.o
> > ranlib libfoo.a
> > mv libfoo.a libfoo.so # if its a type thing, maybe this would upset it?
This comment is misleading.
It's not just the type. It's also the fact that ..
> > xlc -g -c foo2.c
> > ar cru libfoo.a foo2.o
> > ranlib libfoo.a
> > xlc -brtl -o main1 main.c -L. -lfoo # this picks up libfoo.so (foo1.o)
..at this point, foo is bound:
$ dump -HTv main1 | grep foo
$
Just like how you use a static library, and very much unlike shared
linking.
> > xlc -o main2 main.c -L -lfoo # this picks up libfoo.a (foo2.o)
> > ./main1
> foo1
> > ./main2
> foo2
>
> The AIX *convention* is to reserve the *.so suffix for dynamic loaded
> libraries ("run time linkage" in AIX-speak which is probably the
> reason for the flag's name -brtl). It seems intended to apply shared
> linkage to run-time linked libraries. (Which makes sense since in AIX,
> there's also a switch to apply static linkage to otherwise shared
> libraries). Note that if I build libfoo.so the usual way, this also works
>
> > xlc -G -o libfoo.so foo3.o #assume this prints foo3, without me showing
> > code
> > ./main1 # no need to relink main1
> foo3
$ cat >foo3.c
#include
foo() {
printf("foo3\n");
}
int vfoo = 99;
$ xlc -g -c foo3.c
$ xlc -G -o libfoo.so foo3.o
$ ./main1
foo1
Unless you also build libfoo.so with -G resp. -brtl, you do not get the
desired linking behavior. Furthermore, if you create an archive but
defer the linking, the linking above does not only involve the library
name and the symbol, but also the archive member that contains the
symbol.
You have many choices on AIX. Globally using -brtl is too expensive,
else libtool should probably use that.
Maybe all this is just me misunderstanding you. I'd love to be
corrected then. In any case, ideas for improvement on how libtool
handles all this are welcome.
> I didn't bother trying to dlopen a library built with ar.
> We all know what happens there on AIX. ;)
No, I don't. But that doesn't matter much to me.
Regards,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
path normalization
One step toward integrating Linux multilib support, but a Libtool
requirement independent of that goal, is comparison of normalized
paths. In a nutshell, I'd like to be able to decide that
../foo/../lib
../lib
are equal.
Unfortunately, libtool so far has neither required its input to be
normalized nor implemented that normalization itself. Thus, we have
to deal with installed .la files which have unnormalized paths for
ever, thus adding such a requirement as an afterthought is hopeless.
Now I figured we may need to compare all sorts of paths,
- relative or absolute (but maybe not one group against the other)
- existing or not existing.
Thus `pwd -L' or portable approximations thereof won't work in all
cases. If we ever have to compare relative to absolute paths, I
think we can rely on them being present.
This is my first try at a shell function that implements this with
sed (and little overhead in most trivial cases). I'm posting it
because it's not trivial, and I'd like to know about bugs in it or
general comments on this problem (before integrating into Libtool)
or the choices I had to make about normalization, or possible
simplification. The size of the script is partly due to the fact
that we cannot use alternation `\|'.
You'd also do me a favor if you tried this on your system and reported
back any output (it does not output anything if all goes ok) or non-
zero exit status. Your sed may require removing all comments from
the sed script -- filtering the whole thingy through
sed '/^[ ]\{1,\}#/d'
should do the trick (space and tab within [ ]). Please try different
shells as well.
This function keeps trailing slashes on purpose -- an IMHO independent
task. I added necessary shell-sanitize blob for ease of testing.
Thanks for reading this far,
Ralf
--- cut here ---
#! /bin/sh
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
emulate sh
NULLCMD=:
# Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
# is contrary to our usage. Disable this feature.
alias -g '${1+"$@"}'='"$@"'
setopt NO_GLOB_SUBST
elif test -n "${BASH_VERSION+set}${KSH_VERSION+set}" && (set -o posix)
>/dev/null 2>&1; then
set -o posix
fi
BIN_SH=xpg4; export BIN_SH # for Tru64
DUALCASE=1; export DUALCASE # for MKS sh
set -e
for ECHO in "${ECHO-echo}" 'print -r' 'printf %s\n' false
do
if test "`($ECHO '\t') 2>/dev/null || :`" = '\t'; then break; fi
done
: ${SED=sed}
: ${Xsed="$SED -e s,^X,,"}
: ${VERBOSE=false}
# func_path_normalize pathname
# Remove /./ and /../ parts from PATHNAME.
# Do not fork in most of the trivial cases,
# respect the number of consecutive slashes at the beginning,
# DOS drive letters,
# trailing slash,
# absolute and relative paths.
# We do not honor newlines in PATHNAME,
# backslashes are always treated as separators,
# DOS paths may not contain a colon (except for the drive letter).
func_path_normalize ()
{
case $1 in
*[\\/]..* | *[\\/].[\\/]* | *[\\/]. )
func_path_normalize_result=`$ECHO "X$1" | $Xsed -e '
# remove multiple slashes except at beginning
s#\([^\\/]\)\([\\/]\)\{1,\}#\1\2#g
/./
:one
# common case
s#\([^\\/][\\/]\)\.[\\/]#\1#
# at beginning
s#^\([\\/]\{1,\}\)\.[\\/]#\1#
# /. at end
s#\([\\/]\)\.$#\1#
t one
/../
# three cases for path elements:
# foo
# .foo
# ..foo
# where foo is nonempty and may not start with a dot.
# DOS drive letters
/^[A-Za-z]:/ {
:dos
s#^\(..[\\/]\)[^\\/.][^\\/]*[\\/]\.\.#\1#
s#^\(..[\\/]\)\.[^\\/.][^\\/]*[\\/]\.\.#\1#
s#^\(..[\\/]\)\.\.[^\\/]\{1,\}[\\/]\.\.#\1#
t dos
# common case
s#\([^\\/:]\)[\\/][^\\/.][^\\/]*[\\/]\.\.#\1#
s#\([^\\/:]\)[\\/]\.[^\\/.][^\\/]*[\\/]\.\.#\1#
s#\([^\\/:]\)[\\/]\.\.[^\\/]\{1,\}[\\/]\.\.#\1#
t dos
s#^\(..\)[^\\/]\{1,\}[\\/]\.\.[\\/]*$#\1#
# we may have picked up multiple slashes again
s#\([^\\/]\)\([\\/]\)\{1,\}#\1\2#g
b end
}
# common case
:common
s#\([^\\/]\)[\\/][^\\/.][^\\/]*[\\/]\.\.#\1#
s#\([^\\/]\)[\\/]\.[^\\/.][^\\/]*[\\/]\.\.#\1#
s#\([^\\/]\)[\\/]\.\.[^\\/]\{1,\}[\\/]\.\.#\1#
t common
# do not add slashes to the root
:root
s#^\([\\/]\{1,\}\)[^\\/.][^\\/]*[\\/]\.\.[\\/]*$#\1#
s#^\([\\/]\{1,\}\)\.[^\\/.][^\\/]*[\\/]\.\.[\\/]*$#\1#
s#^\([\\/]\{1,\}\)\.\.[^\\/]\{1,\}[\\/]\.\.[\\/]*$#\1#
t root
# root special cases
s#^[^\\/]\{1,\}[\\/]\.\.$#.#
: end
s#^\([\\/]\{1,\}\)\.\{1,2\}$#\1#
'`;;
*) func_path_normalize_result=$1;;
esac
}
# input output (desired)
tests='
/ /
/./
/.. /
Re: link_all_deplibs
Hi Christoph, * Christoph Wellner wrote on Tue, Jan 18, 2005 at 09:46:31AM CET: > On Mon, 17 Jan 2005 16:03:46 +0100, Ralf Wildenhues > <[EMAIL PROTECTED]> wrote: > > >Please provide a small recipe how we can reproduce what you are doing, > >or at least post the rules you use to create your libraries and > >programs, i.e., Makefile or Makefile.am snippets. > > Ok, This is much better! :-) > so when I start my application, I get the following: > > > /home/chwellner/nmm2_sarge/apps/clic/.libs/lt-clic: error while loading > shared libraries: libnmmutils.so.0: cannot open shared object file: No > such file or directory > > ldd says: ldd .libs/lt-clic > ... > libc.so.6 => /lib/tls/libc.so.6 (0x4075d000) > libnmmutils.so.0 => not found > ... > libnmmnetutils.so.0 => not found > libnmmrtp.so.0 => > /home/chwellner/nmm2_sarge/nmm/base/proxy/rtp/.libs/libnmmrtp.so.0 > (0x40893000) > libnmmutils.so.0 => > /home/chwellner/nmm2_sarge/nmm/utils/.libs/libnmmutils.so.0 (0x408d4000) > ... Also interesting would be: objdump -p .libs/lt-clic and objdump -p /path/to/.libs/libmnnbase.so (you can pipe the output through egrep 'PATH|NEEDED' if it's too long for your taste). > The linking-part of the Makefile.am is this (snippet) > $(top_builddir)/nmm/utils/gdparse/libnmmgdparse.la \ > $(top_builddir)/nmm/base/libnmmbase.la \ > $(top_builddir)/nmm/base/graph/libnmmgraphmgr.la \ This is part of clic_LDADD or LIBS, right? > So, clic is linked against libnmmbase. And the Makefile.am of libnmmbase : > $(top_builddir)/nmm/utils/libnmmutils.la \ > $(top_builddir)/nmm/utils/thread/libnmmutilsthread.la \ > $(top_builddir)/nmm/base/registry/libnmmregistry.la \ This is part of libnmmbase_la_LDADD, right? Is libnmmbase a library that will be installed (i.e., is it listed in something like lib_LTLIBRARIES or noinst_LTLIBRARIES)? What about libnmmutils? > So libnmmutils is linked against libnmmbase, wich is linked against the > application clic. > > libnmmbase is linked using this command: > /bin/sh ../../libtool --mode=link g++ -g -O0 -Wall -W -Wpointer-arith > -Wmissing-prototypes -Wwrite-strings -fno-check-new -fexceptions -o > libnmmbase.la -rpath /usr/local/lib/nmm --version-info 0:0:0 connect.lo > ConnectorAcceptor.lo ConnectorAddress.lo Node.lo GenericNode.lo > GenericSourceNode.lo GenericProcessorNode.lo GenericSinkNode.lo > GenericMultiplexerNode.lo GenericDemultiplexerNode.lo > GenericMuxDemuxNode.lo GenericConverterNode.lo GenericFilterNode.lo > Jack.lo InputJack.lo OutputJack.lo StdNamedObject.lo QueuedInputJack.lo > QueuedOutputJack.lo JackGroup.lo ThreadedNode.lo StreamQueue.lo Event.lo > EventDispatcher.lo Message.lo NMMObject.lo CommunicationChannel.lo > OutOfBandChannel.lo InstreamChannel.lo TransportStrategy.lo Interface.lo > InterfaceFactory.lo TSFactory.lo NMMApplication.lo BaseExceptions.lo > ProxyObject.lo ProxyApplication.lo ObjectAcceptor.lo GenericProducer.lo > ReferenceCount.lo ConnectionManager.lo FormatStrategyMap.lo > CompositeStrategy.lo ../../nmm/base/proxy/rtp/libnmmrtp.la > ../../nmm/utils/libnmmutils.la > ../../nmm/utils/thread/libnmmutilsthread.la > ../../nmm/base/registry/libnmmregistry.la > ../../nmm/base/serialize/libnmmserialize.la > ../../nmm/base/serialize/net/libnmmnetstream.la > ../../nmm/base/format/libnmmformat.la > ../../nmm/base/resourcemgr/libnmmresourcemgr.la > ../../nmm/base/memorymgr/libnmmmemorymgr.la > ../../nmm/base/graph/libnmmcompositenode.la > ../../nmm/base/sync/libnmmsync.la > ../../nmm/base/proxy/tcp/libnmmtcp.la > ../../nmm/base/proxy/udp/libnmmudp.la > ../../nmm/interfaces/base/libnmmibase.la > ../../nmm/interfaces/audio/libnmmiaudio.la > ../../nmm/interfaces/net/libnmminet.la > > > and the command for clic: > /bin/sh ../../libtool --mode=link g++ -g -O0 -Wall -W -Wpointer-arith > -Wmissing-prototypes -Wwrite-strings -fno-check-new -fexceptions -o clic > ClicApplication.o ../../nmm/utils/gdparse/libnmmgdparse.la > ../../nmm/base/libnmmbase.la../../nmm/base/graph/libnmmgraphmgr.la > ../../nmm/interfaces/file/libnmmifile.la > ../../nmm/interfaces/base/sync/libnmmisync.la > ../../nmm/interfaces/video/display/libnmmidisplay.la > ../../nmm/base/registry/libnmmregistry.la > ../../nmm/misc/timer/libnmmtimer.la For both of these, I'd very much like to see what libtool makes out of these -- post the output of those commands. To avoid having to ask you again, please add --debug as first
Re: Cray X1 port
Hi Gary, * Gary Kedziora wrote on Tue, Jan 18, 2005 at 10:22:52PM CET: > > Thanks for the help. I'm not sure which config.guess I was using the > other day, but now I had to look for one. I found one in the X1 system > autoconf/share directories that printed out 'craynv-cray-unicosmp2.5.X'. > That is what the available system autoconf says as well. Looks reasonable. > The first make did not work. It had several errors compiling ltdl.c. Please post complete make output. Please also post what configure outputs. If you know how to fix them, feel free to post a patch as well. > I generated a new configure script with autoconf and then tried the > configure and make. Make says that aclocal-1.9 and automake-1.9 are not > available. It seems that the system installed tools are out of date. Both should not be necessary, since you have not (yet) changed the m4 files or configure.ac or Makefile.am. But when that is the case, running ./bootstrap will be the way to recreate the necessary output, and you will have to install Automake (not necessarily version 1.9). > It then attempts to reconfigure and stops again at compiling ltdl.c. > > I find no occurence of cray or unicos in any of the m4 scripts. I'm This is nothing to worry about per se. (From a libtool point of view, Unicos/mk ought to be a really simple system.) > using libtool-1.5.10. Do you think this is a system set-up problem or > does libtool no longer support Cray? I'm new to tinkering with > autoconf, automake, and libtool Just post all compile errors so we can fix them. When we're done with that, let's see how the Libtool testsuite fares, make check will do that -- and make check VERBOSE=x TESTS='test1.test ...' will allow you to selectively rerun the tests that failed with more output. Tests in libtool are grouped, so you might have to rerun them in groups. Also note that since 1.5.10 a few fixes have gone into branch-1-5 of Libtool which fix spurious testsuite failures on static-only systems. I'll point them out when they show up, they're harmless. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Cray X1 port
Sorry, forgot that question last time. > * Gary Kedziora wrote on Tue, Jan 18, 2005 at 10:22:52PM CET: > > > > I'm using libtool-1.5.10. Do you think this is a system set-up > > problem or does libtool no longer support Cray? No, libtool has not intentionally dropped Cray support. Either nobody has ever used it there much, or, much more likely, libtool has worked well enough out of the box for the system. Libtool does make quite some use of the Autoconf Principle[tm] which says that you should test for the features and not keep a table of known systems (which will ever be incomplete). The tabular part of Libtool is because testing for many shared library specialties is one of difficult/impossible/very time-consuming. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: POSIX threds example needed
* zaufi wrote on Wed, Jan 19, 2005 at 06:19:28PM CET: > > I'm trying to use ltdl library in multi-threaded (POSIX threads) environment. > Unfortunately the manual does not supply enough information on that topic. > Can anybody please provide an example code that would load a dynamic library > in MT-safe way. I don't know what libtool version you use. Newer versions do not recommend the contained locking functions any more, because they did not work together with POSIX threads. So plainly, a safe way is to use a lock to wrap all lt_* function calls and data access. For most uses, I would guess this to be sufficient performance-wise. If you need finer control: we might put a new locking implementation in place. But I for one would only look at it if someone clearly showed real-world code which unearthed bottlenecks. If all you need is documentation on how to use POSIX threads, there is lots of decent documentation out on the web. If you have a specific libltdl threads related problem with your code, show example code you have and we'll see. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: path normalization
Hi Gary, * Gary V. Vaughan wrote on Wed, Jan 19, 2005 at 02:10:46PM CET: > Ralf Wildenhues wrote: > > > > This is my first try at a shell function that implements this with > > sed (and little overhead in most trivial cases). I'm posting it > > because it's not trivial, and I'd like to know about bugs in it or > > general comments on this problem (before integrating into Libtool) > > or the choices I had to make about normalization, or possible > > simplification. The size of the script is partly due to the fact > > that we cannot use alternation `\|'. > > The implementation looks fine to me, and works on Good work! > > Tested with: ash-0.3.8, bash-2.05b, pdksh-5.2.14 and zsh-4.1.1, > all using GNU sed 4.0.9. I feared it'd rather be different seds that barf. I did tests with Solaris sed, AIX sed, GNU sed, and all shells I could find on those systems. The comment removal is a requirement for the sed script. > Here are some more ideas: > > 1. We could avoid the normalization step on .la files that are new >enough by checking the version (or for speed adding a new >'pathsnormalized=yes' declaration) to decide whether it was already >done at creation time. Maybe. But don't let youself fool by my test cases -- if most paths fit the "trivial case", it's not slow. But see below. Moreover, as soon as you concatenate paths, you have to redo the normalization anyway, so in general you don't win very much. (Think: cross-compilation. Oh, BTW, just so that nobody ever thinks of it: we will *NEVER* support cross-compilation on Windows. I.e., where build=win, and host!=win.) ..time passes.. D*mn. With a cross-compile build=linux, host=cygwin we might have to deal with stuff like /tmp/stage/C:\usr\local\lib. Puke. > 2. Shipping a script to optionally trawl the filesystem and normalize >installed .la files (and add a pathsnormalized decl) at libtool 'make >install' time would save time for subsequent libtool calls. Eww. One bug in that script and you're doomed forever. You can expect users to have the sources of the package they just compiled and installed, but not to all software on the system. > 3. I wonder how much of the normalization we could do with M4 as the >libtool script is generated? How? m4 sees nothing of the paths, as they are potentially end-user input. 4. Change libtool m4 configury to look harder for a fast shell and for a builtin $ECHO. If we have ash, use it but with builtin printf and not /bin/echo. I did a little test with roughly 4000 entries of /usr/lib/*. Without forks, bash is about a factor 20 slower. Even with /bin/echo, ash is much faster, and even with my test cases which all trigger the sed, the speedup incurred by using ash over bash is noticeable. I.e., it might make sense to look harder for a decent $SHELL/$ECHO combination. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: link_all_deplibs
* Christoph Wellner wrote on Thu, Jan 20, 2005 at 02:08:28PM CET: > *snip* > > I attached the files you requested. Thanks. Can you do a favor for me: add -Xlinker --no-add-needed to LDFLAGS on build, i.e., run path/to/configure [OPTIONS] with the options you used before, then use make LDFLAGS='-Xlinker --no-add-needed' to build. If you still have your old build tree, it should suffice to just remove all .la files like this find $top_builddir -name \*.la | xargs rm and then issue the make line, no need to rebuild all objects. (Of course, now the workaround I mentioned should _not_ be in place.) What happens now? Does clic start? The objdump outputs are interesting again. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: link_all_deplibs
* Ralf Wildenhues wrote on Fri, Jan 21, 2005 at 03:10:34PM CET: > * Christoph Wellner wrote on Thu, Jan 20, 2005 at 02:08:28PM CET: ... > Thanks. Can you do a favor for me: add > -Xlinker --no-add-needed > to LDFLAGS on build Never mind. Debian's binutils does not support that option yet. Question for everybody: the linker adds a library to DT_NEEDED which is not mentioned in the link command line. It is found as DT_NEEDED entry in a dependent library (it does not add to the DT_RPATH). Does anybody know exactly when ld does that? Is there a concise document regarding this or does one have to resort to the source code? ld.info is definitely not very enlightening on this issue. Debian with its link_all_deplibs=no will have to work around this issue. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: partial linking
* Bob Friesenhahn wrote on Thu, Jan 13, 2005 at 07:03:35PM CET: > On Thu, 13 Jan 2005, Ralf Wildenhues wrote: > > >>Am I right, that there is no way to pass additional linker flags when > >>doing partial linking? > > > >Yes, as of now. Consider it a bug. > > Is partial linking a documented libtool feature? If not, how can > failure to support partial linking be considered a bug? Well, it is (as was already reported). > Unless libtool can portably support a feature, or there at least can > be a fallback to producing software that runs, then it should not be > supported as a libtool feature. Well, to be honest, I don't know too much about how portable that is. And in any case, it's a Libtool documentation bug to only mention partial linking in 3 lines and be done with it -- no limitations, no explanation of what it does. At least we should warn against it if it is not usable or portable. I investigated a little bit: - every system I checked which has shared objects also has `ld -r' (but exact semantics may vary), even static-only systems have it. - it's not portable to do for neither PIC nor non-PIC objects. - C++ might be a problem. More info appreciated. As I see it, we should probably just warn against it and recommend convenience libraries. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Missing symbols using Intel's compiler
* Bob Friesenhahn wrote on Sun, Jan 23, 2005 at 05:16:03PM CET: > On Sun, 23 Jan 2005, Simon Perreault wrote: > > > >I am using libtool+automake+autoconf to build my library. Everything builds > >fine without warnings or errors and I end up with a nice shared library. > >However, that library is missing stdc++ symbols: > > In order to automatically obtain stdc++ symbols, the library must be > linked using a C++ compiler. It won't work to compile with CC=gcc Right. And the Intel C++ compiler driver is called icpc, not icc. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: fallback-echo, finding a suitable $ECHO
* Ralf Wildenhues wrote on Thu, Jan 27, 2005 at 09:39:46AM CET:
>
> I have attached a small script, and encourage
> people to test it on all their shells they can find on their systems.
> It should reveal at least one working echo, and, in most cases, find
> builtins to do the job.
and here it is..
#! /bin/sh
# Be Bourne compatible
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
emulate sh
NULLCMD=:
# Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
# is contrary to our usage. Disable this feature.
alias -g '${1+"$@"}'='"$@"'
setopt NO_GLOB_SUBST
elif test -n "${BASH_VERSION+set}${KSH_VERSION+set}" && (set -o posix)
>/dev/null 2>&1; then
set -o posix
fi
BIN_SH=xpg4; export BIN_SH # for Tru64
DUALCASE=1; export DUALCASE # for MKS sh
: ${lt_ECHO=echo}
func_fallback_echo ()
{
# Without the eval, Bourne shells create the here doc at definition time.
eval 'cat <<_LT_EOF
$*
_LT_EOF
'
: # work around bash bug
}
for ECHO in "$lt_ECHO" 'print -r' 'printf %s\n' func_fallback_echo \
'/usr/bin/printf %s\n' false
do
if test X`{ $ECHO '\t'; } 2>/dev/null` = 'X\t'; then
set x $ECHO; shift
type $1
case `{ type $1; } 2>/dev/null` in
*builtin*) $ECHO "$ECHO is a working builtin echo." ;;
*) $ECHO "$ECHO is a working external echo." ;;
esac
fi
done
___
http://lists.gnu.org/mailman/listinfo/libtool
fallback-echo, finding a suitable $ECHO
Which systems do actually need libtool's --fallback-echo?
(You can
grep -i '^echo=.*fallback-echo' libtool
to find out).
I would like to kill it, that would clean up initialization a bit.
Of those machines, which ones would have problems with this replacement:
(be it input size limitation, forgetting to unlink the here document
temp file, symlink-farming to child processes, creating the here doc at
definition time, whatever?)
func_fallback_echo ()
{
# Without the eval, Bourne shells create the here doc at definition time.
eval 'cat <<_LT_EOF
$*
_LT_EOF
'
: # work around bash bug
}
(Thanks to Sven Mascheck's for the hint on his site, BTW.)
On a related note: Is there a way to reliably find out whether a command
is a builtin or not? I have attached a small script, and encourage
people to test it on all their shells they can find on their systems.
It should reveal at least one working echo, and, in most cases, find
builtins to do the job.
Thanks,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: -DPIC - redundant?
Hi Kevin, (It'd be great if you could enable your mailer to wrap long text lines.) * Kevin F. Quinn wrote on Thu, Jan 27, 2005 at 09:18:57AM CET: > Thanks people; I understand (now) that libtool supports many targets, > each with their own compilers. I guess that means the question > becomes, why set -DPIC on targets that use gcc, where that compiler > defines __PIC__ if it's generating PIC code (at least since gcc 2.8.1 > to my knowledge - I don't know about earlier versions)? Well, -DPIC means just that: you are compiling for position-independent objects. > Presumably stuff that needs to use conditional compilation for > PIC/non-PIC code is compiler- and target-specific, so should use This is an assumption. Might be valid often, but is an assumption. > whatever support is provided in each case (where libtool could add a > define if otherwise there's nothing available from which to decide on > a given platform). In the case of gcc targets, I think '#ifdef > __PIC__' should always be used, however there's a lot of code out > there doing '#ifdef PIC' inside GCC-specific assembler blocks (for > example). How are you going to use gcc-specific assembler in portable software? Why specifically do you mind `#ifdef PIC' in the gcc-specific assembler? I mean, it's not going to be compiled by any other compiler anyway (and if so, one could arguably expect the other compiler to need the very same PIC-special code anyway). > I'd like to be able to say to people who use '#ifdef PIC' > for gcc-specific code (e.g. stuff inside an '#ifdef __GNUC__' block) > that they should be using __PIC__, and get it fixed accordingly. Why? I mean, you can say that, but what does it buy you? These questions are honest. Maybe it's best to provide a specific example why you think existing practice is not best. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: fallback-echo, finding a suitable $ECHO
* Alexandre Oliva wrote on Sun, Jan 30, 2005 at 01:05:59AM CET:
> On Jan 27, 2005, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> > Which systems do actually need libtool's --fallback-echo?
>
> Probably ones that didn't support shell functions either. I don't
> recall exactly which systems required --fallback-echo, but I do recall
> it was added for a very good reason, given how disgusting it is :-)
>
> Since we've now moved on to better systems, supporting shell functions
> and all, we might as well give libtool a new try without this gunk and
> see how it goes. Failing that, a shell function might be good enough,
> although the fact that not even bash gets it right in some cases
> doesn't exactly give me a warm fuzzy feeling about this construct :-)
Oh, I should have written
> > : # work around old bash bug
, and the bug is really independent of the eval (halts the script if the
last cmd in a function returns nonzero, plus `set -e' is in effect).
On second thought, maybe I don't mind if it really halts then -- let's
just remove the workaround.
Thanks,
Ralf
> > func_fallback_echo ()
> > {
> > # Without the eval, Bourne shells create the here doc at definition
> > time.
> > eval 'cat <<_LT_EOF
> > $*
> > _LT_EOF
> > '
> > : # work around bash bug
> > }
___
http://lists.gnu.org/mailman/listinfo/libtool
Solaris 10
Does anyone have time and access and is willing to try out branch-1-5 Libtool on just-released Solaris 10 within the next couple of days? It'd be great if we could integrate any necessary (simple) patches before releasing 1.5.12 (due this weekend). Testing either of branch-2-0 and HEAD of Libtool would also be great, esp. as the enhanced test coverage is bound to show more failures. With branch-1-5, I'd actually expect no failures (while with the other branches there are a couple of open Solaris issues). Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How to configure libtool so that it doesn't run some tests ?
* Patrick Pélissier wrote on Fri, Feb 04, 2005 at 03:03:32PM CET: > How to configure libtool so that it doesn't run C++ / Fortran tests if > the library is a C library, and so doesn't need a C++ / fortran > compiler? The project uses the other autotools and is a C library. I > haven't found this in the documentation. This feature is not available in the 1.5 Libtool series. Upcoming 2.0 does what you want (e.g., if you did not specify AC_PROG_CXX or some Libtool macro to enable C++, it will not be tested for). Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
