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
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
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
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
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)
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
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
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
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
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
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
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
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
thinking like an environment variable so that packages will not be
effected.
Thanks,
Alon Bar-Lev.
___
http://lists.gnu.org/mailman/listinfo/libtool
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.
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
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
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
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
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
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
/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
, 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
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
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
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
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
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
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
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).
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
-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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
,
Alon Bar-Lev.
___
http://lists.gnu.org/mailman/listinfo/libtool
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
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
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
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
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
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
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
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.
55 matches
Mail list logo
