On Thu, 7 Nov 2002, Charles Wilson wrote:
> Since autoconf (>= 2.56) will only work on systems whose shells support
> shell functions, and libtool requires autoconf, then libtool will only
> work on those same systems. Which means shell functions are available
> and we *can* use them. Whether we
Bob Friesenhahn wrote:
"Shall libtool-1.5 require autoconf-2.56?"
I don't see that introducing shell functions into libtool has any
bearing on the version of autoconf that libtool requires.
The argument you pose is political rather than technical.
Yes. The decision itself is a political
All,
Hey, that's a relief, now we don't have to deal with this
issue anymore. I would be in favor of a) leaving the
shell functions in place, and b) making use of them more.
Thanks,
Robert
Bruce Korb wrote:
>
> Alexandre Duret-Lutz wrote:
>
> > Bruce> ... 20 year old shells are [not] too o
On Thu, 7 Nov 2002, Charles Wilson wrote:
> When will libtool-1.5 be released? Before or after ac-2.56? (given
> that ac-2.55 will be released next week).
>
> Assuming that the autoconf people have not repudiated their plan to
> integrate shell functions starting in 2.56, then the decision to us
This afternoon I received some 60 email messages from various libtool
lists. One of them was dated October 4!
Can someone explain why the list server is so unreliable.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
On the other hand, autoconf's most recent release sez (as ADL pointed
out before I finished composing this message):
** Plans for 2.56
...
- shell functions
Shell functions will gradually be introduced, probably starting with
Autotest. If yo
My experience with developing software is that unless software has
been tested, it is unlikely to actually work. While we may pretend
that libtool supports 20 year old systems, the reality is that no one
is testing to verify that libtool can actually execute on these
systems. Exceedingly few of t
On Thu, 7 Nov 2002, Bruce Korb wrote:
> Alexandre Duret-Lutz wrote:
>
> > Bruce> ... 20 year old shells are [not] too old for continued
> > Bruce> support. Ick. How completely disgusting.
> >
> > Cheer up and read the Autoconf 2.54c announcement entirely :)
>
> You're right. I only read the f
Alexandre Duret-Lutz wrote:
> Bruce> ... 20 year old shells are [not] too old for continued
> Bruce> support. Ick. How completely disgusting.
>
> Cheer up and read the Autoconf 2.54c announcement entirely :)
You're right. I only read the first 100 lines or so. :-)
This is a decade overdue.
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes:
[...]
Bruce> neither Autoconf nor Libtool want to be the first to say
Bruce> that 20 year old shells are too old for continued
Bruce> support. Ick. How completely disgusting.
Cheer up and read the Autoconf 2.54c announcement entirely :)
"Boehne, Robert" wrote:
>
>Part 1.1Type: Plain Text (text/plain)
> Jan,
>
> That actually brings up a big issue. I *assumed* that the win32 patches
> using shell functions that were checked in would only have shell functions
> when running under windows. I later saw this was not the case.
Boehne, Robert wrote:
and any WIN32 specific code can be only
included
when WIN32 is detected at run time
(via ". some_here_document_containing_win32_shellfuncs")
Until all the Autotool maintainers decide to abandon support for
non-shell function
bourne shells we need to support them as well.
Title: [shell functions, was RE: solving of name conflicts in included .a]
Jan,
That actually brings up a big issue. I *assumed* that the win32 patches
using shell functions that were checked in would only have shell functions
when running under windows. I later saw this was not the case.
hello.
no one responded to my question regarding internal dependencies. i'd
really appreciate some guidance on this issue.
on GNU/Linux, if i have a package comprised of libfoo.so and
libfoo-internal.so. i want applications to link only against libfoo.so,
since the libfoo-internal.so interface m
14 matches
Mail list logo
