h of them, but then you might
have to fiddle with adding include directory paths to aclocal such as
with the dirlist feature (info Automake "Macro Search Path").
Another good recommendation is to just not use Libtool 1.5.x or earlier
any more. There really isn't any good reason fo
Hi
A question probably banal so i apologize in advance but i have not
found any clue.
I'm trying to install on Linux(RHEL5) at the same time, as you can do
with automake and autoconf, libtool 2.2.6a with libtool 1.1.5 on FHS
directories (with --prefix /usr) . But it is not enough use the -
progr
Hello Thierry,
* Thierry Pierret wrote on Wed, Nov 19, 2008 at 12:19:04PM CET:
>
> g++ ... -shared ... -o lib_out_sdl.so ... -lccext2 -l... ... `pkg-config
> --libs sdl`
>
> that I transformed into :
>
> $(SHELL) libtool --mode=link --tag=CXX g++ ...
>
> The normal output of the pkg-config com
in advance.
Regards.
--
View this message in context:
http://www.nabble.com/Libtool-1.5---Cross-compilation-and-library-substitution--newbie--tp20577802p20577802.html
Sent from the Gnu - Libtool - Discuss mailing list archive at Nabble.com.
___
http://lis
On Sep 8, 2005, Howard Chu <[EMAIL PROTECTED]> wrote:
> Ralf Wildenhues wrote:
>> Well, that behavior would be fine to me (and it would mean no changes to
>> the code, which is good!), but would not match our current
>> documentation:
>> | @item -static
>> | If @var{output-file} is a program, the
Ralf Wildenhues wrote:
Well, that behavior would be fine to me (and it would mean no changes to
the code, which is good!), but would not match our current
documentation:
| @item -static
| If @var{output-file} is a program, then do not link it against any
| uninstalled shared libtool libraries. I
* Alexandre Oliva wrote on Thu, Sep 08, 2005 at 10:21:18PM CEST:
> On Aug 29, 2005, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> > Hi Howard, Alexandre, others,
> > * Howard Chu wrote on Sun, Aug 28, 2005 at 10:19:03PM CEST:
>
> >> By default we link with -static so
> >> that our local libtool
On Aug 29, 2005, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hi Howard, Alexandre, others,
> * Howard Chu wrote on Sun, Aug 28, 2005 at 10:19:03PM CEST:
>> By default we link with -static so
>> that our local libtool-generated libraries get statically linked. But we
>> don't use -all-static; w
On Mon, Aug 29, 2005 at 03:34:17AM -0700, Howard Chu wrote:
> Ralf Wildenhues wrote:
> >Should we discuss this and decide about what's best? Maybe we'd need
> >another switch to link statically against all non-system libs (in the
> >sense that libc is one, but libdb is not)? Or would implementing
Ralf Wildenhues wrote:
Hi Howard, Alexandre, others,
* Howard Chu wrote on Sun, Aug 28, 2005 at 10:19:03PM CEST:
We just migrated from libtool-1.4.3 to 1.5.18 in the OpenLDAP CVS HEAD,
and are seeing a new linking problem.
You've migrated *already*? :-)
This was actually our 2nd or 3rd att
t; that our local libtool-generated libraries get statically linked. But we
> don't use -all-static; we don't want to alter the default linking for
> system-installed libraries.
OK.
> On SuSE 9.x when the libdb devel RPM is installed, a libdb.la file is
> also installed, an
or
system-installed libraries.
On SuSE 9.x when the libdb devel RPM is installed, a libdb.la file is
also installed, and libtool 1.5 finds and reads this file. In this case,
libtool chooses to link the static libdb into our slapd executable,
rather than the shared library, even though the .la
Hi Jeremie,
* Jeremie LE HEN wrote on Fri, Aug 12, 2005 at 01:43:33PM CEST:
>
> Would you like me to redo the examples once I will be able to a install
> branch-2-0 or HEAD version ?
Naa, since you don't mind my proposed changes, I'll just apply your
patch with fixes.
> > OK. When you can get
Hi Ralf,
> > I made the changes we talked about in our previous mails. Here are a
> > few notes :
> >
> > - I wanted to install the freshly checked-out branch-2-0 from
> > CVS, in order to give real examples of the libtool output.
> > This was really a pain. I've ran into severa
On Thu, Aug 11, 2005 at 04:41:46PM +0200, Ralf Wildenhues wrote:
> They also have position-independent relocations.
> Try 'objdump -x' on my above example.
Ah yes:
.libs/foo.o:
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0019 R_386_GOTPC _GLOBAL_OFFSET_TABLE_
0
* Jeremie LE HEN wrote on Thu, Aug 11, 2005 at 04:10:41PM CEST:
> Hi Patrick,
>
> > quartz% diff -s foo.o .libs/foo.o
> > Files foo.o and .libs/foo.o are identical
Another hint: try
---snip
int foo() { return 1; }
int bar() { return foo(); }
---snip
> I'm not a compiler guru, but as far as I can
Hi Jeremie,
* Jeremie LE HEN wrote on Thu, Aug 11, 2005 at 01:45:39PM CEST:
>
> I made the changes we talked about in our previous mails. Here are a
> few notes :
>
> - I wanted to install the freshly checked-out branch-2-0 from
> CVS, in order to give real examples of the libtool
On Thu, Aug 11, 2005 at 03:41:22PM +0200, Ralf Wildenhues wrote:
> Because in general they are _not_ identical on NetBSD. Show foo.c.
Ah - it was a very simple foo.c ;-)
quartz% cat foo.c
void foo(void);
void foo(void)
{
int i;
i=0;
}
Cheers,
Patrick
___
Hi Patrick,
> Just to check, I just tried this:
>
> quartz% uname -s
> NetBSD
> quartz% libtool compile gcc -g -O -c foo.c
> libtool: compile: gcc -g -O -c foo.c -fPIC -DPIC -o .libs/foo.o
> libtool: compile: gcc -g -O -c foo.c -o foo.o >/dev/null 2>&1
> quartz% ls -laR
> total 16
> drwxr-xr-x
* Patrick Welche wrote on Thu, Aug 11, 2005 at 03:09:29PM CEST:
> On Wed, Jul 20, 2005 at 02:23:06PM +0200, Jeremie LE HEN wrote:
> > IMO, the user is confused while reading this. Furthermore, the
> > first statement is wrong in regard to the example on the NetBSD box
> > (burger) :
>
On Wed, Jul 20, 2005 at 02:23:06PM +0200, Jeremie LE HEN wrote:
> IMO, the user is confused while reading this. Furthermore, the
> first statement is wrong in regard to the example on the NetBSD box
> (burger) :
> burger$ libtool compile gcc -g -O -c foo.c
> mkdir .libs
Hi Ralf,
> Sorry for the late response, I've been away.
Once again, sorry for the late response :-).
I made the changes we talked about in our previous mails. Here are a
few notes :
- I wanted to install the freshly checked-out branch-2-0 from
CVS, in order to give real exam
Hi Jeremie,
Sorry for the late response, I've been away.
* Jeremie LE HEN wrote on Wed, Jul 20, 2005 at 02:23:06PM CEST:
>
> I began to read the documentation (from HEAD) again to make it clearer.
> Here are a few notes :
>
> * Section 3.1 ``Creating object file'' :
> << Since this is a lib
Hi Ralf,
On Fri, Jul 01, 2005 at 05:02:46PM +0200, Ralf Wildenhues wrote:
> * Jeremie LE HEN wrote on Fri, Jul 01, 2005 at 03:29:55PM CEST:
> >
> > > Your documentation points are valid, thanks. We should work on that.
> >
> > You are welcome, I can update the documentation about these subjects
Hi Jeremie,
* Jeremie LE HEN wrote on Fri, Jul 01, 2005 at 03:29:55PM CEST:
>
> > Your documentation points are valid, thanks. We should work on that.
>
> You are welcome, I can update the documentation about these subjects if
> someone points me out the documentation source file (maybe it's si
Hi Ralf,
> > Ok, I didn't know that too :-). I've had a look through the
> > documentation, it would be worth to give an example of the use of
> > this mode, IMHO.
>
> Your documentation points are valid, thanks. We should work on that.
You are welcome, I can update the documentation about the
[ sorry, forgot one part ]
* Ralf Wildenhues wrote on Fri, Jul 01, 2005 at 05:10:22AM CEST:
> * Jeremie LE HEN wrote on Wed, Jun 29, 2005 at 11:20:18AM CEST:
> >
> > I think I got my problem resolved by using the lastest version of
> > libtool (1.5.18) : with exactly the same command sequence, I
Hi Jeremie,
* Jeremie LE HEN wrote on Wed, Jun 29, 2005 at 11:20:18AM CEST:
>
> Ok, I didn't know that too :-). I've had a look through the
> documentation, it would be worth to give an example of the use of
> this mode, IMHO.
Your documentation points are valid, thanks. We should work on that
Hi Ralf,
thank you for spending your time resolving my problem.
> First, a note to your Makefile:
>
> | ${LIB_A}: ${OBJS_A}
> | libtool --mode=link ${CC} -o $@ $^ -static
> |
> | # -rpath is mandatory, libtool --mode=install will fail otherwise.
> | ${LIB_SO}: ${OBJS_SO}
> |
Hi Jeremie,
* Jeremie LE HEN wrote on Tue, Jun 28, 2005 at 05:14:14PM CEST:
>
> > > I'm trying to build both a static and a shared library. This used to
> > > work fine with libtool-1.4, but since I upgraded to libtool-1.5, I can't
> > > build a stati
n to give an answer).
> I'm trying to build both a static and a shared library. This used to
> work fine with libtool-1.4, but since I upgraded to libtool-1.5, I can't
> build a static library any more. I gave a try to the Changelog, but it
> is too heavy, IMO.
Which exa
r).
Yes sorry.
> > I'm trying to build both a static and a shared library. This used to
> > work fine with libtool-1.4, but since I upgraded to libtool-1.5, I can't
> > build a static library any more. I gave a try to the Changelog, but it
> > is too heavy,
.4, but since I upgraded to libtool-1.5, I can't
build a static library any more. I gave a try to the Changelog, but it
is too heavy, IMO.
Thank you.
Regards,
--
Jeremie LE HEN aka TtZ/TataZ [EMAIL PROTECTED]
Hi Ralf,
On Thursday 07 April 2005 11:50 pm, Ralf Wildenhues wrote:
> * Bruce wrote on Thu, Apr 07, 2005 at 06:21:09PM CEST:
> >
> > I am about to release another sharutils and another autogen.
>
> Is that: in less than two weeks?
"in approximately" not "less than". I have to give my uncle an
Hi Bruce,
* Bruce wrote on Thu, Apr 07, 2005 at 06:21:09PM CEST:
>
> I am about to release another sharutils and another autogen.
Is that: in less than two weeks?
> I think I would be disinclined to use the first libtool 2.x out the gate.
> So, that narrows it to 1.5.2 thru 1.5.10, or else 1.5.
Hi again, Ralf,
Ralf Wildenhues wrote:
>
> 1.5.10 does not have this particular regression, but you /might/ hit
> other unrelated Solaris problems since fixed in Libtool which are not
> regressions IIRC.
>
> We had actually hoped not having to release another 1.5.x version, but 2.0
> still has a
On Tue, 10 Aug 2004, Andrews, Glenn J (Glenn) wrote:
When I try to execute a script that uses libtool I get this error..
More than likely there was a /usr/local/bin/echo program present when
this libtool was installed, but it was later removed.
Bob
/usr/local/bin/libtool[393]: /usr/local/bin
When I try to execute a script that
uses libtool I get this error..
/usr/local/bin/libtool[393]: /usr/local/bin/echo:
not found
/usr/local/bin/libtool[562]: /usr/local/bin/echo:
not found
/usr/local/bin/libtool[563]: /usr/local/bin/echo:
not found
/usr/local/bin/libtool[564]
Calling libtool with the following:
/bin/sh ../libtool --mode=link g++ -g -O2 -o libGridExProEDLL.la \
-rpath /prjbob.1/bene/CVS/wxGridEx/Linux/lib \
-rdynamic libGridExProEDLL_la-AFLR3.o \
generates the following command:
g++ -shared -nostdlib
/usr/lib/
On Thu, Feb 19, 2004 at 12:07:21PM -0600, Tim Mooney wrote:
> Given a project that uses libtool 1.4.3 and also uses pthreads, it's
> common to have `-pthread' in CFLAGS when configuring the project. The man
> page for cc defines -pthread as:
>
> -pthread
> Directs the linker to use the th
I believe I've discovered a regression in libtool 1.5.x, at least on Tru64
UNIX. I'm using the vendor cc compiler.
Given a project that uses libtool 1.4.3 and also uses pthreads, it's
common to have `-pthread' in CFLAGS when configuring the project. The man
page for cc
n the the program is first linked in the build
directory. I add placeholders that allow me at install time to insert
code that checks for the existence of any requisite libraries in the
staging directory before prefixing the library's path with the
inst_prefix_dir value.
Sincerely,
Dan
Dano Carroll wrote:
The hello file in /tmp/hello/usr/local/bin/hello is the wrapper file,
not a binary.
I see a very similar problem with an autoconf/automake/libtool project
on HP-UX 11.11 which seems to build and run with no problems in the
staging dir, but when installed into the release dir
then likely have to
fix all the paths in any included scripts, data and documentation
before installing into the final directory. Then the package would
only be usable if I set the SHLIB_PATH/LD_LIBRARY_PATH. This clearly
has some big drawbacks.
Reading the documentation for both libtool 1
book. The Makefile I use is given below. For the purpose of this
demonstration, libtrim.sl is already installed in /usr/local/lib. I am
using libtool 1.5 and gcc 3.3.2, both installed in /usr/local
Makefile--
hello: main.c libhello.la
libtool --mode=link /usr/local/bin/gcc -o hello main.c libh
revert the -static/-shared
functionality not
because I fail to appreciate it, but because it has a duplicate:
indeed, my
request for a -static option for libraries was dropped two or three
years
ago :-) and instead, I was pointed to the disable-shared tag which
was
available in the then ac
Hi Paulo,
It seems this thread starts to go into a direction that might change
the recently added functionality of the -static and -shared flags. In a
previous posting you opted for reverting the -static/-shared
functionality and in the posting quoted below you are opting to make
the disable-s
Why make enable_shared and enable_static specific to a tag? Wouldn't
it be odd that you create shared libs for "C" programs and static for
"C++"? And, the --enable-shared and --enable-static options would have
to multiply (--enable-c-shared, --enable-cxx-shared, etc).
I'm using tags for something d
On Fri, 14 Nov 2003, Albert Chin wrote:
> On Fri, Nov 14, 2003 at 10:44:52AM +0100, Paolo Bonzini wrote:
> > > Does this help?
> > > AC_LIBTOOL_TAGS([])
> >
> > That's only in CVS (actually, I checked and it is not in 1.5, so it must be
> > in CVS).
>
> I can send you a patch against 1.5 if you wa
On Fri, Nov 14, 2003 at 10:44:52AM +0100, Paolo Bonzini wrote:
> > Does this help?
> > AC_LIBTOOL_TAGS([])
>
> That's only in CVS (actually, I checked and it is not in 1.5, so it must be
> in CVS).
I can send you a patch against 1.5 if you want.
> I don't see it that bad that C is not a proper t
> Does this help?
> AC_LIBTOOL_TAGS([])
That's only in CVS (actually, I checked and it is not in 1.5, so it must be
in CVS).
I don't see it that bad that C is not a proper tag, actually.
It would also be good if enable_shared and enable_static became proper tag
variables instead of globals. BTW
On Wed, 2003-11-12 at 20:49, Albert Chin wrote:
> On Wed, Nov 12, 2003 at 06:59:44PM +0100, Paolo Bonzini wrote:
> > I have just upgraded to libtool 1.5 (Debian's package which is taken
> > out of CVS) and here are my first experiences.
>
> HEAD or branch-1-5? I think d
On Wed, Nov 12, 2003 at 06:59:44PM +0100, Paolo Bonzini wrote:
> I have just upgraded to libtool 1.5 (Debian's package which is taken
> out of CVS) and here are my first experiences.
HEAD or branch-1-5? I think development is happening on HEAD towards a
1.6 release.
> However, I ha
I have just upgraded to libtool 1.5 (Debian's package which is taken out of
CVS) and here are my first experiences.
I'd like to make a custom tag so that, for a particular libtool library, PIC
code is also compiled with -fomit-frame-pointer (I really need the register
that is lost by th
When is a 1.5 or 1.5.1 tarball going to be made available?
Thanks,
Nick
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Hello,
Don't really know if it's a problem with libtool-1.5 but I know that I already
built php4.3.3 with libtool-1.4.2.
I tried to build php4.3.3 with the following config:
$ ../configure --prefix=/opt --srcdir=.. --host=x86-pc-nto-qnx --without-pear
--with-zlib=/opt --with-iconv=/op
Hi,
I want to port libtool on qnx-6.2 platform so, I actually encounter a problem
about the so_name's libltdl.so.3.1.0 which is libltdl.so.3 (from objdump -p).
I really need that the so_name is libltdl.so.3.1.0.
I think that libtool has the responsability to inform GCC how to build this.
What I ha
Hi,
About my problem, I found that the soname_spec is incorrect in libtool.m4 and
should be:
soname_spec='${libname}${release}${shared_ext}$versuffix
Tell me if you are agree with that.
I looked at the chapter 13 but I don't really understand what to do after having
modified libtool.m4 in o
On Thursday, September 11, 2003, at 02:03 AM, Charles Wilson wrote:
Boehne, Robert wrote:
Until last week, none of us had a libtool-1.5 tarball, but now that
one has been located we can verify it for the FSF. I'm not sure
when though.
Yeesh, I had no idea. The cygwin libtool-devel-1.5 s
Boehne, Robert wrote:
Until last week, none of us had a libtool-1.5 tarball, but now that
one has been located we can verify it for the FSF. I'm not sure
when though.
Yeesh, I had no idea. The cygwin libtool-devel-1.5 source dist is
widely mirrored, and:
Contents of libtool-devel-
Alan,
Until last week, none of us had a libtool-1.5 tarball, but now that
one has been located we can verify it for the FSF. I'm not sure
when though.
HTH,
Robert
-Original Message-
From: Alan W. Irwin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 02, 2003 11:54 AM
To: [
FSF rightly withdrew many of their tarballs to check for malicious code
because a cracker owned them for many months. However, it has now been a
month since that withdrawal and there is still no official libtool-1.5
tarball at http://ftp.gnu.org/gnu/libtool/. This affects many projects
(like the
On 2003.08.18 06:52 Schleicher Ralph (LLI) wrote:
Steve Edwards writes:
> (Warning) At least one PA 2.0 object file (conftest.o) was detected.
> The linked output may not run on a PA 1.x system.
Add
LDOPTS='+vnocompatwarnings +s'
export LDOPTS
to your .profile file.
Thanks for that. It's
Steve Edwards writes:
> (Warning) At least one PA 2.0 object file (conftest.o) was detected.
> The linked output may not run on a PA 1.x system.
Add
LDOPTS='+vnocompatwarnings +s'
export LDOPTS
to your .profile file.
--
Ralph
___
Libtoo
Just for the information of the libtool maintainers I thought you might
be interested in a few 'features' of the hpux system.
I have just been trying libtool 1.5 on this architecture using the
native hp tools. I am using the HP ANSI C compiler and HP FORTRAN/9000.
When trying to bu
libtool --mode=link gcc test1.o test2.o -o libtest.a
results in
ar cru libtest.a
instead of
ar cru libtest.a test1.o test2.o
--- libtool.objs2003-08-08 12:35:41.0 +0200
+++ libtool 2003-08-08 12:35:51.0 +0200
@@ -5224,7 +5224,7 @@
oldobjs="$libo
Thomas,
This will make the objects link in twice in other cases.
Robert
-Original Message-
From: Thomas Woerner [mailto:[EMAIL PROTECTED]
Sent: Friday, August 08, 2003 5:53 AM
To: [EMAIL PROTECTED]
Subject: libtool 1.5 fix
libtool --mode=link gcc test1.o test2.o -o libtest.a
results
On Sun, Jul 20, 2003 at 08:56:32PM -0400, Thamer Al-Harbash wrote:
> I have been using libtool with some mixed feelings on the amount
> of tests it adds to `configure'. Specifically, although my source
> is all in C, libtool runs C++ and Fortran tests. This adds a bit
> of bloat everytime a user ru
I have been using libtool with some mixed feelings on the amount
of tests it adds to `configure'. Specifically, although my source
is all in C, libtool runs C++ and Fortran tests. This adds a bit
of bloat everytime a user runs the configuration script.
I have already explicitly specified the langu
Hi,
we've recently had a bug report about cross compiling kaffe for
arm-linux. It turned out that libtool was picking the wrong libjpeg
library, the one from the host system instead of the one from the target
system. See the end of
http://www.kaffe.org/pipermail/kaffe/2003-July/042988.html for
ts did not add any checks for C++.
Looking through Google I seem to find references to this dated from April,
and discussion until early June, but no resolution. I just upgraded from
libtool-1.4.3 to libtool-1.5 today in order to get a working
AC_LIBTOOL_DLOPEN (the patches I found on Google didn&
GCC 3.3, most if not all of the Apple-like command line
options are processed just as they are on the compiler distributed by
Apple. Take a look at the sources and you'll see there are hooks for
this. For libtool 1.5, treating stock GCC 3.3 like Apple's GCC works
for me to genera
> With stock GCC 3.3, most if not all of the Apple-like command line
> > options are processed just as they are on the compiler distributed by
> > Apple. Take a look at the sources and you'll see there are hooks for
> > this. For libtool 1.5, treating stock GCC 3.3 like App
eally think it is required?
With stock GCC 3.3, most if not all of the Apple-like command line
options are processed just as they are on the compiler distributed by
Apple. Take a look at the sources and you'll see there are hooks for
this. For libtool 1.5, treating stock GCC 3.3 like Apple&#
f the Apple-like command line
options are processed just as they are on the compiler distributed by
Apple. Take a look at the sources and you'll see there are hooks for
this. For libtool 1.5, treating stock GCC 3.3 like Apple's GCC works
for me to generate dynamic libraries
aturday, May 31, 2003, at 08:22 AM, Bill Northcott wrote:
Another member of our group suggested:
Before installing libtool 1.5, go through the libtool.m4 and change
all
the stuff
that says:
if $CC -v 2>&1 | grep 'Apple' >/dev/null ; then \
to:
if true; then
Then rerun libtoo
Another member of our group suggested:
> Before installing libtool 1.5, go through the libtool.m4 and change all
> the stuff
> that says:
> if $CC -v 2>&1 | grep 'Apple' >/dev/null ; then \
> to:
> if true; then
> Then rerun libtool's `bootstrap',
Could you possible run this again in this directory (preferably with
all the .o's present in the .libs dir) using `"make SHELL=/bin/sh -x"
>& log.txt' and send me the log.
Thanks,
Peter
On Friday, May 30, 2003, at 01:34 PM, Bill Northcott wrote:
****
I have show stopping problems trying to build code with libtool 1.5 on
MacOS X.
The OS is MacOS X 10.2.6 and the compiler is built from recent gcc3.3
sources. The linker is the system ld.
The following are extracts from the build log for the libojc directory of
our project. What is shown
* Michel LESPINASSE <[EMAIL PROTECTED]> [20021009 19:57]:
> On Wed, Oct 09, 2002 at 06:27:18PM -0500, Robert Boehne wrote:
> > Ok, let me see if I understand this one,
> > under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
> > to the CFLAGS explicitly, and configured with --ena
On Wed, Oct 09, 2002 at 06:27:18PM -0500, Robert Boehne wrote:
> Ok, let me see if I understand this one,
> under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
> to the CFLAGS explicitly, and configured with --enable-shared ??
The package adds -prefer-non-pic to the CFLAGS unco
Ok, let me see if I understand this one,
under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
to the CFLAGS explicitly, and configured with --enable-shared ??
What platforms (aside from Alpha & RS/6000) does this work on?
--
Robert Boehne Software Engineer
Ricardo
On Wed, Oct 09, 2002 at 02:57:39PM -0500, Robert Boehne wrote:
> I intend to spin a release 1.4.3 this weekend from the branch-1-4
> sources.
There is a bug in libtool 1.4.2 when using -prefer-non-pic on hppa:
libtool does not pass the -fPIC flag, and then the linker complains
about that. Alexand
Hi Robert,
On Wed, Oct 09, 2002 at 02:57:39PM -0500, Robert Boehne wrote:
> I intend to spin a release 1.4.3 this weekend from the
> branch-1-4 sources. Any properly formatted patches will
> be considered for inclusion before the release. I have
> seen a tendency to post patches on any list in
All,
I intend to spin a release 1.4.3 this weekend from the
branch-1-4 sources. Any properly formatted patches will
be considered for inclusion before the release. I have
seen a tendency to post patches on any list in any
format, which makes it more work to get that particular
patch installed i
On Wed, Oct 09, 2002 at 12:29:44PM -0500, Bob Friesenhahn wrote:
> On Wed, 9 Oct 2002, Guido Draheim wrote:
>
> > > In my experience, the 1.5 code-base is a solid product on systems
> > > supported by 1.4.2, and provided that it is patched and proven to work
> > > under MinGW and Darwin then 1.5
On Wed, 9 Oct 2002, Guido Draheim wrote:
> > In my experience, the 1.5 code-base is a solid product on systems
> > supported by 1.4.2, and provided that it is patched and proven to work
> > under MinGW and Darwin then 1.5 should be ready to release.
> >
>
> That's another argument. And since it w
Bob Friesenhahn wrote:
> Time spent on libtool 1.4.3 is time spent doing work which must
> either be done a second time, or has already been done, for libtool
> 1.5.
Not true. There were some patches backported even before now,
I was doing some of the work under the expectation that we
After seeing what has happened with Autoconf, and given the current
state of libtool, I recommend that the focus of libtool development be
to produce a libtool 1.5 as soon as possible and not spend time
producing a libtool 1.4.3.
Time spent on libtool 1.4.3 is time spent doing work which must
89 matches
Mail list logo
