shared libraries.
There are user-specified options such as -R to specify the library
run-path.
I think I can get back to this tomorrow ...
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
notice that one of the two references to
the library is discovered anyway.
Does anyone know how to resolve this problem?
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
I notice that AC_CANONICAL_BUILD is now considered to be an internal
macro (CVS autoconf) and is renamed _AC_CANONICAL_BUILD. CVS libtool
is still requiring AC_CANONICAL_BUILD so it does not work with CVS
autoconf. Will this be fixed soon?
Bob
==
Bob
On Tue, 14 Mar 2000, Thomas Tanner wrote:
>
> On 27-Feb-2000 Bob Friesenhahn wrote:
> > I am encountering a very strange problem when using CVS libtool
> > (multi-lingual) in that several libraries are repeated (as reported by
> > ldd) as dependencies, and these librar
get to the bottom of
it.
Thanks,
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On 20 Mar 2000, Alexandre Oliva wrote:
> On Mar 20, 2000, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
>
> > /bin/sh ./libtool --mode=link gcc -g -O -Wall -Wmissing-prototypes -o
> > display display.o magick/libMagick.la
>
> Does libMagick.la (the script) contain
he same as before.
Help!
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
y
own.
Thanks,
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
)
--enable-shared[=PKGS] build shared libraries [default=no]
--enable-static[=PKGS] build static libraries [default=yes]
In the configure --help output, and the first set seems to win.
Is there a fix for this.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http
On 4 Apr 2000, Alexandre Oliva wrote:
> On Apr 4, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> >>>>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> Bob> I have been using AM_ENABLE_SHARED(no) AM_ENABLE_STATIC(yes)
> Bob&g
)
AC_SUBST(LIBLTDL)
# Check for dlopen support
AC_LIBTOOL_DLOPEN
AC_LIBTOOL_SETUP
AC_PROG_LIBTOOL
works.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
fixed soon?
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
As a follow up to my previous email, there is no dlopen library
provided with FreeBSD 4.0, so the advice that libtool gives when it
builds a static library rather than a shared-library style module is
not valid.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http
On Sat, 8 Apr 2000, Bob Friesenhahn wrote:
> As a follow up to my previous email, there is no dlopen library
> provided with FreeBSD 4.0, so the advice that libtool gives when it
> builds a static library rather than a shared-library style module is
> not valid.
Please disregard t
libtool automatically preload the necessary modules and set up the data
> structure automatically so that the end user does NOT have to call
> LTDL_SET_PRELOADED_SYMBOLS().
>
>
> Thanks in advance. Any advice you can give me would really help me out
> with my Pspell (http://pspe
On Mon, 10 Apr 2000, Kevin Atkinson wrote:
> On Mon, 10 Apr 2000, Bob Friesenhahn wrote:
>
> > Regarding your Problem 2, the way the library I maintain (ImageMagick,
> > http://www.imagemagick.org) does it, each module exposes unique
> > symbols using a pre-defined n
t; seam to me that it will also make an executable extremely non portable across
> multiple sytems
Systems which want to copy binaries around should agree on standard
library locations and naming conventions. Otherwise, there is always
compilation from source.
Bob
=====
or free software since free software must be held to a
higher standard of quality.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Fri, 14 Apr 2000, Kevin Atkinson wrote:
> On Fri, 14 Apr 2000, Bob Friesenhahn wrote:
>
> > Commercial programs typically include a shell script which sets
> > LD_LIBRARY_PATH (and other variables) in order to find the package
> > components. While this may be fine
rly to the compiler and linker.
The appropriate fix to this problem is for libtool to verify that the
specified directory exists prior to deciding that this is a normal -L
option, otherwise the option should be passed on to the compiler and
linker.
Thanks,
Bob
======
Bob F
thing for all platforms
and take away what is not needed.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On Wed, 30 Aug 2000, Ossama Othman wrote:
> Hi Bob,
>
> On Wed, Aug 30, 2000 at 08:21:49AM -0500, Bob Friesenhahn wrote:
> > It would be nice if the $Id RCS tags were removed from the ltcf-c.sh
> > ltcf-cxx.sh and ltcf-gcj.sh files in the multi-lingual libtool branch
>
command to parse /usr/bin/nm -B output... nm: illegal option
-- B
usage: nm [-agnopruw] [file ...]
nm: illegal option -- B
usage: nm [-agnopruw] [file ...]
failed
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
: cannot open conftest.c
neither works
this is in addition to the previously reported
checking for dlopen in -ldl... yes
checking for dlfcn.h... yes
checking whether a program can dlopen itself... cat: cannot open conftest.cc
no
Bob
==
Bob Friesenhahn
[EMAIL
fset.
Has anyone seen this before? Is there a fix or workaround?
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.o
st fine, without encountering this bug.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
f, with
no pre-existing SunWS_cache directory, that it still fails to link in
an identical way.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PRO
Shared libraries won't work ...
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
this info from
Autoconf to libtool (presumably with_gcc environment variable) is not
working any more.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
e configure script. Instead
ac_cv_c_compiler_gnu is set, and ac_cv_prog_gcc is not set at all.
What is the best fix for this problem? It seems like autoconf needs
to set ac_cv_prog_gcc in order to provide backward compatability
for libtool.
Bob
======
Bob Friesen
I do not believe that this is the correct way to fix the
incompatability between CVS autoconf and libtool on the
multi-language-branch (it should be fixed in Autoconf rather than
libtool), but this is a patch to libtool that gets multi-lingual
libtool users over the hump. If this was the correct
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
When the development version of Autoconf is used to generate a
configure script from CVS libltdl's configure.in this error occurs.
configure.in:36: error: m4_require: circular dependency of AC_LTDL_SYMBOL_USCORE
configure.in:36: AC_LTDL_SYMBOL_USCORE is required by...
./aclocal.m4:3382: AC_LTDL_D
;gmake install MAKE=gmake' works.
The other targets (e.g. 'dist') are also handicapped by this problem.
I prefer to install GNU make as 'gmake' so that it does not shadow the
vendor make program, and makes portability testing easier.
Bob
===
I notice that the distclean target in the libltdl directory fails to
remove libltdlc.la. This is a bug.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
nf 2.13
Great. Modules are working well for ImageMagick.
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
y ideas?
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
It seems that the problem I was having is the result of not
re-libtoolizing the package directory. This apparently caused a
mismatch that created the "bug".
Sorry about the noise.
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems
are built as 32-bit objects instead. Is a fix for this
available?
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.o
On Fri, 21 Sep 2001 [EMAIL PROTECTED] wrote:
> On Thu, Sep 20, 2001 at 09:38:29PM -0500, Bob Friesenhahn wrote:
> > 64-bit compilation under Solaris & Sun's compiler requires that the
> > argument '-xarch=v9' be provided when compiling C++ objects.
> >
objects. All linked objects must be built for the same model or
> > linking will fail.
> >
>
> Ok, so it sounds like your first problem is that you are trying to
> pass a compiler flag to the linker.
You're right! This option should be passed via CFLAGS rather than
L
What is required to get shared libraries working under Mac OS X? Is
CVS libtool expected to work for Mac OS X?
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool
Under SPARC Solaris, libltdl crashes when compiled for the 64-bit
addressing model. I received these words from the ImageMagick
developer who is flushing out 64-bit related bugs:
The bug is in ltdl and may be related to 64-bit or perhaps not. I added
(void) lt_dlopen("tiff.la") as the very firs
The problem with libltdl in the Solaris LP64 64-bit model is due to a
mismatch with sizes. argzize_path requires size_t. Under 64-bits
size_t is 8 bytes and int is 4 bytes. Here is a patch which should
resolve the problem.
Index: ltdl.c
=
Here is the output from Sun's 64-bit lint tool when run on libltdl
current as of September 29. You will notice that there are a number of
type down-conversions going on when the code is 64-bit. In order to
be safe, these types should jive for both the ILP32 and LP64 data type
models.
I don't ha
On Sun, 30 Sep 2001 [EMAIL PROTECTED] wrote:
> On Sat, Sep 29, 2001 at 10:56:13PM -0500, Bob Friesenhahn wrote:
> > The problem with libltdl in the Solaris LP64 64-bit model is due to a
> > mismatch with sizes. argzize_path requires size_t. Under 64-bits
> > size_t is
ImageMagick has been using CVS libtool. With gcc 2.95.2, C++
exceptions work fine under Solaris 2.6. With gcc 3.0.1, C++
exceptions are not being caught, causing the program to core dump.
Has anyone else seen this problem? Is it due to libtool?
Bob
==
Bob
/vec.cc:52) so perhaps this is a compiler library issue
unrelated to libtool.
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
-3.0.1/libstdc++-v3/libsupc++/vec.cc:52
from /usr/local/lib/libstdc++.so.3
52 uncatch_exception::uncatch_exception ()
It doesn't seem that any code in the method was executed. The title
on the top of this source module is "New abi Support".
Bob
===
ries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
rom revision 1.5 to 1.6.
This should be fixed ...
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
ile: /home/cvs/libtool/ChangeLog,v
retrieving revision 1.1075
diff -u -r1.1075 ChangeLog
--- ChangeLog 2001/10/28 12:22:38 1.1075
+++ ChangeLog 2001/10/29 00:03:51
@@ -1,3 +1,7 @@
+2001-10-28 Bob Friesenhahn <[EMAIL PROTECTED]>
+
+* Fix pkgdatadir definition.
+
2001-10-28
to be distributable across multiple prefixes
in order to handle the case where libraries are provided by the
system, installed to a common local directory, and installed in a
private directory.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simple
the build environment.
Libtools .la files do not provide this database. Pkg-config scripts do
not provide this database.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
searched by default? The tools used may not even be consistent. For
example, the compiler may look in /usr/local automatically, but the
system linker does not.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
Is there a good way to turn off the usage message that gets displayed
every time a module is installed by libtool? This usage message is
useful for normal shared libraries, but is not useful for loadable
modules.
Thanks,
Bob
==
Bob Friesenhahn
[EMAIL
pported for as
long as it remains actively in use on your chosen operating system.
If you send it to Mars, then it will be supported longer. :-)
Bob
======
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/
I assume that libtool is currently a "dead" project since libtool CVS
has not been updated in weeks, but could the contents of CVS at least
be left in a functional state before allowing libtool to die?
Bob
======
Bob Friesenhahn
[EMAIL PROTE
On Thu, 3 Jan 2002, Robert Boehne wrote:
> Bob Friesenhahn wrote:
> >
> > I assume that libtool is currently a "dead" project since libtool CVS
> > has not been updated in weeks, but could the contents of CVS at least
> > be left in a functional state befor
It looks like the aborted configure run I was seeing was due to an
update I made to configure.ac to try to get 'make dist' to actually
work. My update was missing a quote. Sorry about that.
The automake warning/error remains.
Bob
======
Bob Friesenh
UE@', needed by `Makefile'.
Stop.
gmake[1]: Leaving directory `/home/bfriesen/src/gnu/libtool/libltdl'
gmake: *** [all-recursive] Error 1
Ideas?
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.si
work just fine.
Sorry for all the bother and for being a PITA.
Bob
==========
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
dll, where x is the number current-age. Is that correct?
It is true that Windows does not support useful versioning and is not
able to select among DLLs based on an interface version. It seems
that your analysis is correct.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simp
backwards
compatibility is broken too. But only "removed" is listed here.
Yes, "changed" is the same as "removed". Square blocks don't fit in
round holes. Increment current and set age to 0. Changing an
interface is a big deal.
Bob
--
Bob Friesenhah
purpose. As you say,
libtool does not provide control over which versions of libraries are
consumed in a link since only the current version in the linker search
path, or the version indicated by a .la file, gets used.
I don't think that this makes libtool useless by any means.
Bob
-
7 add additional new rules (related to manifests) that we will
start needing to worry about.
The problem is not fixed yet as far as I am aware. It certainly
plagues GraphicsMagick.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsM
at is what my software
uses and I have not encountered any difficulties across a broad span
of platforms.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagic
dly or
helpful to diagnose memory problems in applications using this
extension.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___
http://lists.gnu.org/mailman/listinfo/libtool
used.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
ely
still loads some implicit DLLs that libltdl is not aware of.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
file do add value.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
ed be. :-)
Most would agree that libltdl includes too many features that nobody
uses, but can bite you in the ass if you fail to pay attention.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagic
rized, each loader is tried in turn
(issuing an error on failure) until a loader is successful, or there
are no more loaders. This is perhaps worse on OS-X where there are
two OS APIs for loading modules. I think that some improvements were
made, but functionality is still lack
aries won't be used by mistake.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
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
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
996. There is no doubt that such horrors
are possible absent proper design.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
for me.
When one participates in a conversation, mails addressed directly from
the sender to you would fail to be filtered, leading to an incomplete
communication flow in the default inbox.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
ekend (September 5th).
I haven't pushed the new small LTO patch series yet. The 72 hours are
over. Anybody want to review (or reject) it before I push?
While I doubt that I am qualified to review the patch, I am definitely
interested in seeing autotools fully support LTO.
Bob
--
Bob Friesen
.
First I would need to build a GCC which properly supports LTO.
Pushing the branch to head would certainly make it easier to test.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
and OS-X Leopard PPC.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
On Sun, 19 Sep 2010, Gary V. Vaughan wrote:
Hi Bob,
On 19 Sep 2010, at 21:41, Bob Friesenhahn wrote:
On Sun, 19 Sep 2010, Gary V. Vaughan wrote:
I'm planning to make the belated 2.4 release in about 24 hours.
Yesterday I ran the libtool test suite on various machines here. The test
On Sun, 19 Sep 2010, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 05:45:45PM CEST:
Unfortunately, my MinGW testing is not so successful. The testing
still quits part-way through with some sort of make-related issue
(as reported in detail previously).
I don't
ing my own GNU make 3.82 under MinGW and the result
behaves the same as 'mingw32-make'.
The timestamps of the files show that no work should be performed but
it seems like the target dependency has been reversed.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesy
causing the libtool test suite to work
for other people using "MinGW" (a continually evolving/varying
environment) and not for me.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.or
s GNU make 2.5 minutes
before it does any actual work (while building GraphicsMagick), which
represents most of the compilation time with the previous make. A
one-year old Cygwin make takes maybe 1.5 seconds to start working when
given the same environment.
Bob
--
Bob Friesenhahn
bfrie...@simpl
ould not
trust a Windows PC dedicated to testing with the ability to send
email.
Shouldn't there be a username component to that email address?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,
u are using Automake I have
heard that there are some fixes in development Automake which are
needed/useful for -flto.
I am interested in trying LTO for myself. :-)
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,
l in order to
assure original consistent operation. GNU's desire to promote the
latest standards results in older already-installed libraries behaving
differently than they originally did after a newer library is added.
Due to this, I am Cc:ing the libtool list in this reply.
Bo
ing libraries.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
w to fix the problem and run my little toy
code?? Thank you!
It seems that the error message has provided instructions for exactly
what to do. I suggest that you do it. It is very rare that error
messages tell you what to do.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.sim
macro is doing. It seems likely that the developer of
the macro was solving some issue with his own compiler installation.
Libtool 1.4.2 was released in 2002. That is eons in libtool time.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen
lly referenced by the
program.
I think that this information should help considerably with
understanding the issue.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
__
aces. In this
case, the older library supporting the same current-age may be
deleted once the new library is installed.
The applications are really what care about the library versioning.
The OS is just there to help with the selection process.
Bob
--
Bob Friesenhahn
bfrie...@
h a newer version of the library since the linker
may bring in several versions of the same library. These issues are
highly OS dependent.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
haviour wouldn't build even right now.
I have experienced such issues before but my own application did still
build and work.
A library which is expected to be loaded by another program such as a
DLL or loadable module would obviously be broken by static linkage.
Bob
--
Bob Friesenhahn
bfrie.
can be seen that most projects already depend on
it (and the main issue for them is to use --no-undefined so libtool
will build a DLL). Primarily programs which originated under Windows
(or really care about Windows) use the dllexport/dllimport facilities.
Bob
--
Bob Friesenhahn
bfri
1 - 100 of 920 matches
Mail list logo
