> libtool is taking 30-40s to execute on my 366MHz iBook running Mac OS X,
> compared with approx. 2s on my 166MHz x86 running Linux, and I'm pretty
> sure it was even quicker still on my iBook when *that* was running Linux,
> so:
>
> Is it just me & mine, or is there some reason libtool is very
There is a problem with the way autoconf 2.50 (as well as current
CVS HEAD) schedules AC_PROG_CXX and AC_PROG_CXXCPP if both are
AC_REQUIRE'd.
libtool.m4 has
AC_DEFUN([_LT_AC_LANG_CXX],
[AC_REQUIRE([AC_PROG_CXX])
AC_REQUIRE([AC_PROG_CXXCPP])
])# _LT_AC_LANG_CXX
but autoconf generates a configur
> My reflex reaction is to say that this probably isn't supported
> by libtool, but then I have very little practical cross compilation
> know-how.
My first thought that was this is really GCC's job - its specs file
tells it what start/end files to link with. So if it's a "real"
cross-compilat
On Fri, 2001-10-05 at 07:14, Ian Peters wrote:
> Unfortunately, with libtool 1.4.x, I get this instead (after a much,
> much longer time):
>
> gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o
> [snip]
> installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic
>
> > I'd say a bug, since options libtool doesn't handle itself are moved
> > around when they shouldn't be.
>
> Suck, that was what I was afraid of. Any workarounds?
None, I'm afraid. From a quick glance, it seems libtool (well,
ltmain.sh)
collects compiler/linker options in one list, and obje
> >> > it is probably still worth mentioning in the autoconf manual's
> >> > section on portable shell programming.
> >>
> >> Yes, that makes sense.
>
> Tim> I'll whip up something tomorrow.
>
> Hi Tim! ;)
Hi Akim!
As you well know, time is a relative concept (in fact, to me it's
yesterday at
Something like this, perhaps?
2001-10-21 Tim Van Holder <[EMAIL PROTECTED]>
* doc/autoconf.texi: Mention the issue of bash 2.05's
`set' builtin.
Index: doc/autoconf.texi
===
RCS file: /
> >>>>> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
>
> Tim> Something like this, perhaps?
>
> For sure!
>
OK - installed (this may be resolved in bash 2.06; if so, I'll try to
remember to amend this entry accordingly).
__
I asked about this a whil ago, but since I didn't receive any
comments, I'm asking again.
bash's behaviour with regards to the 'set' builtin has changed
in 2.05:
> 3. New Features in Bash
>
> b. When `set' is called without options, it prints function
> defintions in a way that allows the
> Why is this broken?
I was only relaying a problem someone else reported; it seemed odd
to me, but without 2.05 lying around, I couldn't test it.
> It's true that you can't parse the latter line with other shells.
> So perhaps what you're saying is that, if you use Bash 2.05 to
> run 'configure
Ralf Wildenhues wrote:
>> - [LIBTOOL] by default, the compilers require that files come last on
>> the command line, and many versions of libtool (including the one
>> included with GMP) break this rule when configure has determined -c
>> and -o can both be used (it puts the -o last). To work
[cc'ing the libtool list because of the issues marked [LIBTOOL] below;
these may or may not already be resolved in more recent libtools - the
version included with gmp is 1.5.6 according to ltmain.sh (1.220.2.94)]
I just finished building gmp 4.2.1 under OpenMVS ("370-ibm-openedition",
the Unixy s
Ralf Wildenhues wrote:
> * Tim Van Holder wrote on Fri, Jul 13, 2007 at 04:11:43PM CEST:
>> Ralf Wildenhues wrote:
>>>> - [LIBTOOL] by default, the compilers require that files come last on
>>>> the command line, and many versions of libtool (including the on
Ralf Wildenhues wrote:
> * Tim Van Holder wrote on Tue, Jul 17, 2007 at 08:57:56AM CEST:
> [...]
>> Both compiles and links are affected.
>>
>> For the linking, automake puts the -o at the end itself, so it is
>> at least partially to blame. Then again, libtool do
On Wed, 2002-02-13 at 03:01, Ted Irons wrote:
> We are using cygwin (1.3.9) with fltk-1.1 on a
> Windows NT machine.
>
> Our C++ package uses autoconf, automake, and
> libtool to maintain the build system.
> CXXFLAGS contains -DWIN32.
> LDFLAGS contains -no-undefined and -mwindows.
> configure.ac
> On Tue, 2002-04-02 at 08:45, Grzegorz Jakacki wrote:
> >
> > Hi,
> >
> > Why is there so much spam on [EMAIL PROTECTED]? Is there
> anybody blocking
> > spammers?
>
> Mailman allows filtering of messages only on headers, so a lot of spam
> gets through. Since traffic on [EMAIL PROTECTED] is
em not to match a backslash if it is not doubled.
Also, since this is probably an 'is_absolute' check, it should really be
[\\/]* | ?:[\\/]* ) (cfr the File System Conventions chapter in
the autoconf manual's portability section).
--
Tim Van Holder <[EMAIL PROTECTED]>
d
to use 'aclocal -I m4' or something similar so that aclocal will find
and use the libtool macros.
--
Tim Van Holder <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
ap
should do it.
--
Tim Van Holder <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Bill Jones wrote:
So the basic question is how do I specify a static import library with a
*.lib extension to be used by libtool for resolving the symbols provided
by a non-libtool DLL when building a dependent DLL with libtool?
The trivial solution is of course to make a copy of the third-party
Bob Friesenhahn wrote:
On Wed, 14 Apr 2004, Earnie Boyd wrote:
>
So all that is needed is for libtool to accept .lib as an extension
and for libtool to (possibly naively) assume that if a similarly-named
DLL exists that the .lib file is a DLL link library?
Yes and no. For one thing, there is no r
21 matches
Mail list logo
