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

Re: Linking specific library as static

On Mon, Apr 12, 2010 at 8:51 PM, Ralf Wildenhues 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

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

On Fri, May 21, 2010 at 3:22 AM, Gary V. Vaughan 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, p

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

On Sat, May 22, 2010 at 9:46 AM, Gary V. Vaughan 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 wrote: >>> >>> GNU Libtool hides the complexity of using shared libraries behind a >&g

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

On Sat, May 22, 2010 at 12:04 PM, Ralf Wildenhues 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: >&g

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

On Fri, May 21, 2010 at 3:22 AM, Gary V. Vaughan 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, por

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

On Sun, May 23, 2010 at 11:11 AM, Ralf Wildenhues 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 y

hpux linking shared library with static library

11.11 U 9000/800 1528720528 unlimited-user license Regards, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: hpux linking shared library with static library

es 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 wrote: >> >> Hello,

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

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 wrote: >> >> ‎‎Thank you! >> >> But I do link the static library as PIC. >> >>

Re: z/OS

do this by-hand first. Thanks! Alon. On Thu, Jul 15, 2010 at 7:43 AM, Ralf Wildenhues 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

Re: hpux linking shared library with static library

On Wed, Jul 14, 2010 at 10:21 PM, Bob Friesenhahn 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, th

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 intern

Re: GNU Libtool 2.4 released [stable]

‎Thanks for the explanation! On Sun, Sep 26, 2010 at 7:17 AM, Ralf Wildenhues 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 lib

Re: GNU Libtool 2.4 released [stable]

On Thu, Sep 30, 2010 at 1:19 PM, Paolo Bonzini 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 Wildenhues   >> wrote: >>>> >>>> Also, why

Re: GNU Libtool 2.4 released [stable]

On Fri, Oct 1, 2010 at 3:35 PM, Charles Wilson 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 hav

libtool windows dll suffix revision

d 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.

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

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 wors

Customizing soname

ing my libray. Can you please consider adding a way to specify the soname as libtool argument? Thanks, Alon Bar-Lev. --- --- libtool.org 2008-03-27 16:08:34.0 +0200 +++ libtool 2008-03-27 16:09:07.0 +0200 @@ -2034,6 +2034,11 @@ EOF continue ;; + -sona

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

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@ > $(LI

Re: Customizing soname

On 3/28/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Is the set of possible names limited? If yes, please read > > Hi, No... Sorry... I need to produce a different name chosen by configure and/or user

Re: Customizing soname

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.

Re: Customizing soname

On 3/28/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > There was an earlier, much more elaborate one, by Keith Packard, > . I believed I am not the first one... :) Did not find this specific thread though. But... For each report you u

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. A

Shared library - static link specific dependency

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

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

Compiling into chroot

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. _

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

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 (linka

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 t

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 w

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 ab

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 >

Re: Compiling into chroot

/Development/opensc/windows/trunk/image/opensc/lib://lib] 0x000c (INIT) 0x6610 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, > > *

Re: Shared library - static link specific dependency

pendencies, 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: > > > > >

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 ab

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 > >

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 pa

mingw win64 comatibility

anks! Alon Bar-Lev --- --- libtool.1.5.26 2008-10-20 14:25:11.0 +0200 +++ libtool 2008-10-20 14:25:36.0 +0200 @@ -578,7 +578,7 @@ func_win32_libid () ;; *ar\ archive*) # could be an import, or static if eval $OBJDUMP -f $1 | $SED -e '10q' 2>/dev

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 followin

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? > &g

Re: mingw win64 comatibility

On Wednesday 12 November 2008, Ralf Wildenhues wrote: > Hallo Alon, > verify that this command fails: > make check-local TESTSUITEFLAGS='-v -d -x -k AC_WITH_LTDL' > > and post the output, then find out where exactly the failure happens > during configure: > cd tests/testsuite.dir/42 > ./con

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

Re: windres on mingw32 and cygwin

On 12/13/08, Jason Curl wrote: > .rc.lo: > $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=RC --mode=compile > $(RC) $(RCFLAGS) $< -o $@ > > libwin_la_LDFLAGS = -no-undefined -version-info @WINLIB_VERSION_INFO@ > @SHLIB_VERSION_ARG@ > You can look at OpenSC implementation it works both fo

Disable --whole-archive when using convenience archives

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-unde

Re: Disable --whole-archive when using convenience archives

S = -avoid-version -module -shared -no-undefined On Thu, Dec 3, 2009 at 10:17 PM, Ralf Wildenhues 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

Re: Disable --whole-archive when using convenience archives

Hello, On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues 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

Re: Disable --whole-archive when using convenience archives

On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues 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 so

Re: Disable --whole-archive when using convenience archives

On Mon, Dec 21, 2009 at 6:21 PM, Alon Bar-Lev wrote: > On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues > 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 wr

Re: Disable --whole-archive when using convenience archives

On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues 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: >> > --- >>

Re: Disable --whole-archive when using convenience archives

On Sat, Jan 9, 2010 at 10:38 AM, Alon Bar-Lev wrote: > On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues > 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 >>> &g

Re: Extend libtool dll namespaces for mingw-w64

On Tue, Jan 26, 2010 at 5:26 PM, JonY 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 m

Re: Disable --whole-archive when using convenience archives

od" != pass_all; then Any chance this will be solved properly? Thanks, Alon. On Mon, Jan 25, 2010 at 6:12 PM, Alon Bar-Lev wrote: > On Sat, Jan 9, 2010 at 10:38 AM, Alon Bar-Lev wrote: >> On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues >> wrote: >>> * Alon Bar-L