> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> I have been using AM_ENABLE_SHARED(no) AM_ENABLE_STATIC(yes)
Bob> AC_PROG_LIBTOOL
Will probably disappear if you move to AC_, not AM_. Untested.
> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes:
>> configure.in:35: warning: The macro `AC_OUTPUT_COMMANDS' is
>> obsolete. You should run autoupdate. configure.in: 33:
>> `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
>> configure.in:50: warning: The macro `AC_LANG_C' is o
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Apr 4, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>>>>>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]>
>>>>>>&
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Hmm. I'm pretty sure autoconf 2.13 set target to "NONE".
Yes, it did, definitely. But it makes the code much simpler not to
give a default value. Now, if you think this is the beginning of
troubles, we might change it back :(
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Gary> Hmm. I'm pretty sure autoconf 2.13 set target to "NONE".
Akim> Yes, it did, definitely.
Gary> Nup. No problem with the change here.
Alexandre> I think I've alread
| So, here's the "fix". However, this is not very robust, and the real
| problem with the AC_REQUIRE diversions needs to be fixed.
The patch is in the queue.
| +AC_DEFUN(AC_PROG_LIBTOOL,[AC_REQUIRE([_AC_PROG_LIBTOOL])
| +# If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX
| +# immediately, otherwise, hook it in at the end of AC_PROG_CXX.
| + AC_PROVIDE_IFELSE([AC_PROG_CXX],
| +[AC_LIBTOOL_CXX],
| +[define([AC_PROG_CXX], defn([AC_PR
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> I've just thought of a way to avoid any compatibility
Alexandre> problems between libtool components: embedding ltconfig,
Alexandre> ltmain.sh and ltcf-*.sh in libtool.m4. AC_PROG_LIBTOOL
Alexandre> would extract ltconfi
| On Thu, Sep 07, 2000 at 02:12:34PM -0400, Pavel Roskin wrote:
| > -
| > However, in a few places the macros need to use brackets (usually in C
| > program text or regular expressions). In those places, they use the `m4'
| > builtin command `changequote' to temporarily change the qu
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> I'm fixed now :-)
:)
Pavel> I'll try to remove changequote()s from libtool.m4 as long as it
Pavel> remains compatible with Autoconf-2.13
This is totally independent from the Autoconf release.
| On Oct 11, 2000, Morten Eriksen <[EMAIL PROTECTED]> wrote:
| > Autoconf straight out of CVS will complain about "backquotes and
| > doublequotes should not be backslashed" when expanding the macro code
| > of _LT_AC_LTCONFIG_HACK libtool.m4.
|
| The problem is that CVS autoconf changes the way
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> I'm definitely in favor of this change.
OK< I consider this an OK and will apply the change directly.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/li
> "Matthias" == Matthias Koeppe <[EMAIL PROTECTED]> writes:
Matthias> There was also a bunch of missing quotes around `test'
Matthias> arguments in the scripts, which confused /bin/test on
Matthias> Solaris 2.7 boxes.
Could you give some more details on this problem? IMHO, these
variables s
In Autoconf, the words which include _A?_, A?_, _m4_, m4_ are
forbidden, in order to diagnose unexpanded macros. There is
(currently) no escape to this rule.
But then we have a conflict for Libtool for:
~/src/libtool % ace nostromo 15:58
configure:5
> "Bernard" == Bernard Dautrevaux <[EMAIL PROTECTED]> writes:
Bernard> Whar is AS_xxx used for in autoconf?
Autoshell, see m4sh.m4.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello, Akim!
>> In Autoconf, the words which include _A?_, A?_, _m4_, m4_ are
>> forbidden, in order to diagnose unexpanded macros. There is
>> (currently) no escape to this rule.
Pavel> Not _m4_.
Then we should, shouldn't we? N
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> I'd rather take almost the full range and except AR if we need to.
Alexandre> I'd prefer that the maintainers of autoconf weren't so
Alexandre> greedy about prefixes :-)
In fact my position (let's take the full range) is also b
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Nov 6, 2000, Earnie Boyd <[EMAIL PROTECTED]> wrote:
>> Why not just prefix the reserved autoconf variables with a `_'
>> character?
Alexandre> autoconf used to use just AC_/ac_. Now, it's claiming
Alexandre> ownershi
> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
Earnie> But, neither of you answered my question. Why not use `_' to
Earnie> prefix A?_* names? You can then declare that the user is
Earnie> incorrect as _A?_* is a vendor variable! I as a user should
Earnie> be allowed to declare A?_
I'm happy to say that running the test suites of both Libtools and of
Automake with CVS Autoconf works fine.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
+*djgpp*)
+ # DJGPP does not support shared libraries at all
+ ac_cv_prog_cc_pic=
+ ;;
Aah! Libtool uses the ac_ name space??? That's quite risky...
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listin
>>>>> "Raja" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Raja> Hi, Akim Demaille <[EMAIL PROTECTED]> writes:
>> I'm happy to say that running the test suites of both Libtools and
>> of Automake with CVS Autoconf works fine.
Raja> Th
> "Raja" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Raja> OK. But, this problem isn't due to the redefining. I can
Raja> repeat it with
Raja> AC_INIT AC_PROG_CXXCPP AC_OUTPUT
Ah ah! Thanks!
___
Libtool mailing list
[EMAIL PROTECTED]
http
The following message is a courtesy copy of an article
that has been posted to gnu.utils.bug as well.
The Autoconf team is extremely proud (and quite relieved) to announce
the birth of Autoconf 2.49c, our release candidate. The core Autoconf
is not expected to change before the release, while t
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> Ok, I changed AC_CANNONICAL_HOST to AC_CANNONICAL_SYSTEM in
Robert> configure.ac and it works. However, this doesn't appear to be
Robert> the 'proper' fix because AC_CANNONICAL_SYSTEM is obsolete. I
Robert> also have tried AC_C
The Autoconf team is extremely proud (and quite relieved) to announce
the release of Autoconf 2.50. As can be guessed from the NEWS excerpt
below, profound changes have been made in order to provide a more
coherent interface and more user-friendly macros.
Autoconf can be downloaded from
Hi People!
I'm looking for information on the portability of find(1). Please,
send me everything you know. In particular, I think I'm understanding
that `{}' is portably replaced by the argument only when alone, i.e.,
exactly
find ... {} ...
and not
find ... "foo: \{\}" ...
>> sprintf (filename, "%.*s/%s", (int) dirname_len, dirname, dlname);
Given that the rest of ltdl uses strcpy and strcat, I fail to
understand the presence of this sprintf.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinf
> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
Kevin> On an sv1-cray-unicos10.0.0.X with the cvs libtool I noticed
Kevin> the following error,
Kevin> configure: creating libtool sed: 1:
Kevin> "s/[-_ABCDEFGHIJKLMNOPQR ...": RE error: [ ] imbalance or
Kevin> syntax error appendin
>>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> From: Akim Demaille <[EMAIL PROTECTED]> Date: 04 Oct 2001 17:38:43
>> +0200
>>
>> some of our parts would be extremely happy to have as good a shell
>> as possible. For
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
>> > 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! ;)
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
Tim> Something like this, perhaps?
For sure!
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Hi all,
My project builds many libraries and some modules. I've just started
using ltdl in it, with a non-recursive build. As a result,
I have inherited the following line in my single Makefile:
AM_LDFLAGS += -no-undefined
so my libraries now fail to link. Is this on purpose?
Shou
Hi Bob!
Le 8 avr. 2014 à 16:28, Bob Friesenhahn a écrit :
> On Tue, 8 Apr 2014, Akim Demaille wrote:
>
> This option is necessary in order to build DLLs under Windows (and likely
> shared libraries under AIX).
I do understand it is needed on some platforms, but I
don't ai
Le 8 avr. 2014 à 19:01, Bob Friesenhahn a écrit :
> Libltdl is likely managed by a package manager on the system since it is a
> common component on any GNU/Linux system and other free systems. By embedding
> libltdl in some other application or library, the users of that application
> or lib
Hi friends,
I'm trying to use -fsanitize=address on OS X using MacPorts' Clang++ 3.5.
The project consists of C++ libraries, on top of which is built a Python
module (with a thin C++ layer which needs to be compiled). Libtool
(2.4.2 - the name of a fine belgian band of electronic music btw)
is us
Le 17 mai 2014 à 03:36, Peter Rosin a écrit :
> Hi!
Hi Peter,
Thanks for the answer!
>> My other libraries, which are not modules, are linked properly though.
>> For instance (the only relevant part is that -fsanitize is not stripped
>> from the command passed to the linker):
>
> This part I
Hi!
I have a library that, when loading, invokes functions in the main application.
So dependencies are really resolved in reverse: the main program does not
"need" the libraries, it is the libraries that use the main program to inform
it that they are there.
In such a case, some distros, suc
Now that there are no doubts about the portability of shell functions
(in the sense that there's always a shell on the machine that supports
function ---and maybe the documentation should reflect this), I'm
curious about the support of "return" and "local". Is there anything
known about them? IS
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> "local" isn't in POSIX so I'd avoid it in portable scripts.
Doh. Thanks.
> For what it's worth, I briefly searched for this issue and found these
> bug reports dated this year where someone used "local" in a shell
> script and someone
>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
> Akim Demaille <[EMAIL PROTECTED]> writes:
>> if (local foo) >/dev/null 2>&1; then :; else
>> local () { true; }
>> fi
> Note that local is only valid in funct
[Please keep me in CC.]
Hi,
I'm trying to build a convenience library, install it, build another
convenience library on top of it (and again install it), and finally
link an executable using the latter library.
I thought I could do that using Libtool static libraries with
extension .la, but it
>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Hello Akim,
> * Akim Demaille wrote on Fri, Sep 29, 2006 at 10:41:36AM CEST:
>>
>> I'm trying to build a convenience library, install it, build another
>> convenience li
>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
Thanks Ralf,
> (The only system it won't work on then is w32 with MSVC with the
> LIB archiver instead of ar.)
Bummer. But I'm not surprised :)
> Hmm. By default the
> libtool --mode=link $CC -o liba.a a.lo
> will choose the no
Hi!
There must be something not going too well in the AC_REQUIRES of
ltld. In the attached configure.ac, some macros are issued out of
order, which results in, for instance, shrext_cmds being used before
its definition:
$ grep -E 'shrext|If you need' configure
eval libltdl_cv_shlibext=$
Hi friends,
It's cold, the win32ter's back, and I'm a lonely winderer in the
winderful country to losedows.
As you suggested, I'm moved from pw32 to ming32, and as a result, I
now have a "wrapper.exe" instead of a shell script "wrapper". This is
wonderful news, since I was wasting a lot
Le 21 déc. 08 à 17:49, Ralf Wildenhues a écrit :
Hi Akim,
Hi Ralf!
* Akim Demaille wrote on Fri, Dec 19, 2008 at 11:41:34AM CET:
Yet I have a slight problem: for some reason the top-level wrapper
(lt-
cli.exe in my case) tries to launch .libs/lt-cli.exe, which does not
exist. What does
Le 29 déc. 08 à 22:55, Ralf Wildenhues a écrit :
Hi Akim,
* Akim Demaille wrote on Fri, Dec 12, 2008 at 11:17:08AM CET:
There must be something not going too well in the AC_REQUIRES of
ltld.
In the attached configure.ac, some macros are issued out of order,
which
results in, for
[Resending this email because it has been refused from several places,
apparently because the attachment triggers virus-detectors for
whatever reason. Hopefully tz2 should be ok.]
Le 19 avr. 09 à 18:29, tsuna a écrit :
(catching up on some super old emails)
On Wed, Jan 7, 2009 at 8:07 PM,
002 18:44:16 - 1.1829
**
2002-01-24 Akim Demaille <[EMAIL PROTECTED]>
Version 2.52g.
2002-01-24 Akim Demaille <[EMAIL PROTECTED]>
* bin/autoheader.in, bin/autoconf.in, bin/autoscan.in,
* doc/autoconf.texi: Finally add Akim as an author.
20
> "Ilya" == Ilya Shlyakhter <[EMAIL PROTECTED]> writes:
Ilya> Hello, I've converted my project to use libtool, and it compiles
Ilya> fine but doing "make distcheck" fails saying that after make
Ilya> distclean, files are left. I'm on cygwin and the only file left
Ilya> is called "a.exe". Wh
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> Unfortuntely, autoconf 2.52 does not define 'Java' as a language.
Per> But that can probably be worked around.
Autoconf 2.52+ would be most happy to support Java.
___
Libtool mailing list
[EM
The Autoconf team is extremely pleased to announce Autoconf 2.53. We
hope it will address your problems, and make your life easier.
Enjoy!
Akim, Alexandre, Jim, Paul, Tom.
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.53.tar.gz (973 kB)
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.53.t
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> Perhaps we could start by defining some or all of AC_PROG_GCJ,
Per> AC_PROG_JAVAC (the .java->.class compiler), and AC_PROG_JAVA (the
Per> Java .class file "interpreter"). Or perhaps there could be a
Per> AC_JAVA that subsumes all three
> "Patrick" == Patrick Guio <[EMAIL PROTECTED]> writes:
Patrick> If I just "touch configure" then everything is running ok
Patrick> again. I am not sure which of the package is generating this
Patrick> trouble nut is there any policy/strategy of using
Patrick> configuration tool together with
| Am Mon, 2002-09-23 um 10.49 schrieb Alexandre Duret-Lutz:
| > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html
| >
| > Ralf> .. which seems to indicate that libtool is the culprit.
|
> "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes:
Ralf> .. still nobody wanting to care to fix it?
>> AFAICT it's fixed in CVS Libtool.
Roger> And in Debian.
Am I crazy suggesting that Debian Libtool be the next Libtool release?
___
Libtool m
| Alexandre Duret-Lutz wrote:
| > Bruce> My preference would be this:
| >
| > Could you send this to the list?
|
| Alright:
|
| I would really like to see the auto* tools packages (autoconf,
| automake and libtool) each adopt several of their worst
| clients' packages for regression testing.
| > I have not read all the details yet, but does anybody know what we
| > must do to cope with Libtool 1.4.2?
|
| How about this patch to Autoconf? It should let us limp along until a
| new libtool version is published.
|
| --- old/BUGS 2002-03-26 08:14:37.0 -0800
| +++ new/BUGS 200
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> Wouldn't it be better to get libtool 1.5 out the door? The
Bob> resources required to achieve a releasable product are similar
Bob> and CVS libtool already contains most of the fixes that would go
Bob> into a 1.4.3.
There is one bi
> "Sascha" == Sascha Schumann <[EMAIL PROTECTED]> writes:
Sascha> We use it for the PHP project (>80k lines configure script),
Sascha> because 2.5x is 5 to 6 times slower
That's because it does provide a better service too :( I have timed a
lot of the code, and I can tell that we're hittin
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Great thread people! I'm happy to see you're alive :)
Russ> There were a variety of reasons for breaking backward
Russ> compatibility, like choosing to clean up quoting, but that's a
Russ> justification for doing it, not an argument that
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> Ok, So a 1.4.3 version is desired, that's established. The
Robert> million-dollar question is: Does current branch-1-4 Libtool do
Robert> the trick?
Robert> If so, then a roll out could be done within the week.
I would like to
| > Sascha> and contains a dependency-ignorant cache system.
| >
| > What do you mean?
|
| Each of PHP's bundled extensions has a config.m4 which can be
| maintained separately. Autoconf 2.50 and later insert stale
| code into configure, when such a config.m4 file changes.
You want
| > You want autoconf -f then.
| -f, --force consider all files obsolete
|
| We do a ./cvsclean right now for autoconf +2.50 which purges
| all generated data. I guess that is basically the same.
|
| > You know, you are typically the kind of people who has valid grieve
ions, please run the test suite of
Autoconf 2.55 on it, and report the results to
[EMAIL PROTECTED]
ChangeLog entries:
2002-10-25 Akim Demaille <[EMAIL PROTECTED]>
Version 2.54a.
* Makefile.maint: Update from the Coreutils.
(AMTAR): Remove, obsolete.
(autom
ChangeLog 4 Nov 2002 08:47:39 - 1.2092
**
2002-11-04 Akim Demaille <[EMAIL PROTECTED]>
Version 2.54c.
* Makefile.maint (update, cvs-update, po-update, do-po-update):
New.
I fyou look at the current tarball of GNU M4, located here:
http://www.lrde.epita.fr/~akim/download/m4-1.4q.tar.gz or .bz2
you'll see that make distcheck fails, while make check passes.
distcheck fails in a simple way, corresponding to this:
~/src/m4/m4-1.4q/=build/tests % echo 'esyscm
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> All, Hey, that's a relief, now we don't have to deal with this
Robert> issue anymore. I would be in favor of a) leaving the shell
Robert> functions in place, and b) making use of them more.
I don't agree. Autoconf does not use
The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the birth of Autoconf 2.55. Download, compile, install,
torture, and enjoy!
- Why should I upgrade from 2.54?
A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming Gettex
Bruce> Bootstrap-Bash could use a frozen version of configure.
This means freezing at least one copy of Bash. Doable.
But I still think it might be a bit too soon. I don't see the urgency
to move to shell functions, but I do see how they can simplify our
lives.
The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the birth of Autoconf 2.56, aka 2.55 with a packaging
problem fixed.
- Why should I upgrade from 2.54?
A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming Gettext release
NEWS
* Major changes in Autoconf 2.57d
* Major changes in Autoconf 2.57b
Released 2003-08-24, by Akim Demaille.
** Autotest and local.at
The optional file local.at is always included in Autotest test suites.
** Warnings
The warnings are always issued, including with cached runs.
This be
Released 2003-10-01, by Akim Demaille.
* Major changes in Autoconf 2.57e
Released 2003-09-29, by Akim Demaille.
** AC_CONFIG_COMMANDS
The directory for its first argument is automatically created. For
instance, with
AC_CONFIG_COMMANDS([src/modules.hh], [...])
$top_builddir/src
I'm not sure I understand how interlib deps are expected to work.
In a project of mine, I have several directories containing
libs. For instance, in the ast/ directory I have the following
Makefile.am snippet:
noinst_LTLIBRARIES = libast.la
libast_la_SOURCES = \
Le 4 déc. 04, à 16:21, Bob Friesenhahn a écrit :
libast_la_LIBADD=../symbol/libsymbol.la ../task/libtask.la \
../misc/libmisc.la
Does that help?
But it results in libast containing all the other libraries.
I tried to avoid that.
___
Libtool mailing lis
Le 4 déc. 04, à 18:13, Bob Friesenhahn a écrit :
On Sat, 4 Dec 2004, Akim Demaille wrote:
Le 4 déc. 04, à 16:21, Bob Friesenhahn a écrit :
libast_la_LIBADD=../symbol/libsymbol.la ../task/libtask.la \
../misc/libmisc.la
Does that help?
But it results in libast containing all the other libraries
I'm not sure I understand correctly what -static means for
programs. My understanding is that during the build, libraries
against which the program is linked are statically linked
if there are not installed *now*. Reading the documentation, it is
somewhat unclear to me whether it refers to librar
This message
(http://lists.gnu.org/archive/html/libtool/2004-12/msg00263.html)
is left without answer. I am quite stuck currently. It seems
to me that it is due to a CVS libtool bug on Darwin, but I have
received no confirmation.
The original message includes a test case.
Thanks!
I'm not sure I
Le 4 janv. 05, à 00:02, Peter O'Gorman a écrit :
Hi Akim,
Hi!
I have no idea what is supposed to happen in this situation. You have
specified that static libraries should not be built and also asked that
executables be statically linked against not-yet-installed libraries.
Right.
If you
configure w
80 matches
Mail list logo
