Re: patch adding argz_add and argz_count implementation
Hi Karl, * Karl Berry wrote on Mon, Feb 25, 2008 at 06:59:39PM CET: A Texinfo contributor made use of two argz functions that are not in the implementation in gnulib, argz_add and argz_count. As a result, of course compilation failed on non-glibc systems. They seemed trivial to implement, so here is a patch for argz.c and argz_.h. How does it look? Good, except that I'd prefer if argz_count used strlen instead of walking the argz vector manually. Little point in adding a suboptimal algorithm if one can have speed (or smaller size) for free by using a library function. Actually, the whole argz_.h vs argz.in.h thing is a bit confusing. It seems like gnulib uses argz.in.h, but the libtool sources use argz_.h. I guess I should change the name when syncing from libtool to gnulib? Or maybe change the name in libtool? I'll change the name in Libtool after 2.2. Maybe I'll even change it to use gnulib-tool ... P.S. I see in passing there are more argz functions not present, but since I didn't need them, I didn't do anything about them. The code from libc/string/argz* could perhaps be used if the need ever arises. Certainly. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
RE: Libtool HEAD on Windows.
Hi! Duft Markus wrote: Hi! [...] Attached is both a log for configure/build and the complete testsuite, and a patch against current HEAD. Has anybody looked into this yet? I'm afraid this won't apply anymore when it's finally reviewed. Cheers, Markus 2008-02-12 Markus Duft [EMAIL PROTECTED] Implemented support for *-winnt*, which is the parity compiler for windows (http://www.sf.net/projects/parity): * libltdl/config/ltmain.m4sh: recognize winnt as Windows OS, specially handle parity compiler (force C++), don't handle .exe extensions like on cygwin and mingw, but like on UNIX. Disable the use of reloadable objects (not supported). * libltdl/libltdl/lt_system.h: Only define R_OK if it's not allready defined elsewhere on Windows. * libltdl/loaders/dlopen.c: Don't use RTLD_GLOBAL with parity. * libltdl/loaders/loadlibrary.c: In case LoadLibrary is used instead of dlopen, convert paths to windows-style for the Windows API's (dlopen does this otherwise). * libltdl/m4/argz.m4: Windows (parity) has no argz support. * libltdl/m4/libtool.m4: Added winnt support. * libltdl/m4/ltdl.m4: On winnt dlopen opens deplibs. * tests/configure-iface.at: Fix output for testsuite. * tests/ctor.at: Use dllimport for correct link. * tests/destdir.at: Add $EXEEXT to output filenames. * tests/duplicate_conv.at: Don't execute the part of the test that relies on reloadable objects (not supported). * tests/export.at: Need explicit export of uninitialized data, use the LIBA_SCOPE define instead of extern. * tests/link-order.at: Use dllimport for correct link. * tests/link-order2.at: XFAIL on winnt. Windows has no RTL. * tests/lt_dladvise.at: Fix output for testsuite. Use dllimport for correct link. Don't test undefined symbols. * tests/lt_dlexit.at: Use dllimport for correct link. * tests/need_lib_prefix.at: Fix output for testsuite. * tests/stresstest.at: Need explicit export of uninitialized data, use the LIBA_SCOPE define instead of extern. link the main-static object only when -static is given. * tests/template.at: Add dependent libs to link line. There is no support for undefined symbols on winnt. * tests/testsuite.at: the *_EXEC_CHECK macros know of $EXEEXT * tests/demo/foo.c tests/demo/foo.h tests/depdemo/l1/l1.c tests/depdemo/l1/l1.h tests/depdemo/l2/l2.c tests/depdemo/l2/l2.h tests/depdemo/l3/l3.c tests/depdemo/l3/l3.h tests/depdemo/l4/l4.c tests/depdemo/l4/l4.h: Use dllimport for correct link. * tests/mdemo/foo1.c tests/mdemo/foo2.c: Initialize global data, otherwise dllexport would be required. * tests/pdemo/foo.h tests/pdemo/longer_file_name_foo.c: Use dllimport for correct link. I hope that's everything you need, otherwise just tell me. Cheers, Markus
Re: PATCH: set --silent when run under make -s
Hi Ben, * Ben Elliston wrote on Mon, Feb 25, 2008 at 07:07:03AM CET: My patch detects when libtool is invoked by make -s and sets the same flag (opt_silent) as if it were invoked with --silent. This is an (undocumented) FAQ: http://thread.gmane.org/gmane.comp.gnu.libtool.general/8772/focus=8803 Your patch is not strict enough, and I would prefer if further discussion actually added value to the already-long discussion that you can for example find in the above thread (and others). For example, a vote by (many) feet could be a reason to think about throwing away backward compatibility and good programming principles ... Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -export-* usage when linking program
I've looked through that part of Libtool due to AIX issues and discovered that export-symbols and its counterpart are not used for linking programs at all. Only for libraries. I don't know if this is intended behavior, but it is the way libtool does things, even with 2.1 Hi all, I'm running libtool 1.5.24 on linux (binutils 2.18) in link mode to link C program with plugins. And I want to use -export-symbols to export plugin API to plugins via standard linker without reinventing dynamic linker (e.g. pass plugin some structure full of pointers to functions). When I pass -export-dynamic to libtool, then all symbols are exported from main binary and my plugin using that symbols can be loaded via dlopen() and it works fine, but exporting all symbols is a bit ugly. When I pass -export-symbols or -export-symbols-regex to link main binary - these options are _silently_ ignored, symbols are not exported and plugin fails to load. :) I've tested my ld and found that it supports option --dynamic-list, that can be used to implement -export-symbols. So my questions are: 1. is it right behavior or is it libtool bug? 1.a silent ignorance of option 1.b working -export-dynamic while linking program 1.c not working -export-symbols while linking program 2. what platforms support -export-symbols option? ___ http://lists.gnu.org/mailman/listinfo/libtool
linking a C program with a C++ library on Solaris
I've been building and packaging a lot of software in the past couple weeks on my x86_64-sun-solaris2.10 workstation. I've been using the Sun Workshop 12 C and C++ compilers for the builds. I've run into several situations in the past week where I'm building a package that's mainly written in C (nautilus, tracker, faac, et. al.) that wants to link with a C++ library (exempi, mpeg4ip). In all the permutations I've encountered so far, both the C++ library and the C package are using libtool, and I've always updated both to use 1.5.26. On Solaris, if you are linking against any C++ objects, you must use the C++ compiler to link. I don't know if that's common to other platforms or not, as I don't have access to the plethora of UNIX platforms I used to. In any case, the packages I've encountered don't seem to expect that, so the (libtool) link stage for the C project doesn't know to use C++, and the link fails. Is this something that libtool could be (should be?) handling automatically? Even if it can't be handled automatically, is there something that libtool could be doing to help make it easier for packages that are primarily C (but link against C++ libraries/objects) to know that they need to switch to C++ for linking in their C project? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linking a C program with a C++ library on Solaris
On Mon, 25 Feb 2008, Tim Mooney wrote: On Solaris, if you are linking against any C++ objects, you must use the C++ compiler to link. I don't know if that's common to other platforms or not, as I don't have access to the plethora of UNIX platforms I used to. In any case, the packages I've encountered don't seem to expect that, so the (libtool) link stage for the C project doesn't know to use C++, and the link fails. Libtool 2.2 does not have this problem. It should be released as soon as someone is available to create the release package since the consensus is that it is ready. Since it did not appear to happen this past weekend, maybe we will be lucky and it will pop out this next weekend. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linking a C program with a C++ library on Solaris
On Mon, 25 Feb 2008, Tim Mooney wrote: Thanks Bob, that's great news! I don't see anything in 2.1b's info files or README or NEWS for updating a project from 1.5.x to 2.2. I assume that means that there's nothing a project maintainer needs to do other than to re-libtoolize his or her project? I believe that backward compatability has been mostly respected. One thing I am aware of is that there is now a requirement that libtool be initialized before libltdl is initialized. There is some newer syntax now. This is what I am using for my nonrecursive project which also configures and builds libltdl nonrecursively. # Configure libtool AC_LIBTOOL_DLOPEN LT_INIT([disable-shared win32-dll]) LT_LANG([C++]) AC_SUBST(LIBTOOL_DEPS) # Configure libltdl LT_CONFIG_LTDL_DIR([ltdl]) LTDL_INIT([convenience nonrecursive]) Building libltdl nonrecursively saves a lot of configure time, and it makes the package smaller. I hope it is nice and warm in North Dakota. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Convenience libraries build both PIC and non-PIC regardless of -static?
For a simple libtool convenience library, I've noticed the compile stage compiles both PIC and non-PIC objects regardless of if it's actually going to need PIC in the link stage. E.g, for something like this, which is explicitly -static: noinst_LTLIBRARIES = libconvenience.la libconvenience_la_LDFLAGS = -static libconvenience_la_SOURCES = convenience.cc convenience.hpp It'll compile both a -fPIC .libs/convenience.o and a normal convenience.o, despite only using the normal convenience.o when producing the archive. For C++ projects with slow compile times, this burns a lot of time. Is there a way to tell libtool to not build those PIC objects without disabling shared libraries globally in the project with AC_DISABLE_SHARED? The only thing I could find about this was this thread[1] but the patch doesn't seem to have been applied. [1] http://www.mail-archive.com/libtool@gnu.org/msg03971.html ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Convenience libraries build both PIC and non-PIC regardless of -static?
On Mon, 25 Feb 2008, Steven Brown wrote: Is there a way to tell libtool to not build those PIC objects without disabling shared libraries globally in the project with AC_DISABLE_SHARED? Probably not without an ugly recursive configure. The problem is that libtool does not know how the convenience libraries will be used so it plays it safe. If you are feeling brave, investigate using a non-recursive build in order to avoid convenience libraries entirely and improve build times. Time for my (mixed C and C++) project to build: recursive: gmake -j 6 89.10s user 7.47s system 195% cpu 49.413 total non-recursive: gmake -j 6 94.90s user 4.56s system 289% cpu 34.301 total The recursive project is older and has a bit less code to compile. The difference grows larger on slower systems. Notice that more build concurrency was achieved with the non-recursive build since with the recursive build there are more barrier points (e.g. packing and unpacking the convenience libs) where concurrency is not allowed. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Convenience libraries build both PIC and non-PIC regardless of -static?
Hello Steven, * Steven Brown wrote on Tue, Feb 26, 2008 at 04:16:42AM CET: noinst_LTLIBRARIES = libconvenience.la libconvenience_la_LDFLAGS = -static libconvenience_la_SOURCES = convenience.cc convenience.hpp Is there a way to tell libtool to not build those PIC objects without disabling shared libraries globally in the project with AC_DISABLE_SHARED? The only thing I could find about this was this thread[1] but the patch doesn't seem to have been applied. With CVS HEAD Libtool, try libconvenience_la_CXXFLAGS = -static or with either HEAD or 1.5.x, and Automake = 1.10, try libconvenience_la_LIBTOOLFLAGS = --tag=disable-shared Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linking a C program with a C++ library on Solaris
Hello Bob, Tim, * Bob Friesenhahn wrote on Tue, Feb 26, 2008 at 03:11:44AM CET: On Mon, 25 Feb 2008, Tim Mooney wrote: I don't see anything in 2.1b's info files or README or NEWS for updating a project from 1.5.x to 2.2. I assume that means that there's nothing a project maintainer needs to do other than to re-libtoolize his or her project? I believe that backward compatability has been mostly respected. Yes, but just running libtoolize has never been enough. Running aclocal (with Libtool 2.2's macro files visible to aclocal) to get the new macro definitions is also needed; autoreconf -vf takes care of both. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
