Re: GNU Libtool 2.4 released [stable]
On Thu, Sep 30, 2010 at 1:19 PM, Paolo Bonzini bonz...@gnu.org wrote: On 09/27/2010 03:41 PM, Alon Bar-Lev wrote: Thanks for the explanation! On Sun, Sep 26, 2010 at 7:17 AM, Ralf Wildenhuesralf.wildenh...@gmx.de wrote: Also, why not take the value of the sysroot from the DESTDIR automake variable? Because we know DESTDIR far too late, only at 'make install' time and not yet at the time we link against dependent libraries (that may already be installed below the sysroot). But you do relink the libraries when 'make install' is executed. So why not relink it with proper sysroot? Because if you removed sysroot syntax upon make install, you would not be able to link future code with the newly-installed library. Note that it's perfectly possible to use .la files on the final system that didn't go through libtool --mode=finish, as long as all the packages you compile are upgraded to Libtool 2.4 (and IIUC, cygwin's packaging system for example is already re-libtoolizing each package, so it's not that hard to do this). Paolo I wanted to see the process this way... export SYSROOT=/tmp/root1 package1: ./configure package1: make install DESTDIR=/tmp/root1 package2: ./configure package2: make install DESTDIR=/tmp/root2 1. No need to update existing builds, adding --with-sysroot to all configure statements is harder. 2. You can assume DESTDIR is base root (own sysroot), and while linking and all take the SYSROOT environment as base. So I don't really understand the '=' in the .la files. You can always add the SYSROOT prefix to everything in .la if it resides within the SYSROOT. Alon ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.4 released [stable]
On Fri, Oct 1, 2010 at 3:35 PM, Charles Wilson libt...@cwilson.fastmail.fm wrote: Please, over the past three months there were hundreds of messages discussing sysroot and how it shoold be handled. While libtool's support is not yet complete, what IS there is the result of those discussions. Please read them; I have a suspicion you don't quite grok what sysroot is really FOR, so your assumptions about how it should/shouldn't/does/doesn't work are somewhat flawed. You assume wrong. I use cross compilers as much as I use native ones. This why I waited and followed for long libtool's lacking support in these environments. I guess you know better and sure that all OK, this ends the discussion before it started. Anyway, sysroot and cross compile sysroot can be the same, however, making the cross compiler sysroot dirty, may cause undesirable results, especially in build machines. Here comes the DESTDIR to the rescue. But you know better... Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.4 released [stable]
New in 2.4 2010-09-22: • New features: - Sysroot support. This allows you to build cross-compiled packages with the same prefix that will be used on the destination machine, and still find dependent libraries under the compiler's sysroot. Without sysroot support, paths internal to the build system may leak into the product of the build. Sysroot support is disabled unless the --with-sysroot configure option is passed to configure, because .la files generated with sysroot support will not be usable in general with older Libtools. This is great news! Can you please explain how this feature works? I see '=' is added to the prefix of .la files. This suggests *ALL* packages compiled into sysroot must be migrated to libtool 2.4. Also, why not take the value of the sysroot from the DESTDIR automake variable? Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: hpux linking shared library with static library
Thank you! But I do link the static library as PIC. Attached is a sample. When I remove the restriction all works, shared can call static, main can call both. --- $ ldd xxx/bin/test1 = /usr/lib/libc.2 = /usr/lib/libc.2 /usr/lib/libdld.2 =/usr/lib/libdld.2 /usr/lib/libc.2 = /usr/lib/libc.2 /tmp/alon/test-1/xxx/lib/libb.sl = /tmp/alon/test-1/xxx/lib/libb.sl /usr/lib/libc.2 = /usr/lib/libc.2 $ xxx/bin/test1 --- --- AUTOMAKE_OPTIONS = foreign 1.10 ACLOCAL_AMFLAGS = -I m4 noinst_LTLIBRARIES = liba.la lib_LTLIBRARIES = libb.la bin_PROGRAMS = test1 liba_la_SOURCES = a.c liba_la_CFLAGS = $(AM_CFLAGS) -prefer-pic liba_la_LDFLAGS= $(AM_LDFLAGS) -rpath $(libdir) -static libb_la_SOURCES = b.c libb.exports libb_la_LIBADD = liba.la libb_la_LDFLAGS = $(AM_LDFLAGS) \ -avoid-version -no-undefined \ -export-symbols $(srcdir)/libb.exports test1_SOURCES = c.c test1_LDADD = libb.la --- On Tue, Jul 13, 2010 at 7:30 PM, Robert Boehne rboe...@gmail.com wrote: When your shared library links, that doesn't mean it will work. You would need to run a program with it, that uses symbols in the archive you've attempted to link to your shared library. IIRC, HPUX will generate non-pic by default and your link may not be resolving anything in the static archive. On Tue, Jul 13, 2010 at 11:09 AM, Alon Bar-Lev alon.bar...@gmail.com wrote: Hello, When I try to link shared library with static library on hpux I get the following message: *** Warning: This system can not link to static lib archive libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. However if I change libtool: -deplibs_check_method=file_magic (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library +deplibs_check_method=pass_all It succeed in linking. Any reason why this is forbidden in hpux? $ uname -a HP-UX hpux1 B.11.11 U 9000/800 1528720528 unlimited-user license Regards, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool test.tar.gz Description: GNU Zip compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
z/OS
Hello, Does anyone has experience with libtool at z/OS open edition? It builds static libraries, but it does not know how to build shared objects. Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: hpux linking shared library with static library
Hello Robert, This argument is correct, however it is true for all platforms, while this already works using libtool in: - Windows 32bit - Windows 64bit - Solaris 8 - Solaris 10 sparc - Solaris 10 intel - AIX 5.3 - AIX 6.1 - Linux 2.2 i386 - Linux 2.4 i386 - Linux 2.6 i686 - Linux 2.6 x86_64 - Linux 2.6 ppc - Linux 2.6 s390 Something must be different in hpux configuration, while it can behave like any other OS, libtool enforces something else. Thanks, Alon. On Wed, Jul 14, 2010 at 7:20 PM, Robert Boehne rboe...@gmail.com wrote: Libtool is intended to support a portable subset of shared library functionality. When you use an archive file to create a shared library, this is generally not a portable feature, and won't work on many systems (like Windows). In this situation, you will be better off creating a shared library of the archive you want to link in, or expanding it into it's object files and linking them directly (like a Libtool convenience library). But whatever you may do, if you get an archive that isn't pic, it won't work, and because the one advantage to static archives is that they don't have to be pic (and may run a little faster) most of them are created from object files that are not pic. HTH, Rob On Wed, Jul 14, 2010 at 2:47 AM, Alon Bar-Lev alon.bar...@gmail.com wrote: Thank you! But I do link the static library as PIC. Attached is a sample. When I remove the restriction all works, shared can call static, main can call both. --- $ ldd xxx/bin/test1 = /usr/lib/libc.2 = /usr/lib/libc.2 /usr/lib/libdld.2 = /usr/lib/libdld.2 /usr/lib/libc.2 = /usr/lib/libc.2 /tmp/alon/test-1/xxx/lib/libb.sl = /tmp/alon/test-1/xxx/lib/libb.sl /usr/lib/libc.2 = /usr/lib/libc.2 $ xxx/bin/test1 --- --- AUTOMAKE_OPTIONS = foreign 1.10 ACLOCAL_AMFLAGS = -I m4 noinst_LTLIBRARIES = liba.la lib_LTLIBRARIES = libb.la bin_PROGRAMS = test1 liba_la_SOURCES = a.c liba_la_CFLAGS = $(AM_CFLAGS) -prefer-pic liba_la_LDFLAGS= $(AM_LDFLAGS) -rpath $(libdir) -static libb_la_SOURCES = b.c libb.exports libb_la_LIBADD = liba.la libb_la_LDFLAGS = $(AM_LDFLAGS) \ -avoid-version -no-undefined \ -export-symbols $(srcdir)/libb.exports test1_SOURCES = c.c test1_LDADD = libb.la --- On Tue, Jul 13, 2010 at 7:30 PM, Robert Boehne rboe...@gmail.com wrote: When your shared library links, that doesn't mean it will work. You would need to run a program with it, that uses symbols in the archive you've attempted to link to your shared library. IIRC, HPUX will generate non-pic by default and your link may not be resolving anything in the static archive. On Tue, Jul 13, 2010 at 11:09 AM, Alon Bar-Lev alon.bar...@gmail.com wrote: Hello, When I try to link shared library with static library on hpux I get the following message: *** Warning: This system can not link to static lib archive libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. However if I change libtool: -deplibs_check_method=file_magic (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library +deplibs_check_method=pass_all It succeed in linking. Any reason why this is forbidden in hpux? $ uname -a HP-UX hpux1 B.11.11 U 9000/800 1528720528 unlimited-user license Regards, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: z/OS
Sure, I do anything to help. However, I am missing some details on the z/OS linkage process, even without libtool I could not find a proper way to create a shared object (or dll which is the right name at this platform). If nobody ported libtool to this platform, I will try to figure out how to do this by-hand first. Thanks! Alon. On Thu, Jul 15, 2010 at 7:43 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hi Alon, * Alon Bar-Lev wrote on Wed, Jul 14, 2010 at 04:48:22PM CEST: Does anyone has experience with libtool at z/OS open edition? It builds static libraries, but it does not know how to build shared objects. AFAICS Libtool does not support z/OS yet, which means only static libraries can be expected to work. Porting Libtool to a new system is fairly straightforward if all the documentation is available. Are you willing to help with this? If yes, I can start writing a number of questions for it. You could send pointers. Generally, the right thing to do is grab git Libtool, start reading the PORTING file, follow pointers there, and search for PORTME in *.m4 files. When you have something that works, start running the test suites to find out that you're not quite done yet. ;-) Post whatever you can find out, including (very important!) test suite output. We may need copyright papers for nontrivial patches (so please don't post them if you're not willing to go there; in that case it is easier if you provide pointers and test suggested patches from us). Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: hpux linking shared library with static library
On Wed, Jul 14, 2010 at 10:21 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Wed, 14 Jul 2010, Alon Bar-Lev wrote: Thank you! But I do link the static library as PIC. Even if the static library is PIC, and the OS is happy to load and run the result, there is a common problem with this approach since if more than one shared library is linked with the static library, and these two shared libraries are used in the same program, there are likely to be duplicate symbol conficts or semi-random operation. The problem becomes worse if multiple versions of the static library were used. Bob Hello Bob, Yes, I know, we already gone though this argument before and I Ralph helped me with the hack -rpath $(libdir) [1]. This argument is good for best practice design, but there are cases in which the shared library should be with minimum dependencies, I explained all at thread [2], it should be my decision to make. Now, this already works using libtool in: - Windows 32bit - Windows 64bit - Solaris 8 - Solaris 10 sparc - Solaris 10 intel - AIX 5.3 - AIX 6.1 - Linux 2.2 i386 - Linux 2.4 i386 - Linux 2.6 i686 - Linux 2.6 x86_64 - Linux 2.6 ppc - Linux 2.6 s390 So something must be different in hpux configuration, while it can behave like any other OS, libtool enforces something else. Alon. [1] http://www.mail-archive.com/libtool@gnu.org/msg11805.html [2] http://www.mail-archive.com/libtool@gnu.org/msg11804.html ___ http://lists.gnu.org/mailman/listinfo/libtool
hpux linking shared library with static library
Hello, When I try to link shared library with static library on hpux I get the following message: *** Warning: This system can not link to static lib archive libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. However if I change libtool: -deplibs_check_method=file_magic (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library +deplibs_check_method=pass_all It succeed in linking. Any reason why this is forbidden in hpux? $ uname -a HP-UX hpux1 B.11.11 U 9000/800 1528720528 unlimited-user license Regards, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Sun, May 23, 2010 at 11:11 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Sat, May 22, 2010 at 11:13:50AM CEST: On Sat, May 22, 2010 at 12:04 PM, Ralf Wildenhues wrote: * Alon Bar-Lev wrote on Sat, May 22, 2010 at 09:44:46AM CEST: If I read your response correctly, all is needed is to set: lt_cv_deplibs_check_method=pass_all For mingw hosts. But I am no expert in libtool, and it is a complex set of macros. All I know that in the final result libtool script setting: deplibs_check_method=pass_all Makes it work. But breaks other things on this system. Can you please outline [logically] a solution for achieving this without breaking other things? If you give me a hint I can check it out and produce another solution. Not easy, because I haven't analyzed the issues that show up when setting pass_all. I know it breaks a few testsuite tests (and I fear it breaks more things that we don't test in our testsuite), but it's been a while and I haven't been taking good notes back then. It might be that some of the libtool logic is flawed wrt. the w32 semantics. Will windows be supported or not? I've gone a long way in order to convince people of using autoconf/automake/libtool also to create windows binaries. It is great to have single build system for all platforms... And now that we have the mingw-w64 project which revived mingw development it should be great! However, the lack of proper windows support in libtool is a major obstacle. Linking between DLL and static library is valid in this platform. There were some arguing that it shouldn't be done out of consistency/portability reasons: users could come to expect that this would be possible everywhere. I'm not sure where I stand here; certainly, the testsuite failures encountered provide the more stringent argument. PIC static linking with shared objects is also portable... Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Fri, May 21, 2010 at 3:22 AM, Gary V. Vaughan g...@gnu.org wrote: GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. snip I don't think [1] was solved. [1] http://www.mail-archive.com/libtool@gnu.org/msg12013.html ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Sat, May 22, 2010 at 9:46 AM, Gary V. Vaughan g...@gnu.org wrote: Hi Alon, On 22 May 2010, at 13:02, Alon Bar-Lev wrote: On Fri, May 21, 2010 at 3:22 AM, Gary V. Vaughan g...@gnu.org wrote: GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. snip I don't think [1] was solved. [1] http://www.mail-archive.com/libtool@gnu.org/msg12013.html Thanks for the ping. However I haven't used a Windows machine in almost a decade and don't have access to one, but I'd be happy to accept a patch. You don't have to access one, as this is exactly what I am trying to achieve, cross compile Windows binaries on Linux. Although I've slipped the deadlines I set myself at the top of this thread: http://www.mail-archive.com/libtool@gnu.org/msg12059.html a little already, I still plan to put Libtool-2.2.8 out within a week (or two at most), just so long as no one reports significant breakage or regression that make it worse than 2.2.6. And then Libtool-2.2.10 a month (or two at most) later. If your pet bugs aren't patched in time for 2.2.8, there's still time to feed a patch to us in time for 2.2.10. Cheers, -- Gary V. Vaughan (g...@gnu.org) If I read your response correctly, all is needed is to set: lt_cv_deplibs_check_method=pass_all For mingw hosts. But I am no expert in libtool, and it is a complex set of macros. All I know that in the final result libtool script setting: deplibs_check_method=pass_all Makes it work. If you have some other though and you want me to test, I will be happy to. Regards, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Sat, May 22, 2010 at 12:04 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello, please don't Cc: autotools-announce on discussions. Thanks. Sorry. * Alon Bar-Lev wrote on Sat, May 22, 2010 at 09:44:46AM CEST: If I read your response correctly, all is needed is to set: lt_cv_deplibs_check_method=pass_all For mingw hosts. But I am no expert in libtool, and it is a complex set of macros. All I know that in the final result libtool script setting: deplibs_check_method=pass_all Makes it work. But breaks other things on this system. Can you please outline [logically] a solution for achieving this without breaking other things? If you give me a hint I can check it out and produce another solution. Linking between DLL and static library is valid in this platform. Maybe accept current ar archive file type will perform better? Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Fri, May 21, 2010 at 3:22 AM, Gary V. Vaughan g...@gnu.org wrote:
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl,
which hides the complexity of loading dynamic runtime libraries
(modules) behind a consistent, portable interface.
snip
Windows regression.
When linking with libstdc++ which is static library.
libtool-2.2.6b - complains but creates a shared library.
libtool-2.2.7b - complains and does not create a shared library.
Why linking with libstdc++? One of the static archives uses C++.
Why not use CXX? As the sources are C only.
Regards,
Alon.
configure.ac
---
AC_PREREQ([2.63])
AC_INIT([test1], [0])
AC_CONFIG_SRCDIR([f.c])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE
AC_PROG_CC
LT_INIT([win32-dll])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
---
Makefile.am
---
AUTOMAKE_OPTIONS = foreign 1.10
ACLOCAL_AMFLAGS = -I m4
lib_LTLIBRARIES = libf.la
libf_la_SOURCES = f.c
libf_la_LDFLAGS = $(AM_LDFLAGS) -no-undefined
libf_la_LIBADD = -lstdc++
---
f.c
---
int f(void) {
return 0;
}
---
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking specific library as static
On Mon, Apr 12, 2010 at 8:51 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Sun, Apr 11, 2010 at 04:56:23PM CEST: How can I link statically with a specific library? Search the libtool lists for 'per-deplib static' and you will find a proposed patch that should still mostly apply. There were smaller issues left to do IIRC. That's great. When will it be merged? It is important... for Windows too... Remember the discussion [1]. This feature will also enable linking DLL in Windows without dependencies, right? [1] http://www.mail-archive.com/libtool@gnu.org/msg10644.html ___ http://lists.gnu.org/mailman/listinfo/libtool
Linking specific library as static
Hello, I know I had asked this before, but this is one of the most annoying issue I have with libtool. Real world example... I have libpcap which is installed at /usr/lib using the names: libpcap.so libpcap.a I wish to create an application that is linked statically with pcap and pcap alone. If I use -all-static I get all static libraries within my application. If I use -static-libtool-libs it has no effect as there is no libtool description, and also if I link with more than one libtool library I get both static. How can I link statically with a specific library? Ugly Workaround: Create a symbolic link libpcap-static.a-libpcap.a and link with -lpcap-static. Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
Hello Ralf, It is find if you don't want to solve this, but please acknowledge that you don't. So far I did not get any response regarding this issue. When using: AM_CFLAGS = $(PCAP_CFLAGS) -prefer-pic AM_LDFLAGS = -rpath $(libdir) -static In order to make whole-archive go away, it works in *NIX but not in Windows. In order to fix it I need to modify libtool: elif test $build_libtool_libs = yes; then # Not a shared library - if test $deplibs_check_method != pass_all; then +if false test $deplibs_check_method != pass_all; then Any chance this will be solved properly? Thanks, Alon. On Mon, Jan 25, 2010 at 6:12 PM, Alon Bar-Lev alon.bar...@gmail.com wrote: On Sat, Jan 9, 2010 at 10:38 AM, Alon Bar-Lev alon.bar...@gmail.com wrote: On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Jan 07, 2010 at 09:07:46AM CET: For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any idea how to workaround/solve this on windows host? I'm not sure I understand correctly. libtool prints a warning, but should not fail. Is the result usable? If not, then the build should end with an error in a later link: can you post it and its output? Thanks, Ralf Here it is: liba - should be static libb - should be dynamic, liking with liba without whole archive. Works on UNIX does not on Windows. Attached are the sources. Thanks, Alon. --- make all-am make[1]: Entering directory `/home/alonbl/tmp/xx/libtool' /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c -o b.lo b.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -DDLL_EXPORT -DPIC -o .libs/b.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -o b.o /dev/null 21 mv -f .deps/b.Tpo .deps/b.Plo /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -prefer-pic -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c -o liba_la-a.lo `test -f 'a.c' || echo './'`a.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -DDLL_EXPORT -DPIC -o .libs/liba_la-a.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -o liba_la-a.o /dev/null 21 mv -f .deps/liba_la-a.Tpo .deps/liba_la-a.Plo /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -prefer-pic -g -O2 -rpath /usr/local/lib -static -o liba.la liba_la-a.lo libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries libtool: link: i686-w64-mingw32-ar cru .libs/liba.a liba_la-a.o libtool: link: i686-w64-mingw32-ranlib .libs/liba.a libtool: link: ( cd .libs rm -f liba.la ln -s ../liba.la liba.la ) /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 -module -shared -avoid-version -no-undefined -export-symbols ./libb.exports -o libb.la -rpath /usr/local/lib b.lo liba.la *** Warning: This system can not link to static lib archive liba.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. libtool: link: i686-w64-mingw32-ar cru .libs/libb.a .libs/b.o libtool: link: i686-w64-mingw32-ranlib .libs/libb.a libtool: link: ( cd .libs rm -f libb.la ln -s ../libb.la libb.la ) make[1]: Leaving directory `/home/alonbl/tmp/xx/libtool' Sorry to bother... but any news regarding this one
Re: Extend libtool dll namespaces for mingw-w64
On Tue, Jan 26, 2010 at 5:26 PM, JonY jo...@users.sourceforge.net wrote: Hi, Currently, on Win32 platforms, Cygwin uses the cyg prefix for dlls, and MinGW based systems uses the lib prefix. This works fine, until mingw-w64 showed up with 64bit dlls. This problem is especially apparent with trying to build mingw-w64 cross compilers. For example, both mingw and mingw-w64 builds libstdc++-6.dll from GCC. When installed, there might be up to 3 incompatible versions of libstdc++-6.dll, from mingw.org, 32bit mingw-w64 and 64bit mingw-w64. I suggest the following naming scheme. mingw.org: libname-major.dll (unchanged) Cygwin: cygname-major.dll (unchanged) mingw-w64(64): lib64name-major.dll mingw-w64(32): lib32name-major.dll libtool should also check if GCC -m32 or -m64 is used, and select the proper namespace accordingly (mingw-w64 GCC can do multilib). Comments? This is highly none standard naming convention... Handling w32 and w64 should be the same as handling multilib at Linux for example. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
On Sat, Jan 9, 2010 at 10:38 AM, Alon Bar-Lev alon.bar...@gmail.com wrote: On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Jan 07, 2010 at 09:07:46AM CET: For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any idea how to workaround/solve this on windows host? I'm not sure I understand correctly. libtool prints a warning, but should not fail. Is the result usable? If not, then the build should end with an error in a later link: can you post it and its output? Thanks, Ralf Here it is: liba - should be static libb - should be dynamic, liking with liba without whole archive. Works on UNIX does not on Windows. Attached are the sources. Thanks, Alon. --- make all-am make[1]: Entering directory `/home/alonbl/tmp/xx/libtool' /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c -o b.lo b.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -DDLL_EXPORT -DPIC -o .libs/b.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -o b.o /dev/null 21 mv -f .deps/b.Tpo .deps/b.Plo /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -prefer-pic -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c -o liba_la-a.lo `test -f 'a.c' || echo './'`a.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -DDLL_EXPORT -DPIC -o .libs/liba_la-a.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -o liba_la-a.o /dev/null 21 mv -f .deps/liba_la-a.Tpo .deps/liba_la-a.Plo /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -prefer-pic -g -O2 -rpath /usr/local/lib -static -o liba.la liba_la-a.lo libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries libtool: link: i686-w64-mingw32-ar cru .libs/liba.a liba_la-a.o libtool: link: i686-w64-mingw32-ranlib .libs/liba.a libtool: link: ( cd .libs rm -f liba.la ln -s ../liba.la liba.la ) /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 -module -shared -avoid-version -no-undefined -export-symbols ./libb.exports -o libb.la -rpath /usr/local/lib b.lo liba.la *** Warning: This system can not link to static lib archive liba.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. libtool: link: i686-w64-mingw32-ar cru .libs/libb.a .libs/b.o libtool: link: i686-w64-mingw32-ranlib .libs/libb.a libtool: link: ( cd .libs rm -f libb.la ln -s ../libb.la libb.la ) make[1]: Leaving directory `/home/alonbl/tmp/xx/libtool' Sorry to bother... but any news regarding this one? Thanks! libtool-whole.tar.bz2 Description: BZip2 compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Jan 07, 2010 at 09:07:46AM CET: For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any idea how to workaround/solve this on windows host? I'm not sure I understand correctly. libtool prints a warning, but should not fail. Is the result usable? If not, then the build should end with an error in a later link: can you post it and its output? Thanks, Ralf Here it is: liba - should be static libb - should be dynamic, liking with liba without whole archive. Works on UNIX does not on Windows. Attached are the sources. Thanks, Alon. --- make all-am make[1]: Entering directory `/home/alonbl/tmp/xx/libtool' /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c -o b.lo b.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -DDLL_EXPORT -DPIC -o .libs/b.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -o b.o /dev/null 21 mv -f .deps/b.Tpo .deps/b.Plo /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -prefer-pic -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c -o liba_la-a.lo `test -f 'a.c' || echo './'`a.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -DDLL_EXPORT -DPIC -o .libs/liba_la-a.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -o liba_la-a.o /dev/null 21 mv -f .deps/liba_la-a.Tpo .deps/liba_la-a.Plo /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -prefer-pic -g -O2 -rpath /usr/local/lib -static -o liba.la liba_la-a.lo libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries libtool: link: i686-w64-mingw32-ar cru .libs/liba.a liba_la-a.o libtool: link: i686-w64-mingw32-ranlib .libs/liba.a libtool: link: ( cd .libs rm -f liba.la ln -s ../liba.la liba.la ) /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 -module -shared -avoid-version -no-undefined -export-symbols ./libb.exports -o libb.la -rpath /usr/local/lib b.lo liba.la *** Warning: This system can not link to static lib archive liba.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. libtool: link: i686-w64-mingw32-ar cru .libs/libb.a .libs/b.o libtool: link: i686-w64-mingw32-ranlib .libs/libb.a libtool: link: ( cd .libs rm -f libb.la ln -s ../libb.la libb.la ) make[1]: Leaving directory `/home/alonbl/tmp/xx/libtool' libtool-whole.tar.bz2 Description: BZip2 compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
On Mon, Dec 21, 2009 at 6:21 PM, Alon Bar-Lev alon.bar...@gmail.com wrote: On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 09:28:59PM CET: On Thu, Dec 3, 2009 at 10:17 PM, Ralf Wildenhues wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 07:08:03PM CET: I have some convenience archives linked against several modules. I wish only required objects to be included in modules. Then make the convenience archives not be convenience archives any longer, i.e., make them libtool libraries. [...] In either case, they may end up being shared libraries (or both), so if you don't want that, add -static to libbar_la_LDFLAGS. I had to add -prefer-pic to CFLAGS in order it to work properly... :) Wow... this is an ugly workaround... Any reason why a simple switch to libtool --mode=link is not supported? Yes, I think this is by intention. What you do is, at least most of the time, ugly. Why do you need the library to be PIC? Usually, the reason for that is that lib1.la does end up included in a, or a couple of, shared libraries or modules somewhere. And at that point, you risk (exposing your users to) subtle bugs: if code from lib1 is present in several places, and contains static state (example: last random number of a RNG), then on some systems, different parts of the running executable might suddenly use different instances of that state. Eww. Typically, that's the point at which developers reconsider to make lib1 a proper shared library. Is it the first time someone needs this? No, but we've been able to convince most of the other guys that asked for this to reconsider. ;-) Hello Ralf, For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any ideas? Hello Ralf, Any idea how to workaround/solve this on windows host? Thanks! ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 09:28:59PM CET: On Thu, Dec 3, 2009 at 10:17 PM, Ralf Wildenhues wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 07:08:03PM CET: I have some convenience archives linked against several modules. I wish only required objects to be included in modules. Then make the convenience archives not be convenience archives any longer, i.e., make them libtool libraries. [...] In either case, they may end up being shared libraries (or both), so if you don't want that, add -static to libbar_la_LDFLAGS. I had to add -prefer-pic to CFLAGS in order it to work properly... :) Wow... this is an ugly workaround... Any reason why a simple switch to libtool --mode=link is not supported? Yes, I think this is by intention. What you do is, at least most of the time, ugly. Why do you need the library to be PIC? Usually, the reason for that is that lib1.la does end up included in a, or a couple of, shared libraries or modules somewhere. And at that point, you risk (exposing your users to) subtle bugs: if code from lib1 is present in several places, and contains static state (example: last random number of a RNG), then on some systems, different parts of the running executable might suddenly use different instances of that state. Eww. Typically, that's the point at which developers reconsider to make lib1 a proper shared library. Is it the first time someone needs this? No, but we've been able to convince most of the other guys that asked for this to reconsider. ;-) Hello Ralf, For some strange reason this workaround does not work in Windows when creating a DLL. I get: --- /bin/sh ../../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 *** Warning: This system can not link to static lib archive ../../../../src/lib/core/libcore.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. --- If I modify libtool: if test $deplibs_check_method != pass_all; then To: if false test $deplibs_check_method != pass_all; then It works... Any ideas? ___ http://lists.gnu.org/mailman/listinfo/libtool
Disable --whole-archive when using convenience archives
Hello, Using: autoconf-2.63 automake-1.10.2 libtool-2.2.6a I have some convenience archives linked against several modules. I wish only required objects to be included in modules. But libtool's usage of --whole-archive forces the whole archive to be included in the module. I could not find any way to disable the --whole-archive injection. In the following example, both a.c and b.c are compiled and added to module.so, although only a.c is actually used. Removing the -Wl,--whole-archive from compilation solves this issue. The following is produced by libtool: bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -module -shared -no-undefined -o module.la -rpath /usr/local/lib m.lo lib1.la libtool: link: gcc -shared .libs/m.o -Wl,--whole-archive ./.libs/lib1.a -Wl,--no-whole-archive -Wl,-soname -Wl,module.so -o .libs/module.so Can anyone help? Thanks! Alon Bar-Lev. --- AUTOMAKE_OPTIONS = foreign 1.10 ACLOCAL_AMFLAGS = -I m4 noinst_LTLIBRARIES = lib1.la lib_LTLIBRARIES = module.la lib1_la_SOURCES = a.c b.c module_la_SOURCES = m.c module_la_LIBADD = lib1.la module_la_LDFLAGS = -avoid-version -module -shared -no-undefined ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
Thank you for quick response (as usual... :) )
I had to add -prefer-pic to CFLAGS in order it to work properly... :)
Wow... this is an ugly workaround... Any reason why a simple switch to
libtool --mode=link is not supported? Is it the first time someone
needs this?
Thanks,
Alon.
---
AUTOMAKE_OPTIONS = foreign 1.10
ACLOCAL_AMFLAGS = -I m4
noinst_LTLIBRARIES = lib1.la
lib_LTLIBRARIES = module.la
lib1_la_CFLAGS = $(AM_CFLAGS) -prefer-pic
lib1_la_SOURCES = a.c b.c
lib1_la_LDFLAGS = -rpath $(libdir) -static
module_la_SOURCES = m.c
module_la_LIBADD = lib1.la
module_la_LDFLAGS = -avoid-version -module -shared -no-undefined
On Thu, Dec 3, 2009 at 10:17 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Hello Alon,
* Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 07:08:03PM CET:
I have some convenience archives linked against several modules.
I wish only required objects to be included in modules.
Then make the convenience archives not be convenience archives any
longer, i.e., make them libtool libraries.
You can make them normal libtool libraries with either
foo_LTLIBRARIES = libbar.la
but then they will be installed in $(foodir) ('foo' often being 'lib').
If you don't want that, then you can get automake to not install them,
but libtool still treat them as normal libraries with
noinst_LTLIBRARIES = libbar.la
libbar_la_LDFLAGS = -rpath /some/dir
In either case, they may end up being shared libraries (or both), so if
you don't want that, add -static to libbar_la_LDFLAGS.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
Hello, On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 09:28:59PM CET: I had to add -prefer-pic to CFLAGS in order it to work properly... :) Wow... this is an ugly workaround... Any reason why a simple switch to libtool --mode=link is not supported? Yes, I think this is by intention. What you do is, at least most of the time, ugly. Oh... It depends of how you perceive ugly... :) Well... I have a plugin which shares code with programs. The plugin should be self-contained. And I have .a libraries which are common to both. In order to support this I must use this workaround for all libraries which are common to the plugin and the module. I just finished migrating a proprietary build system into autoconf/automake/libtool and this simple task became the most complex one. Why do you need the library to be PIC? Usually, the reason for that is that lib1.la does end up included in a, or a couple of, shared libraries or modules somewhere. True. I need to be linked into .so which is a standalone plugin. And at that point, you risk (exposing your users to) subtle bugs: if code from lib1 is present in several places, and contains static state (example: last random number of a RNG), then on some systems, different parts of the running executable might suddenly use different instances of that state. Eww. Well... I can think of a lot of bug that may result from incorrect use of tools... Typically, that's the point at which developers reconsider to make lib1 a proper shared library. Yes, but I cannot have dependencies for my plugin .so implementation. Is it the first time someone needs this? No, but we've been able to convince most of the other guys that asked for this to reconsider. ;-) I see... :) Thank you for your help... As long as there is a workaround I am happy... But... I think this requirement is not so extra ordinary. Thank you, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw win64 comatibility
On 11/23/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: Committed like this. Cheers, and thanks, Ralf Thanks! Will you backport this to 1.5 branch? Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw win64 comatibility
On 11/23/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: No. The 1.5 branch is dead, and I don't recall anyone that desired turning it undead. If there is anything that 1.5.x gave you that you don't get from 2.2.x, then time to complain is *now* (well, *was* a long time ago, but anyway). 2.2.x should be more portable, faster, shinier, better. And 99% compatible (except for what changes NEWS mentions). Cheers, It is that I need now to convince all developers in my project to switch to 2.2 before distro marked it stable. Thanks! ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw win64 comatibility
Ralf?
This is the last task... OpenSSL, mingw64 and other projects already
accepted all patches to make this environment work.
libtool is the last one.
Alon.
On 10/27/08, Alon Bar-Lev [EMAIL PROTECTED] wrote:
Hello Raf,
Any news?
Can I do anything to help?
Alon.
On 10/21/08, Alon Bar-Lev [EMAIL PROTECTED] wrote:
Hello,
Used git head.
Before I use cross compile, I tried to see if all tests pass on local
compiler.
My system (gentoo) has the following versions:
sys-devel/m4-1.4.11
sys-devel/autoconf-2.61-r2
sys-devel/automake-1.10.1-r1
sys-devel/libtool-1.5.26
Attached is the native log and win64 log (after the fix).
You should add *.exe to ignore... :)
Thanks!
Alon.
On 10/21/08, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hello Alon,
Thanks for the report.
* Alon Bar-Lev wrote on Mon, Oct 20, 2008 at 03:19:50PM CEST:
The func_win32_libid is not working correctly when win64 objects are
found.
The file format is file format pe-x86-64.
The attached patches for 1.5.26, 2.2.6a for the resulting libtool
script.
I did not know where to put this in libtool source, can you please
look into it?
It needs to be done in libltdl/config/ltmain.m4sh.
--- libtool.2.2.6a2008-10-20 14:21:57.0 +0200
+++ libtool 2008-10-20 14:21:42.0 +0200
@@ -3073,7 +3073,7 @@ func_win32_libid ()
;;
*ar\ archive*) # could be an import, or static
if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
- $EGREP 'file format pe-i386(.*architecture: i386)?'
/dev/null ; then
+ $EGREP 'file format pe-i386(.*architecture: i386)?|file
format pe-x86-64?' /dev/null ; then
The trailing ? after pe-x86-64 is wrong, pleasse drop it.
win32_nmres=`eval $NM -f posix -A $1 |
$SED -n -e '
1,100{
Can you be bothered to check out the Libtool git tree or a nightly
snapshot (see homepage for links) and, with above change, build it
and run the testsuite on win64, please? We'd be interested in any
failures of
make -k check
(add VERBOSE=yes for verbose output of the old testsuite, and send
tests/testsuite.log for failure of the new one).
You'd need Autoconf for rebuilding Libtool, and also Automake for
running all tests.
Thanks!
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw win64 comatibility
Hello Raf,
Any news?
Can I do anything to help?
Alon.
On 10/21/08, Alon Bar-Lev [EMAIL PROTECTED] wrote:
Hello,
Used git head.
Before I use cross compile, I tried to see if all tests pass on local
compiler.
My system (gentoo) has the following versions:
sys-devel/m4-1.4.11
sys-devel/autoconf-2.61-r2
sys-devel/automake-1.10.1-r1
sys-devel/libtool-1.5.26
Attached is the native log and win64 log (after the fix).
You should add *.exe to ignore... :)
Thanks!
Alon.
On 10/21/08, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hello Alon,
Thanks for the report.
* Alon Bar-Lev wrote on Mon, Oct 20, 2008 at 03:19:50PM CEST:
The func_win32_libid is not working correctly when win64 objects are
found.
The file format is file format pe-x86-64.
The attached patches for 1.5.26, 2.2.6a for the resulting libtool
script.
I did not know where to put this in libtool source, can you please
look into it?
It needs to be done in libltdl/config/ltmain.m4sh.
--- libtool.2.2.6a2008-10-20 14:21:57.0 +0200
+++ libtool 2008-10-20 14:21:42.0 +0200
@@ -3073,7 +3073,7 @@ func_win32_libid ()
;;
*ar\ archive*) # could be an import, or static
if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
- $EGREP 'file format pe-i386(.*architecture: i386)?' /dev/null
; then
+ $EGREP 'file format pe-i386(.*architecture: i386)?|file format
pe-x86-64?' /dev/null ; then
The trailing ? after pe-x86-64 is wrong, pleasse drop it.
win32_nmres=`eval $NM -f posix -A $1 |
$SED -n -e '
1,100{
Can you be bothered to check out the Libtool git tree or a nightly
snapshot (see homepage for links) and, with above change, build it
and run the testsuite on win64, please? We'd be interested in any
failures of
make -k check
(add VERBOSE=yes for verbose output of the old testsuite, and send
tests/testsuite.log for failure of the new one).
You'd need Autoconf for rebuilding Libtool, and also Automake for
running all tests.
Thanks!
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Howto recreate *.la file
Hi! You can review discussion at [1]. Alon. [1] http://lists.gnu.org/archive/html/libtool/2008-06/msg00034.html On 7/8/08, michael [EMAIL PROTECTED] wrote: Hi all, I have crosscompile a lot of stuff for an embedded target. It is possible to recrate the *.la file with the target path without use regular expression? For the dependency_libs= and lib_dir= The paths depends on the temp installation directory. So for example: /home/michael/build/usr/lib in /usr/lib Regards michael ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
Thank you for your response. As long as it is in the future TODO list it is good I am waiting for this for a long time. If it was difficult to you guys, imagine how it is for someone external... Building packages into chroot is more and more common, live-cd, live-usb, initramfs, embedded, vservers etc... A lot of packages use libtool, so using the standard gnu build for chroot environment, in order to build packages without change in the package is important. ./configure --prefix=/ make install DESTDIR=/tmp/myroot As far as I know libtool is the only tool that needs fixups or workaround. If there is any formal workaround for this I will be happy to know, my sample implementation is available at [1]. I will be happy to modify it if there is a better way. But still I get real paths in libraries: $ i586-pc-linux-uclibc-readelf --dynamic root1/lib/libopensc.so Dynamic section at offset 0x7be90 contains 27 entries: TagType Name/Value snip 0x000f (RPATH) Library rpath: [/home/alonbl/my/Development/opensc/windows/trunk/image/opensc/lib://lib] 0x001d (RUNPATH)Library runpath: [/home/alonbl/my/Development/opensc/windows/trunk/image/opensc/lib://lib] 0x000c (INIT) 0x6610 snip Thank you, Alon Bar-Lev. [1] http://www.opensc-project.org/windows/browser/trunk/build On 6/14/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Alon, Bob, all, * Bob Friesenhahn wrote on Thu, Jun 12, 2008 at 10:07:39PM CEST: The best path forward is that if you feel strongly enough about this, then prepare a patch for libtool which works for you. That's necessary, but typically not sufficient, unfortunately. ;-) The patched libtool needs to be tested on various host environments to make sure that it still passes all of its tests. It needs to work for C, C++, and other languages that libtool supports. If the patched libtool only works properly for one host environment, then it is not worth accepting into libtool. Sigh. Fixing DESTDIR support is a lot of work. I think I threw a month's worth of weekends at it once, and then decided to postpone it for a long time. Except for systems using GNU binutils, it'd hardly work anywhere anyway (in order for to have libtool still behave vaguely similar to how it does now, you'd have to have -rpath-link, which most other linkers don't). If there is some volunteer wanting to work on this (with lots of time on their hands), please speak up, and I can try to dig out stuff and go into detail. Actually, if you're a student, and have free time next summer, starting on this could be a good summer-of-code project. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared library - static link specific dependency
Thank you for explaining this. I still don't understand why the developer cannot make the decision if it is proper or not. The -static-libtool-libs can be used for this as-well. If it absent (default) current behavior apply, but if it is specify on shared library then it should behave consistently with executable. It is usable when you want to provide a library to target with low space, and your library use a dependency and you don't want the whole .so be needed at target. Or we have in OpenSC issue with Windows, we would like the PKCS#11 provider (dll) to be without certain dependencies, so that it may be loaded to application with incompatible OpenSSL reference. Alon. On 6/14/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Alon, and sorry for the delay, * Alon Bar-Lev wrote on Fri, Jun 06, 2008 at 09:15:37AM CEST: I want to make a shared library without dependencies. I compile the dependencies in PIC mode, so it should be compatible. Let's say I have liba.la pointing to liba.so* and liba.a(pic) installed in my system. I am not building this right now. Now, I would like to create moduleb.so that use liba but I do not want to have external dependency of liba.so*. Ah, ok. Libtool doesn't really support this. Well, only with convenience archives, but not with installed stuff. Here's why: The general idea is that you should not have multiple entities of the same code in different libraries, as this can lead to subtle and difficult-to-analyze bugs. Either your libraries are shared (and its dependencies are, too), or your libraries are static, and their code will end up in the final program (but not in other libraries depending on it). This is how libtool handles shared libraries and shared modules, and also how it handles static libraries and dlpreopened modules. Of course the latter only work with libltdl. This is also the reason why installing convenience archives is discouraged: it makes it easy to end up with code being duplicated into several libraries. (I suppose you could hack around this by manually copying libconvenience.la and $(LT_OBJDIR)/libconvenience.a into some installed location, and use that later; but again, be warned). Maybe libtool should support this (I think it did at one point in the past), but add a big fat warning sign. Hmm. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared library - static link specific dependency
On 6/14/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: I would like to create a program that links against your PKCS#11 provider DLL, and for some reason, I also need to link against OpenSSL or some other library from which you have put code into the DLL. If I understand your example above correctly, then I can get into trouble with symbol mixups caused by that. This would not happen, had you linked against the OpenSSL/other DLL in the first place. I may not understand what you write. As far as I understand, if I have PKCS#11 provider (library) with OpenSSL linked within it, and application loads it, there is not symbol mixups, as the symbols of embedded OpenSSL implementation are not exposted to the application. And as the interface between application and the library does not share any OpenSSL related element, it should work perfectly even if the application load incompatible OpenSSL library. However, current implementation forces all the modules (.exe, .dlls) to use the exact same libraries thought instance. So if I use libtool to build the PKCS#11 provider, I cannot provide a library that will be independent of the .exe dependencies. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared library - static link specific dependency
On 6/14/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Alon Bar-Lev wrote on Sat, Jun 14, 2008 at 11:36:03AM CEST: On 6/14/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: I would like to create a program that links against your PKCS#11 provider DLL, and for some reason, I also need to link against OpenSSL or some other library from which you have put code into the DLL. If I understand your example above correctly, then I can get into trouble with symbol mixups caused by that. This would not happen, had you linked against the OpenSSL/other DLL in the first place. I may not understand what you write. As far as I understand, if I have PKCS#11 provider (library) with OpenSSL linked within it, and application loads it, there is not symbol mixups, as the symbols of embedded OpenSSL implementation are not exposted to the application. How do you ensure that (portably)? And as the interface between application and the library does not share any OpenSSL related element, it should work perfectly even if the application load incompatible OpenSSL library. As I don't know your package, I assume this may be realized somehow. My point is: it is not possible to realize this fully portably, but what's more, on unixoid systems it typically requires both action on your part (default to symbol hiding), and it requires that the library in question (here: OpenSSL) not have some unique state that must not exist more than once in the final loaded code. Does that make sense? You know much more than, so I take your word that it may add some issues. Thank you for this discussion. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Compiling into chroot
Hello, I looked at recent libtool-2 versions and could still not find a solution to compile into chroot. I want to create an image to embedded device using a cross compiler. So I do: mkdir /tmp/device-root cd /package1 ./configure --host= --prefix=/usr make install DESTDIR=/tmp/device-root cd /package2 ./configure --host= --prefix=/usr make install DESTDIR=/tmp/device-root But package2 cannot find libraries as the .la files constains pathes to /usr/lib and not /tmp/device-root/usr/lib. Is there any way to make libtool search the /tmp/device-root prefix, and behave correctly? I am thinking like an environment variable so that packages will not be effected. Thanks, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Roumen Petrov [EMAIL PROTECTED] wrote: Hmm. What is related to chroot ? After installing I want to perform: chroot /tmp/device-root /bin/whatever And continue from there. So all elements (linkage, .la) should be related to the chroot and not to host filesystem. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Roumen Petrov [EMAIL PROTECTED] wrote: It look like an enhancement request. libtool to obey as example FAKEROOT=/tmp/device-root and to look first in $FAKEROOT/path1 , ... and $FAKEROOT/pathN and later in /path1,... and /pathN . This what I had in mind. It also should append the FAKEROOT to pathes read from .la files. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Thu, 12 Jun 2008, Alon Bar-Lev wrote: After installing I want to perform: chroot /tmp/device-root /bin/whatever And continue from there. So all elements (linkage, .la) should be related to the chroot and not to host filesystem. Why not just add a /tmp/device-root symbolic link to '/' in your chrooted space? Then everything will be happy. The alternative is to use a script to update all of the installed .la files to use the new paths. This is not libtool's problem. Sure it is libtool's problem! Changing the .la after each package is not enough. If there is embedded configure within configure, or if it is part of package management, it cannot be simply done. Also I am getting: ~/my/Development/opensc/windows/trunk/image $ i586-pc-linux-uclibc-readelf --dynamic root1/lib/libopensc.so Dynamic section at offset 0x7be90 contains 27 entries: TagType Name/Value snip 0x000f (RPATH) Library rpath: [/home/alonbl/my/Development/opensc/windows/trunk/image/opensc/lib://lib] 0x001d (RUNPATH)Library runpath: [/home/alonbl/my/Development/opensc/windows/trunk/image/opensc/lib://lib] 0x000c (INIT) 0x6610 Notice the two pathes. Maybe I am doing something wrong, you can review the script at [1]. It should build all OpenSC packages for initramfs and Windows. Currently libtool is the only tool making the problems, I need to keep modifying the .la files over and over, and then restore them. And I still get the full path of the host system within the libraries and executables, this is unexpected side result of clean chroot. Alon. [1] http://www.opensc-project.org/windows/browser/trunk/build ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Bob Friesenhahn [EMAIL PROTECTED] wrote: There are three ways of looking at this issue. One is to prepare the files differently so that they just work in the chroot environment (requires the FAKEROOT when files are prepared). The second way is to do something special so that already prepared files still work in the chroot environment (requires the FAKEROOT when files are used under chroot). The third way is to edit/update the .la files so that they work in the new root. The first and second ways seem to cause runtime overhead for all libtool users and are not completely portable since build tools may embed paths to source files, object files, or libraries in the built objects and libraries. There is quite a bit to keep track of so new bugs may be added. Because of this configure --prefix=/ is used, so embedded paths will be relative to root and not directory in host system. So the only issue is with libtool. The third way is similar to the first way except that it requires an extra step from the user. As it turns out, libtool already supports a last step (--mode=finish) which could be used to fix up any paths as well as do any platform-specific actions. Libtool would have to know that paths need to be corrected. This would need to be executed from within the chroot environment. The path correction could be computed based on the difference between the current path and the path in the .la file. It may be that some existing platform-specific actions (e.g. ranlib, ldconfig) might fail in the chroot environment since the user has not made it complete enough. Since the libtool project is a volunteer project, it does not take requests unless a maintainer volunteers to do the work. The best path forward is for a interested volunteer to perform the necessary edits, prove that they work, and submit a patch. There is the risk that it will be decided that the changes are too invasive or too risky and the patch might not be accepted. We all volunteers... and before we do work for a project, we need to know that it is not for nothing. But usually project maintainers can do these stuff in less effort and better quality. The FAKEROOT proposal sounds similar to DESTDIR (implemented in Automake) except that it may require many changes in libtool vs very little required change for DESTDIR. This is the simplest, as execution of commands within the chroot is impossible. As it may be cross compile and target is not operational. As far as I understand, you can add FAKEROOT into each path variable read from .la files, and removed before writing the .la files. Also removed from all operations during the finish stage. But as libtool script is so complex it is very difficult to provide a solution to outsiders. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Thu, 12 Jun 2008, Alon Bar-Lev wrote: Because of this configure --prefix=/ is used, so embedded paths will be relative to root and not directory in host system. So the only issue is with libtool. Libtool is not aware of --prefix! It only knows the paths given to it and what it learns from its environment. Because of this we recommend an environment variable. So that it can substract it from the path to determine the path on the chroot. This is the simplest, as execution of commands within the chroot is impossible. As it may be cross compile and target is not operational. Commands may be executed if the chroot environment is sufficiently updated to make it possible. How? If this is for different CPU? I have the same issue with cross compile to mips, I compile initramfs. Do you mean that you need a libtool something to run on my embedded initramfs to fix up the mess at runtime? As far as I understand, you can add FAKEROOT into each path variable read from .la files, and removed before writing the .la files. Also removed from all operations during the finish stage. How does this mesh with libltdl (which also reads .la files) and test suites? It seems that libltdl would also need to know about FAKEROOT, which results in every application using libltdl responding to FAKEROOT. There may be additional security issues here similar to LD_LIBRARY_PATH, but worse since the compromised application could setenv FAKEROOT before a module is loaded and cause a compromised module/library to be loaded. I don't understand! If all pathes within the .la files are relative to the FAKEROOT, the libltdl which runs within the chroot environment will find the files exactly where .la files reference to. All the work should be done so that within the chroot environment all files will be as if they were compiled within it. But as libtool script is so complex it is very difficult to provide a solution to outsiders. A well kept secret is that the libtool maintainers also consider the libtool script to be quite complex. :-) I figured this out... Even libtool-2 with all its cleanups is very complex. Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Bob Friesenhahn [EMAIL PROTECTED] wrote: The libltdl code doesn't know if it is executed in a chrooted environment. The FAKEROOT option can be used for purposes other than cross-compile so it can be expected that if the build is not a cross-compile then libltdl needs to be able to work (to support testing), and therefore needs to respect FAKEROOT. If you prepare chroot environment, you don't expect it to work without chroot into it first! You cannot eliminate a cross-compile solution only because you cannot test it on build machine. All tools work great in doing cross compile (including libtool), the only missing functionality is for libtool to create valid chroot environment. Besides cross compile, a use of a chrooted environment is to detect use of files which are not currently resident in that environment. It is a poor-man's way to decide if the build is likely to work on someone else's machine without testing on another machine. Which file is missing? I don't follow you. DESTDIR users may also have a desire to fix up the .la files but without desire for the FAKEROOT features. No... DESTDIR just tells to install into other location, without any change or fixup. It seems that there are many descriptions of this elephant. I think you going to differnet place than creating a valid environment for chroot. Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/13/08, Bob Friesenhahn [EMAIL PROTECTED] wrote: Any file. :-) Another common use of chroot installs is to create a small OS-root environment with all of the libraries and files that the package is expected to need (could be a base Linux install). Then the package is installed under the chrooted environment and tested. The package should be able to run without saying that it can't find libYYY.so or fileXXX. You compile the libc and also install it to the same place. I don't think that it is libtool job to find dependencies and place them within. I use a simple script that examine dependencies within the chroot and copy libraries from cross compile environment into the chroot location. So I don't think this is the feature that is missing. The major issue is to make sure that files installed by libtool into the chroot will be valid after chroot given all dependencies are available. It seems that there are many descriptions of this elephant. I think you going to differnet place than creating a valid environment for chroot. That is true, but if more valid uses are identified for the feature then perhaps there will be more incentive to develop it. Oh... OK. As long as we understand this use case, I am happy. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared library - static link specific dependency
On 6/6/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Alon, * Alon Bar-Lev wrote on Thu, Jun 05, 2008 at 07:09:43PM CEST: I want to make a shared library without dependencies. I compile the dependencies in PIC mode, so it should be compatible. I also require this on Windows, in order to build a DLL without OpenSSL external dependency. Sorry, but I fail to understand your problem description. Is it that liba uses a function from libb, but you would like to use libtool --mode=link $CC -o liba.la a1.lo a2.lo -rpath $libdir rather than libtool --mode=link $CC -no-undefined -o liba.la a1.lo a2.lo libb.lo -rpath $libdir ? Well, on w32, you cannot create DLLs that have unresolved symbols. That's simply not possible. Thank you for your response, Let's say I have liba.la pointing to liba.so* and liba.a(pic) installed in my system. I am not building this right now. Now, I would like to create moduleb.so that use liba but I do not want to have external dependency of liba.so*. This is something like -static-libtool-libs for executables. But if I use -*static* of libtool, I never get moduleb.so as build_libtool_libs=no is forced. I could not find how I can make prefer_static_libs=yes. Regards, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
Shared library - static link specific dependency
Hello, I read that there was some discussion regarding this. I want to make a shared library without dependencies. I compile the dependencies in PIC mode, so it should be compatible. I also require this on Windows, in order to build a DLL without OpenSSL external dependency. I could not find an option for this in 2.2.4. Will this be available? Or I need to write my own build? Thank you, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
Cross compile
Hello, Just checked out the 2.2.4 version. It looks like it still does not support chroot cross compile environment. There is no way to pass the prefix of chroot so that the .la references will be resolved correctly. Do I miss something? Regards, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/29/08, Roumen Petrov [EMAIL PROTECTED] wrote: So with automake makefile like this : lib_LTLIBRARIES = @[EMAIL PROTECTED] @[EMAIL PROTECTED] = module.c @[EMAIL PROTECTED] = -module -avoid-version where MODULE is substituted by configure you can get result. Thanks! It works. Although I am sure I tried this in several notations, and in all I got automake error that this must not be none constant. Strange... I still think that libtool should enable soname to be customized :) Thanks! Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/28/08, Peter O'Gorman [EMAIL PROTECTED] wrote: -rpath is required for proper execution in many environments, the ability to change the soname is, as far as I can tell, not. Please present a more convincing argument. Hello Peter, I think that infrastructures such as libtool should allow customization of any attribute that affect the output. Of course there should be defaults but it should allow overriding to allow customization. This especially true when the customization is simple to implement and to maintain. Your example of not using automake simplified rules in order to workaround the lack of ability to customize the soname attribute is correct. But it is a workaround that makes build system much more complex, just because customization is missing. What you recommend is instead the following automake rules: lib_LTLIBRARIES=module1.la module1_la_SOURCES=m1.c m2.c m3.c m4.c module1_la_LDFLAGS=-module -avoid-version -soname @MYNAME@ install-exec-local: install-libLTLIBRARIES mv -f $(DESTDIR)$(libdir)/module1.so $(DESTDIR)$(libdir)/@MYNAME@ Write the following make rules: LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) CCLD = $(CC) my_objects=m1.lo m2.lo m3.lo m4.lo @MYNAME@: $(my_objects) $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ -module -avoid-version $(LDFLAGS) -o $@ \ -rpath $(libdir) $(my_objects) $(LIBS) lib_LTLIBRARIES=#create install-exec-hook: install-libLTLIBRARIES @MYNAME@ $(LIBTOOL) --mode=install $(INSTALL) @MYNAME@ \ $(DESTDIR)$(libdir) all-local: @MYNAME@ .c.lo: if am__fastdepCC $(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $ mv -f $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo else if AMDEP source='$' object='$@' libtool=yes @AMDEPBACKSLASH@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ endif $(LTCOMPILE) -c -o $@ $ endif It is doable... But in what price? Patching libtool with three lines to add ability to override soname and use 5 line simple automake rules. Or write complex build rules and remove/add parts if automake chooses to not generate/generate libtool stuff, and maintaining these complex rules of about 30 lines. I know what I choose. As far as I understand the soname is one of the few last attributes that cannot be overridden, I don't understand who not enable this and not forcing users to create complex rules if required. It is simple enough to support this... Without breaking ABI or any other past interface. Thank you for your time, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/28/08, Roumen Petrov [EMAIL PROTECTED] wrote: You request is to change library name. So I could not understand what is related to SONAME. It came as a surprise to me to allow user(verdor) to change library name at configure time. It for generating a differnet module using automake. At the end SONAME matches the module name. Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/28/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: There was an earlier, much more elaborate one, by Keith Packard, http://thread.gmane.org/gmane.comp.gnu.libtool.general/6213. I believed I am not the first one... :) Did not find this specific thread though. But... For each report you usually have many people that solves this in a different (long, unmaintained and even incorrect) way, or fail to. And we never applied anything there *because* there was no patch that was nicely portable, or even degrade gracefully on lesser capable platforms, IIRC. Can you please explain (As I don't understand) how allowing to override soname when generating a module makes it less portable? I truly don't understand... If user specify soname and system does not support soname, it is ignored. If system do support soname, then developer has reason to override this. If a user does not specify soname you keep current behavior. Well, I haven't looked much at your 30 lines of Makefile.am, but I can tell you maintaining those 30 lines is going to be *far less* hassle than getting -soname support right. I am truly sorry... But I fail to understand this statement as-is. FWIW2, if you believe modules are named *.so on all kinds of interesting systems, nope. Sorry... I can detect this part at configure. I thought about creating another thread after this one... As libtool *KNOWS* the extension to use, it can place this on autoconf variable... Or add the following: libtool --mode=getvar shrext libtool --mode=getvar libext Thank you, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/27/08, Peter O'Gorman [EMAIL PROTECTED] wrote: Why? I can understand wanting to change the extension, we have -shrext for that. But why do you want the user to have the option to set the name? Hi! Because I generate a plugin, each configuration results in different plugin. I also have this when I produce proxy shared library. I can do this very simple with automake/libtool if I rename the output. But not got any solution of how to correct the soname. Maybe I can do this with some ELF hacking utility, but I think that adding the ability to override the soname via libtool is the simplest and cleanest. Thanks! Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/27/08, Peter O'Gorman [EMAIL PROTECTED] wrote: Does automake complain if you do something like: @PLUGIN_TARGET@: foo.lo $(LIBTOOL) --mode=link --tag=CC $(CCLD) -o @PLUGIN_TARGET@ \ foo.lo -avoid-version -module install-exec-hook: @PLUGIN_TARGET@ $(LIBTOOL) --mode=install $(INSTALL) @PLUTIN_TARGET@ \ $(DESTDIR)$(libdir) ? Hi, Yes, I can write my own automake rules. But then I have to reverse engineer each automake version and add AM_CFLAGS, AM_LDFLAGS, CFLAGS, LDFLAGS, target specific flags, or anything automake generates. I expected libtool to allow override these kind of settings... So I proposed to add -soname argument. I think it is very simple and may make live easier if needed. But if you totally against adding this I will consider maintaining specific automake rules. Thanks! Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/28/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: Is the set of possible names limited? If yes, please read http://www.gnu.org/software/automake/manual/html_node/Conditional-Libtool-Libraries.html Hi, No... Sorry... I need to produce a different name chosen by configure and/or user. But exactly in the spirit of -rpath I believe -soname should be added... :) Thanks! Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool windows dll suffix revision
On 3/15/08, Peter Rosin [EMAIL PROTECTED] wrote: With your suggestion of always using age, you would get dll-7.dll and dll-8.dll for your examples, but you would also get dll-7.dll for my example, and then you would have the same file name for two incompatible dlls, which is a lot worse than having the same file name for two compatible dlls. Please explain further, if I have made any false assumptions. Thank you for your response!!! I reread the libtool versioning system, and it looks like I got it wrong. It looks like you already doing what I request, but I did not put the numbers right. current = newest age = current - oldest dll_suffix = current - age = oldest I am truly sorry... I did not understand that I have to calculate the age delta my-self when producing libtool version, and age is not the oldest. Thank you, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool windows dll suffix revision
Hello, I appreciate any reply regarding this. The win32 build is supported in 2.2 series, and this issue remains. Regards, Alon Bar-Lev. On 3/9/08, Alon Bar-Lev [EMAIL PROTECTED] wrote: Hello, Please CC me as I am not subscribed. Was something in the following discussion progressed? http://www.cygwin.com/ml/cygwin/2000-09/msg00053.html From: Gary V. Vaughan gvv at techie dot com Libtool translates the 5:4:3 into a system specific version number for the soname to help the runtime loadee choose the best available library at runtime. As I said before, currently this mapping is wrong on Windows, and I think the correct mapping is to always use the oldest supported interface number -- in this case library2.dll -- when generating the soname. This is explained fully in the version node of the libtool manual link that was quoted earlier in the thread. For example, I have current interface 7 and age 7 i get dll-0.dll, and if I upgrade to current interface 8 and age 8 I also get dll-0.dll. It looks like generating the suffix version based on delta is incorrect, as you may have duplicate dll names. It also looks like Gary is right, having the version be the age solves the issue, since as long as the library is backward compatible to this age, the name is not change. Best Regards, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool windows dll suffix revision
Hello, Please CC me as I am not subscribed. Was something in the following discussion progressed? http://www.cygwin.com/ml/cygwin/2000-09/msg00053.html From: Gary V. Vaughan gvv at techie dot com Libtool translates the 5:4:3 into a system specific version number for the soname to help the runtime loadee choose the best available library at runtime. As I said before, currently this mapping is wrong on Windows, and I think the correct mapping is to always use the oldest supported interface number -- in this case library2.dll -- when generating the soname. This is explained fully in the version node of the libtool manual link that was quoted earlier in the thread. For example, I have current interface 7 and age 7 i get dll-0.dll, and if I upgrade to current interface 8 and age 8 I also get dll-0.dll. It looks like generating the suffix version based on delta is incorrect, as you may have duplicate dll names. It also looks like Gary is right, having the version be the age solves the issue, since as long as the library is backward compatible to this age, the name is not change. Best Regards, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
