Prevent libtool from moving flags

[Akim Demaille]

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, such as Ubuntu, will completely drop the 
dependency on the library.  The workaround is well known: use 
-Wl,--no-as-needed.

Unfortunately, libtool moves the options around, and since 
-Wl,--(no-)?-as-needed applies to the libraries that are _after_ it, the result 
is disastrous:

# ./libtool --tag=CXX --mode=link g++-4.9 -Xlinker --no-as-needed 
-Wl,--no-as-needed -g -O2 -std=c++14 -avoid-version -module 
-L/usr/lib/python3.4/config-3.4m-x86_64-linux-gnu -L/usr/lib -lpthread -ldl  
-lutil -lm  -lpython3.4m -Xlinker -export-dynamic -Wl,-O1 
-Wl,-Bsymbolic-functions -o python/vcsn_cxx.la -rpath 
/usr/local/lib/python3.4/site-packages python/python_vcsn_cxx_la-vcsn_cxx.lo 
-lboost_python-py34 -lpthread -ldl  -lutil -lm  -lpython3.4m 
lib/liblal_char_b.la  lib/liblal_char_q.la  lib/liblal_char_z.la lib/libvcsn.la
libtool: warning: 
'/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libltdl.la' seems 
to be moved
libtool: link: rm -fr  python/.libs/vcsn_cxx.la python/.libs/vcsn_cxx.lai 
python/.libs/vcsn_cxx.so
libtool: link: g++-4.9  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginS.o  
python/.libs/python_vcsn_cxx_la-vcsn_cxx.o   -Wl,-rpath 
-Wl,/build/vcsn/_build/lib/.libs -Wl,-rpath -Wl,/usr/local/lib/vcsn 
-L/usr/lib/python3.4/config-3.4m-x86_64-linux-gnu -L/usr/lib 
-lboost_python-py34 -lpthread -lutil -lpython3.4m lib/.libs/liblal_char_b.so 
lib/.libs/liblal_char_q.so lib/.libs/liblal_char_z.so lib/.libs/libvcsn.so 
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu 
-lboost_filesystem -lboost_system /usr/lib/x86_64-linux-gnu/libltdl.so -ldl 
-lrt -L/usr/lib/gcc/x86_64-linux-gnu/4.9 
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -lstdc++ -lm -lc -lgcc_s 
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn
 .o  -Wl,--no-as-needed -Wl,--no-as-needed -g -O2 -Wl,-export-dynamic -Wl,-O1 
-Wl,-Bsymbolic-functions   -pthread -Wl,-soname -Wl,vcsn_cxx.so -o 
python/.libs/vcsn_cxx.so
libtool: link: ( cd "python/.libs" && rm -f "vcsn_cxx.la" && ln -s 
"../vcsn_cxx.la" "vcsn_cxx.la" )

So basically:

$ libtool --tag=CXX --mode=link g++-4.9 -Wl,--no-as-needed lib/liblal_char_b.la 
...

becomes

$ g++-4.9 lib/liblal_char_b.la...  -Wl,--no-as-needed

so -Wl,--no-as-needed has no effects, it is too late.

I have read the faq, and I do know that there is a workaround: "./configure 
CXX='g++ -Wl,--no-as-needed'", and yes it works.  But I meant to say that it 
would be nice if options could stay where they are :)

Cheers!
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool and ASAN

[Akim Demaille]

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 don't understand, is there perhaps a -fsanitize in one of the
> dependent .la files?

Yes, probably.  I've not looked into the details to
know what has happened though.

>> Thanks for reading (the English parts of this message :)!
> 
> This last part is an FAQ:
> 
> http://www.gnu.org/software/libtool/manual/libtool.html#FAQ

Bummer, that's even the only FAQ :)  I would suggest adding
common dropped options in there, such as -f, so that a
search would find it.

Thanks again.
___
https://lists.gnu.org/mailman/listinfo/libtool

Libtool and ASAN

[Akim Demaille]

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 used in all layers.

To enable ASAN, I add '-fsanitize=address' to my CXXFLAGS.  It works well
except for the C++ part of the Python module:

> akim@erebus ~/src/lrde/vaucanson2 $ make -C _build/35d python/vcsn_cxx.la V=1
> /bin/sh ./libtool  --tag=CXX   --mode=link ccache clang++-mp-3.5 -Wall 
> -Wextra -Wcast-align -Wcast-qual -Wdocumentation -Wformat 
> -Wmissing-declarations -Wno-parentheses -Woverloaded-virtual -Wpointer-arith 
> -Wwrite-strings  -Qunused-arguments -ggdb -fsanitize=address -std=c++11 
> -avoid-version -module -L/opt/local/lib -Wl,-rpath,/opt/local/lib 
> -L/opt/local/lib -o python/vcsn_cxx.la -rpath 
> /opt/gostai/lib/python2.7/site-packages python/python_vcsn_cxx_la-vcsn_cxx.lo 
> -lboost_python-mt lib/liblal_char_b.la lib/liblal_char_br.la 
> lib/liblal_char_q.la lib/liblal_char_r.la lib/liblal_char_z.la 
> lib/liblal_char_zr.la lib/liblal_char_zrr.la lib/liblan_char_b.la 
> lib/liblan_char_r.la lib/liblan_char_z.la lib/liblan_char_zr.la 
> lib/liblao_br.la lib/liblao_z.la lib/liblaw_char_b.la lib/liblaw_char_br.la 
> lib/liblaw_char_r.la lib/liblaw_char_z.la lib/liblaw_char_zr.la 
> lib/liblaw_char_zrr.la lib/libvcsn.la 
> libtool: link: rm -fr  python/.libs/vcsn_cxx.la python/.libs/vcsn_cxx.lai 
> python/.libs/vcsn_cxx.so
> libtool: link: ccache clang++-mp-3.5 -Wl,-undefined -Wl,dynamic_lookup -o 
> python/.libs/vcsn_cxx.so -bundle  python/.libs/python_vcsn_cxx_la-vcsn_cxx.o  
>  -L/opt/local/lib -lboost_python-mt lib/.libs/liblal_char_b.dylib 
> lib/.libs/liblal_char_br.dylib lib/.libs/liblal_char_q.dylib 
> lib/.libs/liblal_char_r.dylib lib/.libs/liblal_char_z.dylib 
> lib/.libs/liblal_char_zr.dylib lib/.libs/liblal_char_zrr.dylib 
> lib/.libs/liblan_char_b.dylib lib/.libs/liblan_char_r.dylib 
> lib/.libs/liblan_char_z.dylib lib/.libs/liblan_char_zr.dylib 
> lib/.libs/liblao_br.dylib lib/.libs/liblao_z.dylib 
> lib/.libs/liblaw_char_b.dylib lib/.libs/liblaw_char_br.dylib 
> lib/.libs/liblaw_char_r.dylib lib/.libs/liblaw_char_z.dylib 
> lib/.libs/liblaw_char_zr.dylib lib/.libs/liblaw_char_zrr.dylib 
> lib/.libs/libvcsn.dylib -lboost_filesystem-mt -lboost_system-mt -lltdl  
> -Wl,-rpath -Wl,/opt/local/lib  
> libtool: link: ( cd "python/.libs" && rm -f "vcsn_cxx.la" && ln -s 
> "../vcsn_cxx.la" "vcsn_cxx.la" )

What matters here is that -fsanitize=address is dropped, it is
not passed to the linker.  And I really need it:

> akim@erebus ~/src/lrde/vaucanson2 $ ./_build/35d/tests/bin/vcsn -e python -c 
> 'import vcsn'
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/Users/akim/src/lrde/vaucanson2/python/vcsn/__init__.py", line 4, in 
> 
> from vcsn_cxx import *
> ImportError: 
> dlopen(/Users/akim/src/lrde/vaucanson2/_build/35d/python/.libs/vcsn_cxx.so, 
> 2): Symbol not found: ___asan_option_detect_stack_use_after_return
>   Referenced from: 
> /Users/akim/src/lrde/vaucanson2/_build/35d/lib/.libs/liblal_char_b.0.dylib
>   Expected in: flat namespace
>  in /Users/akim/src/lrde/vaucanson2/_build/35d/lib/.libs/liblal_char_b.0.dylib

I have to use -Wc to force Libtool to pass it to the compiler used
to link (I must not use -Wl, because then it is passed to the linker
invoked by the compiler, and the linker rejects -fsanitize).

> akim@erebus ~/src/lrde/vaucanson2/_build/35d $ /bin/sh ./libtool  --tag=CXX   
> --mode=link ccache clang++-mp-3.5 -Wall -Wextra -Wcast-align -Wcast-qual 
> -Wdocumentation -Wformat -Wmissing-declarations -Wno-parentheses 
> -Woverloaded-virtual -Wpointer-arith -Wwrite-strings  -Qunused-arguments 
> -ggdb -Wc,-fsanitize=address -std=c++11 -avoid-version -module 
> -L/opt/local/lib -Wl,-rpath,/opt/local/lib -L/opt/local/lib -o 
> python/vcsn_cxx.la -rpath /opt/gostai/lib/python2.7/site-packages 
> python/python_vcsn_cxx_la-vcsn_cxx.lo -lboost_python-mt lib/liblal_char_b.la 
> lib/liblal_char_br.la lib/liblal_char_q.la lib/liblal_char_r.la 
> lib/liblal_char_z.la lib/liblal_char_zr.la lib/liblal_char_zrr.la 
> lib/liblan_char_b.la lib/liblan_char_r.la lib/liblan_char_z.la 
> lib/liblan_char_zr.la lib/liblao_br.la lib/liblao_z.la lib/liblaw_char_b.la 
> lib/liblaw_char_br.la lib/liblaw_char_r.la lib/liblaw_char_z.la 
> lib/liblaw_char_zr.la lib/liblaw_char_zrr.la lib/libvcsn.la
> libtool: link: rm -fr  python/.libs/vcsn_cxx.so.ld_QwmwqO
> libtool: link: ccache clang++-mp-3.5 -Wl,-undefined -Wl,dynamic_lookup -o 
> python/.libs/vcsn_cxx.so -bundle  python/.libs/python_vcsn_cxx_la-vcsn_cxx.o  
>  -L/opt/local/lib -lboost_python-mt lib/.libs/liblal_char_b.dylib 
> lib/.libs/liblal_char_br.dylib lib/.libs/liblal_char_q.dylib 
> lib/.libs/liblal_char_r.dylib lib/.libs/liblal_char_z.dylib 
> lib/.libs/liblal_char_zr.dylib lib/.libs/liblal_char_zrr.dy

Re: AM_LDFLAGS += -no-undefined

[Akim Demaille]

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 library may overwrite the libltdl installed by the package manager.  The 
> configure options to manage this are confusing.

OK, you have me convinced!  It would be great to have an option
to LTDL_INIT to mean "don't embed one in my project, I want to
use the installed version and fail if there is none".  Currently
one has to call AC_CHECK_HEADERS (wow, it's been a million years
since I last wrote this name :-) etc.?


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: AM_LDFLAGS += -no-undefined

[Akim Demaille]

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 aim at these.

> It expects a commitment to supply all dependency libraries at library/module 
> link time.

Which almost means additional dependencies and time spent
in relinking.  Which I try to avoid as much as possible.

> You could edit the copy of libltd/Makefile.inc in your project if it causes 
> an issue for you but there may be consequences for platforms which need it.

Yes, I know.  But still, to me it looks like something which
is probably not meant to be.  After all, it decides for the
whole package what options should be passed for all libraries.

It should rather be scoped to libltdl only, and the documentation
should emphasize the relevance of -no-undefined (which it already
does).

> GraphicsMagick uses a non-recursive build and used to build libltdl as part 
> of the build (for at least 8 years).  Even though ltdl added -no-undefined it 
> was not a problem since GraphicsMagick was intentionally using this option.
> 
> Since then, I realized that building libltdl as part of the project was 
> prohibitive, costly, and dangerous.  It was better to rely on libltdl to be a 
> formally installed dependency on the system. Now GraphicsMagick treats 
> libltdl just like any other external library and life is much improved.  I 
> would encourage any other package to not bundle libltdl and to simply 
> document that it must already be installed on the system.

What do you mean by dangerous?  In case of mixture of versions I guess?
This is probably a problem for libraries that likely to be linked in
a program that links with even more libraries.

And for "prohibitive and costly", I'd be happy too to have some details :)
It's not too big, and very fast to build (compared to the remainder
of my severely-templated C++ libraries, it is perfectly negligible).
___
https://lists.gnu.org/mailman/listinfo/libtool

AM_LDFLAGS += -no-undefined

[Akim Demaille]

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?
Shouldn't this flag be for libltdl only?  I have not seen
information about this in the documentation, but I might
have not looked correctly (I looked at occurrences of
-no-undefined and LDFLAGS).

Cheers,

Akim


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: cccl usage

[Akim Demaille]

[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, Ralf Wildenhues > wrote:

* Peter Rosin wrote on Wed, Jan 07, 2009 at 02:09:38PM CET:


Ralf, I have a vague memory of you mentioning that you knew of a
project that was using cccl to provide its Windows port, do you
remember which project that was? Is anyone else aware of any cccl
users?


Hmm.  Markus Duft started out with cccl IIRC, but quickly switched to
implementing his own program.  Benoit has made some changes to the
script, maybe he knows more (Cc:ed).


I used cccl in my previous company, the latest version when I left was
at http://tsunanet.net/~tsuna/cccl
I don't know if they still use it though.  But when I was there we
could build all our projects (including Qt-based projects) with the
autotools using the MSVC tools (cl.exe and so on).  It was very
convenient, we could build all our targets (many combinations of
compilers / architectures) in just the same way.


FWIW, we are now using the following script, installed as both cl.exe  
and link.exe.  Passing CC=CXX=cl.exe, LD=link.exe, and  
DUMPBIN='link.exe -dump -symbols'.  There does not seem to be a common  
root between the two scripts, I have no idea why.  This script maps  
Windows file names to Unix path names, so that depcomp can work  
properly (it also maps -MP and so forth in a way that pleases  
depcomp).  It uses the Perl ndbm module to save calls to winepath,  
unfortunately this modules does not support concurrent accesses, so  
this does not work properly with -j :(  The way out is certainly to  
tie the hash to an sqlite database, but this is a TODO.




link.tz2
Description: Binary data





___
http://lists.gnu.org/mailman/listinfo/libtool

Re: AC_REQUIRE hell

[Akim Demaille]

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 instance, shrext_cmds being used before its  
definition:

[...]

I have a simple work around: instead of

AC_DEFUN([URBI_LTDL], [my macro])

I have

AC_DEFUN([URBI_LTDL], [m4_fatal([should never be used])])
m4_define([URBI_LTDL], [my macro])

The first line is to have aclocal notice that the macro is defined  
in an
m4/ file, and the second is to avoid that URBI_LTDL define an  
AC_REQUIRE
boundary.  I don't remember the details, but it seems suspicious to  
me
that code using shrext_cmds is emitted before the contents of my  
macro.
Either somewhere there are m4_define that should be AC_DEFUN to  
define

the AC_REQUIRE barriers (an error in Libtool), or when a macro OUTER
invokes a macro INNER which requires REQUIRED then REQUIRED is output
before OUTER, which seems wrong to me (an error in Autoconf).


Without having tested it, this looks like another instance of
<http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/6421/focus=6429 
>.


yes, I agree it looks very much the same.

Thanks!



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool.git & cl.exe & Mingw32

[Akim Demaille]

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 exist is .libs/cli.exe (and actually it makes more
sense to me).  So I had to change libtool:


Thanks for the report.  You can make your bug reports even more  
perfect
by providing './libtool --tag=CC --config', and writing to bug- 
libtool.


Cc'd.


And, in this case, also providing --mode=link command line and output.
;-)


Sure :)

# Which release of libtool.m4 was used?
macro_version=2.2.7a
macro_revision=1.3046

# What type of objects to build.
pic_mode=default

# Whether or not to build shared libraries.
build_libtool_libs=yes

# Whether or not to build static libraries.
build_old_libs=no

# Assembler program.
AS=as

# DLL creation program.
DLLTOOL=false

# Object dumper program.
OBJDUMP=objdump

# Whether or not to optimize for fast installation.
fast_install=yes

# Shell to use when invoking shell scripts.
SHELL="/bin/sh"

# An echo program that protects backslashes.
ECHO="printf %s\\n"

# The host system.
host_alias=mingw32
host=i386-pc-mingw32
host_os=mingw32

# The build system.
build_alias=
build=i686-pc-linux-gnu
build_os=linux-gnu

# A sed program that does not truncate output.
SED="/bin/sed"

# Sed that helps us avoid accidentally triggering echo(1) options like -n.
Xsed="$SED -e 1s/^X//"

# A grep program that handles long lines.
GREP="/bin/grep"

# An ERE matcher.
EGREP="/bin/grep -E"

# A literal string matcher.
FGREP="/bin/grep -F"

# A BSD- or MS-compatible name lister.
NM="/home/build/.wine/dosdevices/c:/vcxx8/VC/bin/link.exe -dump -symbols"

# Whether we need soft or hard links.
LN_S="ln -s"

# What is the maximum length of a command?
max_cmd_len=98304

# Object file suffix (normally "o").
objext=obj

# Executable file suffix (normally "").
exeext=

# whether the shell understands "unset".
lt_unset=unset

# turn spaces into newlines.
SP2NL="tr \\040 \\012"

# turn newlines into spaces.
NL2SP="tr \\015\\012 \\040\\040"

# How to create reloadable object files.
reload_flag=" -r"
reload_cmds="\$LD\$reload_flag -o \$output\$reload_objs"

# Method to check whether dependent libraries are shared objects.
#deplibs_check_method="file_magic ^x86 archive import|^x86 DLL"
deplibs_check_method=pass_all

# Command to use when deplibs_check_method == "file_magic".
file_magic_cmd="func_win32_libid"

# The archiver.
AR="lib.exe"
AR_FLAGS="cru"

# A symbol stripping program.
STRIP="strip"

# Commands used to install an old-style archive.
RANLIB=":"
old_postinstall_cmds="chmod 644 \$oldlib~\$RANLIB \$oldlib"
old_postuninstall_cmds=""

# A C compiler.
LTCC="cl.exe"

# LTCC compiler flags.
LTCFLAGS="-g -O3"

# Take the output of nm and produce a listing of raw symbols and C names.
global_symbol_pipe="gawk ' {last_section=section; section=\$ 3}; 
/Section length .*#relocs.*(pick any)/{hide[last_section]=1}; \$ 
0!~/External *\\|/{next}; / 0+ UNDEF /{next}; / UNDEF \\([^|]\\)*()/{next}; 
{if(hide[section]) next}; {f=0}; \$ 0~/\\(\\).*\\|/{f=1}; {printf f ? 
\"T \" : \"D \"}; {split(\$ 0, a, /\\||\\r/); split(a[2], s)}; 
s[1]~/^...@?]/{print s[1], s[1]; next}; s[1]~prfx {split(s[1],t,\"@\"); 
print t[1], substr(t[1],length(prfx))} ' prfx=^_"


# Transform the output of nm in a proper C declaration.
global_symbol_to_cdecl="sed -n -e 's/^T .* \\(.*\\)\$/extern int \\1();/p' -e 
's/^[ABCDGISTW]* .* \\(.*\\)\$/extern char \\1;/p'"

# Transform the output of nm in a C name address pair.
global_symbol_to_c_name_address="sed -n -e 's/^: \\([^ ]*\\) \$/  {\\\"\\1\\\", 
(void *) 0},/p' -e 's/^[ABCDGISTW]* \\([^ ]*\\) \\([^ ]*\\)\$/  {\"\\2\", (void 
*) \\&\\2},/p'"

# Transform the output of nm in a C name address pair when lib prefix is needed.
global_symbol_to_c_name_address_lib_prefix="sed -n -e 's/^: \\([^ ]*\\) \$/  
{\\\"\\1\\\", (void *) 0},/p' -e 's/^[ABCDGISTW]* \\([^ ]*\\) \\(lib[^ ]*\\)\$/ 
 {\"\\2\", (void *) \\&\\2},/p' -e 's/^[ABCDGISTW]* \\([^ ]*\\) \\([^ ]*\\)\$/  
{\"lib\\2\", (void *) \\&\\2},/p'"

# The name of the directory that contains temporary libtool files.
objdir=.libs

# Used to examine libraries when file_magic_cmd begins with "file".
MAGIC_CMD=file

# Must we lock files when doing compilation?
need_locks="no"

# Tool to manipulate archive

libtool.git & cl.exe & Mingw32

[Akim Demaille]

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 of time in useless  
recompilations, because "libtool -o foo.exe" used to create "foo",  
which cause the Makefiles to never be satisfied and relaunching  
endless recompilations.


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 exist is .libs/cli.exe (and actually it makes more  
sense to me).  So I had to change libtool:



case $host_os in
  mingw*)
   cat <<"EOF"
  /* execv doesn't actually work on mingw as expected on unix */
  newargz = prepare_spawn (newargz);
  rval = _spawnv (_P_WAIT, newargz[0], (const char * const *)  
newargz); // Changed here

 if (rval == -1)
{
  /* failed to start process */
#ifndef __MINGW32CE__
  LTWRAPPER_DEBUGPRINTF (("(main) failed to launch target \"%s\":  
errno = %d\n", lt_argv_zero, errno));

#else
  LTWRAPPER_DEBUGPRINTF (("(main) failed to launch target \"%s 
\"\n", lt_argv_zero));

#endif
  return 127;
}
  return rval;
EOF
;;

so that _spawnv be given newargz[0] (== .libs/cl.exe) as first  
argument instead of lt_argv_zero (== .libs/lt-cl.exe).


I don't understand exactly what the code is expected to do: is the  
problem the value of lt_argv_zero (which is what I suspect), or rather  
the fact that there is no .libs/lt-cli.exe (which I doubt).  This is  
what I get without this change:


$ ./cli.exe
(main) argv[0]  : ./cli.exe
(main) program_name : cli.exe
(find_executable)   : ./cli.exe
(check_executable)  : 
R:\home\build\libport_x86_windows_vcxx2005_release_dynamic\work\build\tests\libport/./cli.exe
(main) found exe (before symlink chase) at : 
R:\home\build\libport_x86_windows_vcxx2005_release_dynamic\work\build\tests\libport/./cli.exe
(main) found exe (after symlink chase) at : 
R:\home\build\libport_x86_windows_vcxx2005_release_dynamic\work\build\tests\libport/./cli.exe
(main) libtool target name: lt-cli.exe
(lt_setenv) setting 'BIN_SH' to 'xpg4'
(lt_setenv) setting 'DUALCASE' to '1'
(lt_update_lib_path) modifying 'PATH' by prepending ''
(lt_update_exe_path) modifying 'PATH' by prepending 
'C:\boost_1_35_0\lib;C:\boost_1_35_0\bin;C:\opt\lib;C:\opt\bin;R:\home\build\libport_x86_windows_vcxx2005_release_dynamic\work\build\lib\libport\.libs;R:\usr\local\gostai\lib;R:\usr\local\gostai\bin;'
(lt_setenv) setting 'PATH' to 
'C:\boost_1_35_0\lib;C:\boost_1_35_0\bin;C:\opt\lib;C:\opt\bin;R:\home\build\libport_x86_windows_vcxx2005_release_dynamic\work\build\lib\libport\.libs;R:\usr\local\gostai\lib;R:\usr\local\gostai\bin;c:\windows;c:\windows\system;c:\vcxx8\vc\lib'
(main) lt_argv_zero : 
R:/home/build/libport_x86_windows_vcxx2005_release_dynamic/work/build/tests/libport/./.libs/lt-cli.exe
(main) newargz[0]   : 
R:/home/build/libport_x86_windows_vcxx2005_release_dynamic/work/build/tests/libport/./.libs/cli.exe
(main) failed to launch target 
"R:/home/build/libport_x86_windows_vcxx2005_release_dynamic/work/build/tests/libport/./.libs/lt-cli.exe":
 errno = 2




Also, I have enabled the DEBUGWRAPPER traces by changing libtool by  
hand, is there a better way?  Read the code I see that the wrappers  
support options, but I found no documentation about them, and there is  
no --lt-help: is this for Libtool developers only?


Cheers!

___
http://lists.gnu.org/mailman/listinfo/libtool

AC_REQUIRE hell

[Akim Demaille]

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=$shrext_cmds
# If you need to create a library, use libtool.  < First  
line in the macro

  shrext_cmds=".dll"
shrext_cmds=".so"
  shrext_cmds=".dll"
  shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
shrext_cmds='.so'
shrext_cmds='.sl'
shrext_cmds='.sl'
  shrext_cmds=".dll"
shrext_cmds='`$ECHO "$shrext_cmds" | $SED  
"$delay_single_quote_subst"`'

shrext_cmds \
shrext_cmds=$lt_shrext_cmds



I have a simple work around: instead of

AC_DEFUN([URBI_LTDL], [my macro])

I have

AC_DEFUN([URBI_LTDL], [m4_fatal([should never be used])])
m4_define([URBI_LTDL], [my macro])

The first line is to have aclocal notice that the macro is defined in  
an m4/ file, and the second is to avoid that URBI_LTDL define an  
AC_REQUIRE boundary.  I don't remember the details, but it seems  
suspicious to me that code using shrext_cmds is emitted before the  
contents of my macro.  Either somewhere there are m4_define that  
should be AC_DEFUN to define the AC_REQUIRE barriers (an error in  
Libtool), or when a macro OUTER invokes a macro INNER which requires  
REQUIRED then REQUIRED is output before OUTER, which seems wrong to me  
(an error in Autoconf).


Cheers!



configure.ac
Description: Binary data




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Installing convenience libraries

[Akim Demaille]

>>> "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 non-PIC object though; so you will have to put
 > -prefer-pic into compile mode flags, or --tag=disable-static in compile
 > mode flags before --mode=compile.  (The latter avoids double
 > compilation).

Thanks for the details!

 > I'm very reluctant to make installability for convenience archives
 > too easy for users, for fear of the scenarios stated.

I can afford a --yeah-I-want-to-install-a-convenience-library :)


 >> Say you have a company that ships libfull which is composed of
 >> a libcore and extra stuff.  Only few people have access to the sources
 >> of libcore, but libcore is installed on developer stations so that
 >> they can work on the extra-sources to put into libfull (which includes
 >> libcore).  libfull is provided to the clients, and it should be
 >> self-contained.
 >> 
 >> Isn't what libtool convenience libraries are tailored to do?

 > Sure they may be useful in this setting.  But I still don't understand
 > why you just don't simply make libcore be an ordinary shared library?
 > Is that because of relocatability issues?

Eventually we sure will use shared libraries, but as of today, it
seems simpler to first deal with only static libraries.  Besides, my
real problem is making an archive self-contained.  Unless you are
saying that if I had a "shared" libcore (the convenience one) I could
link it directly inside libfull.so?

 > I agree that in this case it may be a practical one.  Another one
 > may be to create a relocatable object that contains all the other
 > ones, i.e., do partial linking
 >
 >   ld -r -o liballofit.o obj1.o obj2.o

That's nice!  I wasn't aware of this feature.  I must say that I don't
know enough on object files to tell what the difference is with a
genuine library.  The toc I guess. I'll do my homework and look for
information on the Internet :)

 > Libtool advertises to do this portably, but that functionality still
 > has (old) bugs.  Also since it's not so often used, GNU binutils ld
 > has bugs with it on some systems (MinGW at least, IIRC).

Guess what: that's one of the targets :(



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Installing convenience libraries

[Akim Demaille]

>>> "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 library on top of it (and again install it), and finally
 >> link an executable using the latter library.

 > Convenience archives are not intended to be installed.

This is a quote from the documentation:

   You can even install a convenience library using GNU Libtool,
   though you probably don't want to and hence GNU Automake doesn't
   allow you to do so.

I guess it should read "static" instead of "convenience", in
particular since the example seems to refer to a plain library (it
uses .a):

 burger$ libtool install ./install-sh -c libhello.a /local/lib/libhello.a
 ./install-sh -c libhello.a /local/lib/libhello.a
 ranlib /local/lib/libhello.a
 burger$


 > Why?  Because that breaks dependency analysis, and it's not clean style.
 > The former could be fixed in Libtool, but the latter leads to problems
 > such as these scenarios:

My scenario is really different from yours (which does make a lot of
sense in a given environment).  Mine does not have the problem you
raise.  Say you have a company that ships libfull which is composed of
a libcore and extra stuff.  Only few people have access to the sources
of libcore, but libcore is installed on developer stations so that
they can work on the extra-sources to put into libfull (which includes
libcore).  libfull is provided to the clients, and it should be
self-contained.

Isn't what libtool convenience libraries are tailored to do?

 > But the ugliness happens even earlier: say, you create shared libraries
 > liba1, liba2, liba3, from a convenience archive libconv.  Assume libaX
 > are from different packages, different versions.  (This is a practical
 > assumption, since, if all libraries were from the same package or tree
 > of packages, you wouldn't have the need to install libconv in the first
 > place.)

Yes, I do.  Or maybe not: that seems like the best means to provide
the libcore to libfull developers.

 > Maybe you rather want to use an installable static library?
 >   libtool ---mode=link $CC ... -static -rpath /install/path \
 >   -o libfoo.la foo.lo ...

But then, I wouldn't have a self-contained libfull, would I?

Thanks!





___
http://lists.gnu.org/mailman/listinfo/libtool

Installing convenience libraries

[Akim Demaille]

[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 seems I can't do that.  It works well with
.o/.a, but with .lo/.la, it fails without an explicit explanation:

 | + libtool --tag=CC --mode=compile gcc -static foo.c -c -o foo.lo
 | mkdir .libs
 |  gcc foo.c -c  -fPIC -DPIC -o .libs/foo.o
 |  gcc foo.c -c -o foo.o >/dev/null 2>&1
 | + libtool --tag=CC --mode=link gcc -static foo.lo -o libfoo.la
 | ar cru .libs/libfoo.a  foo.o
 | ranlib .libs/libfoo.a
 | creating libfoo.la
 | (cd .libs && rm -f libfoo.la && ln -s ../libfoo.la libfoo.la)
 | + libtool --tag=CC --mode=install install -c libfoo.la 
/tmp/test-libtool.sh.tmp/lib/libfoo.la
 | install -c .libs/libfoo.lai /tmp/test-libtool.sh.tmp/lib/libfoo.la
 | install: cannot stat `.libs/libfoo.lai': No such file or directory

Am I trying to do something silly?  This is

ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 
22:14:06)

If you want to try, use the attached script.  Without argument it uses
.o/.a, with -l it uses .lo/.la.  I'd like to stick to Libtool
libraries because eventually we will probably move to using dynamic
libraries (i.e., the first library libfoo would remain a convenience
library, which should be later integrated into libbar so that the
latter is really self-contained.  Not clear this is doable...).

Any help is appreciated!

#! /bin/sh

set -ex

case $1 in
  -l) ext=l;;
  '') ext=;;
   *) exit 1
esac

libtool='libtool --tag=CC'

tmp=/tmp/$(basename $0).tmp
rm -rf $tmp
mkdir $tmp
cd $tmp
mkdir lib

make_object ()
{
  base=$1
  cat >$base.c <___
http://lists.gnu.org/mailman/listinfo/libtool

Re: sh portability questions

[Akim Demaille]

>>> "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 function context, so this will always
 > produce a failure.

Thanks, I didn't know.  How about this then?

(
foo=bar
test_local () {
local foo=foo
}
test_local
test $foo = bar
) || local () {
case $1 in
*=*) eval "$1";;
esac

}




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: sh portability questions

[Akim Demaille]

>>> "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 else complained and fixed it.

 > http://www.networksecurityarchive.org/html/Secure-Shell/2005-02/msg00067.html
 > http://packages.debian.org/changelogs/pool/main/x/xfree86/xfree86_4.3.0.dfsg.1-14/changelog

Thanks, I should have done this myself...

 > Is "local" that crucial?  Admittedly it's very annoying to lack local
 > variables, but you can always solve it by renaming.  (Unless you want
 > to use recursion.  Is that a goal here?)

No, recursion is not an issue, but it was to avoid having to stick to
ugly naming convention to avoid clashes.

 > Assuming you don't need recursion, here's a thought.

Nice trick!  Thanks for the suggestion.  Unfortunately, although I
don't have recursion, I do call my function multiple times.  Of course
I could start using 'unset', which is unportable but easy to work
around, but that starts to become quite a mess.

I can actually define "local" to do nothing and use an external
maintainer-check to grep'n check them.

Also, maybe I am paranoid, but would you trust shells to support
conditional function definitions?  Or function definitions in eval?

if (local foo) >/dev/null 2>&1; then :; else
  local () { true;  }
fi

or even

(local foo) >/dev/null 2>&1 || local () { true; }


Bah.  First trust, then react.  Thanks!



___
http://lists.gnu.org/mailman/listinfo/libtool

sh portability questions

[Akim Demaille]

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?  ISTR there were spies about return in the Autoconf
test suite, but there seems to be nothing about it today
(hum... wrong, there is now something in m4sh.m4 that looks for
"return" support, see below).

Thanks!



# _AS_SHELL_FN_WORK
# -
# This is a spy to detect "in the wild" shells that do not support shell
# functions correctly.  It is based on the m4sh.at Autotest testcases.
m4_define([_AS_SHELL_FN_WORK],
[as_func_return () {
  (exit [$]1)
}
as_func_success () {
  as_func_return 0
}
as_func_failure () {
  as_func_return 1
}
as_func_ret_success () {
  return 0
}
as_func_ret_failure () {
  return 1
}

exitcode=0
AS_IF([as_func_success], [],
  [exitcode=1
  echo as_func_success failed.])
AS_IF([as_func_failure],
  [exitcode=1
  echo as_func_failure succeeded.])
AS_IF([as_func_ret_success], [],
  [exitcode=1
  echo as_func_ret_success failed.])
AS_IF([as_func_ret_failure],
  [exitcode=1
  echo as_func_ret_failure succeeded.])
AS_IF([( set x; as_func_ret_success y && test x = "[$]1" )], [],
  [exitcode=1
  echo positional parameters were not saved.])
test $exitcode = 0])



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Understanding -static

[Akim Demaille]

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 with --enable-static then you get a statically linked  
executable,
but the default in your application is not to build static libs, so it  
links
against the only available thing the shared lib, yet it thinks it is
building static and makes no wrapper script :(
Right.  But linking statically a dynamic library doesn't sound
absurd to me (but I may be naive here).  At least, it works fine
on GNU/Linux.
Perhaps libtool should complain that -static was specified and no  
static
library was available in this case? How on earth does linux manage  
this?
What is the problem actually?
It seems that if there is no specific test in libtool for a feature,  
you can
pretty much guarantee that it does not work on Darwin :(
:) :) :)
When I use gcc directly, I have a weird failure.
sulaco% g++ -o hw main.o -static ./.libs/libhw.dylib
ld: can't locate file for: -lcrt0.o
There is nothing like crt0 on my machine.
sulaco% locate '*crt*o'
/sw/lib/python2.3/test/test_descrtut.pyo
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
test/test_descrtut.pyo
/usr/lib/crt1.o
/usr/lib/gcc/darwin/3.1/crtbegin.o
/usr/lib/gcc/darwin/3.3/crt2.o
/usr/lib/gcrt1.o

I'm not sure what it means :(
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Understanding -static

[Akim Demaille]

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 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 libraries that
are installed or not *now* (the present), or meant to be installed
or not (the future).
`-static'
 If OUTPUT-FILE is a program, then do not link it against any
 uninstalled shared libtool libraries.
My wondering comes from the fact that the attached tarball (to
bootstrap via autoreconf -fvi) does not link statically on Darwin when 
the
top level Makefile.am builds a lib_LTLIBRARIES (*to be installed*, but 
not
yet installed).  It builds, but the resulting binary is incomplete:

sulaco% file hw
hw: Mach-O executable ppc
sulaco% otool -L hw
hw:
/usr/local/lib/libhw.0.dylib (compatibility version 1.0.0, 
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 71.1.1)
sulaco% ./hw
dyld: ./hw can't open library: /usr/local/lib/libhw.0.dylib  (No such 
file or directory, errno = 2)
zsh: trace trap  ./hw

(Isn't lilbtool expected to build a wrapper script in such a case?)
When I replace
lib_LTLIBRARIES = libhw.la
with
noinst_LTLIBRARIES = libhw.la
then it works properly.
Note that on my Linux box, both work and link libhw
statically into hw.  Note also that AC_DISABLE_STATIC is specified.
This is with CVS Libtool.  BTW, thanks for the multiple files
with the same name within a single archive fix :)
And please, keep me in CC.


___
http://lists.gnu.org/mailman/listinfo/libtool

Understanding -static

[Akim Demaille]

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 libraries that
are installed or not *now* (the present), or meant to be installed
or not (the future).
`-static'
 If OUTPUT-FILE is a program, then do not link it against any
 uninstalled shared libtool libraries.
My wondering comes from the fact that the attached tarball (to
bootstrap via autoreconf -fvi) does not link statically on Darwin when 
the
top level Makefile.am builds a lib_LTLIBRARIES (*to be installed*, but 
not
yet installed).  It builds, but the resulting binary is incomplete:

sulaco% file hw
hw: Mach-O executable ppc
sulaco% otool -L hw
hw:
/usr/local/lib/libhw.0.dylib (compatibility version 1.0.0, 
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 71.1.1)
sulaco% ./hw
dyld: ./hw can't open library: /usr/local/lib/libhw.0.dylib  (No such 
file or directory, errno = 2)
zsh: trace trap  ./hw

(Isn't lilbtool expected to build a wrapper script in such a case?)
When I replace
lib_LTLIBRARIES = libhw.la
with
noinst_LTLIBRARIES = libhw.la
then it works properly.
Note that on my Linux box, both work and link libhw
statically into hw.  Note also that AC_DISABLE_STATIC is specified.
This is with CVS Libtool.  BTW, thanks for the multiple files
with the same name within a single archive fix :)
And please, keep me in CC.



c++-libtool-swig-python-0.01a.tar.gz
Description: GNU Zip compressed data
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Darwin: interlib deps

[Akim Demaille]

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 tried to avoid that.
I see.  If you are interested in helping us get objects/targets in 
subdirectories working properly for libtool 2.0 then libtool 2.0 will 
be ready sooner, and you will be able to simply refer to the objects 
you are interested in as part of a comprehensive build.  You would no 
longer need to use convenience libraries.  Building would be faster, 
cleaner, and more accurate.  Of course this approach requires that you 
are aware of the exact objects which need to be used since they would 
not be lumped together into a "library".
I was not aware this was an objective of Libtool 2.0.  Thanks for the
invitation, but I'm not used to hacking Libtool, and there are other
projects I should be working on :(
Anyway, I wanted to make sure I understood everything correctly.
Thanks for your help (and more generally thanks everybody for
Libtool!).

___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Darwin: interlib deps

[Akim Demaille]

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 list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Darwin: interlib deps

[Akim Demaille]

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 = \
position.hh location.hh \
...
libast.hh libast.hxx libast.cc  \
tasks.hh tasks.cc
and to have interlib dependency support, I report that this
lib depends on three siblings: symbol, task, and misc:
libast_la_LDFLAGS = -L../symbol -lsymbol -L../task -ltask -L../misc 
-lmisc

It seems that linking is correct:
/bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -W -Wcast-align 
-Wcast-qual -Wformat -Wmissing-prototypes -Wshadow -Wstrict-prototypes 
-Wwrite-strings -g -O2 -pipe   -o libast.la  -L../symbol -lsymbol 
-L../task -ltask -L../misc -lmisc decs.lo arrayexp.lo arrayty.lo 
assignexp.lo ast.lo breakexp.lo callexp.lo dec.lo escapable.lo exp.lo 
field.lo fieldinit.lo fieldvar.lo forexp.lo functiondec.lo ifexp.lo 
intexp.lo letexp.lo namety.lo nilexp.lo opexp.lo recordexp.lo 
recordty.lo seqexp.lo simplevar.lo stringexp.lo subscriptvar.lo ty.lo 
typable.lo typedec.lo var.lo vardec.lo whileexp.lo print-visitor.lo 
libast.lo tasks.lo  rm -fr  .libs/libast.a .libs/libast.laar cru 
.libs/libast.a .libs/decs.o .libs/arrayexp.o .libs/arrayty.o 
.libs/assignexp.o .libs/ast.o .libs/breakexp.o .libs/callexp.o 
.libs/dec.o .libs/escapable.o .libs/exp.o .libs/field.o 
.libs/fieldinit.o .libs/fieldvar.o .libs/forexp.o .libs/functiondec.o 
.libs/ifexp.o .libs/intexp.o .libs/letexp.o .libs/namety.o 
.libs/nilexp.o .libs/opexp.o .libs/recordexp.o .libs/recordty.o 
.libs/seqexp.o .libs/simplevar.o .libs/stringexp.o .libs/subscriptvar.o 
.libs/ty.o .libs/typable.o .libs/typedec.o .libs/var.o .libs/vardec.o 
.libs/whileexp.o .libs/print-visitor.o .libs/libast.o 
.libs/tasks.oranlib .libs/libast.acreating libast.la(cd .libs && rm -f 
libast.la && ln -s ../libast.la libast.la)

in the beginning -L../symbol -lsymbol -L../task -ltask -L../misc -lmisc 
do appear.
But when I try to link a small test case:

check_PROGRAMS = test-ast
test_ast_SOURCES = test-ast.cc
test_ast_LDADD = libast.la
TESTS = test-ast
I have linking failures: neither symbol, task or misc is added.
libast.la contains:
# Libraries that this one depends upon.
dependency_libs=' -L/Users/akim/src/tc/_build/src/symbol 
-L/Users/akim/src/tc/_build/src/task 
-L/Users/akim/src/tc/_build/src/misc   '

is this normal?  When I had -lsymbol etc. by hand, linking and execution
passes.
How am I expected to do that?
If I try to link again libast as a dynamic library it fails to:
/bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -W -Wcast-align 
-Wcast-qual -Wformat -Wmissing-prototypes -Wshadow -Wstrict-prototypes 
-Wwrite-strings -g -O2 -pipe   -o test-ast -last test-ast.o  g++ -Wall 
-W -Wcast-align -Wcast-qual -Wformat -Wmissing-prototypes -Wshadow 
-Wstrict-prototypes -Wwrite-strings -g -O2 -pipe -o test-ast test-ast.o 
-Wl,-bind_at_load  /Users/akim/src/tc/_build/src/ast/.libs/libast.ald: 
Undefined 
symbols:symbol::Symbol::Symbol[in-charge](std::basic_string, std::allocator > 
const&)misc::Deref::Deref[in-charge](std::basic_ostream >&)misc::iendl(std::basic_ostream 
>&)misc::Escape::Escape[in-charge](std::basic_ostream >&)misc::decendl(std::basic_ostream >&)misc::incendl(std::basic_ostream >&)misc::decindent(std::basic_ostream >&)misc::incindent(std::basic_ostream >&)misc::Escape::escape_(std::basic_string, std::allocator > const&) constmake[2]: 
*** [test-ast] Error 1make[1]: *** [check-am] Error 2make: *** [check] 
Error 2

-last appears, but...

___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Autoconf 2.57f is released

[Akim Demaille]

This is our candidate release for Autoconf 2.58.  We plan to release
it soon, so that Automake 1.8 can be released, hence Libtool 1.6, so
that GNU M4 2.0 can be shipped, enabling Autoconf 2.60 ;)

Please, test it thoroughly.

Akim, Alexandre, Jim, Paul, and Tom.


Here are the compressed sources:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.gz   (1.2MB)
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.bz2  (837KB)

And here are xdelta-style diffs:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57d-2.57f.xdelta   (10KB)

Here are GPG detached signatures:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.gz.asc
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.bz2.asc

Here are the MD5 and SHA1 signatures:

dd48fe8cf425f7068d729aa432df4527  autoconf-2.57f.tar.gz
385a923859a0e02e4c6f0ccc4f29b137  autoconf-2.57f.tar.bz2
4f342dbfbcee2648e7426c3f46f59fb8  autoconf-2.57d-2.57f.xdelta
9b1f3a2bfeb21e80813619e86cc5a52b7edaffbb  autoconf-2.57f.tar.gz
5dd5018ae395ed627384caf69460fea5006a037e  autoconf-2.57f.tar.bz2
2cda92c4f05799ace152744927152a1645030287  autoconf-2.57d-2.57f.xdelta

NEWS

* Major changes in Autoconf 2.57f

  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/ is created if needed.


ChangeLog entries:

**
ChangeLog
**
2003-10-01  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.57f.

2003-09-30  Paul Eggert  <[EMAIL PROTECTED]>

* lib/Autom4te/XFile.pm: Use Errno.
(lock): Ignore ENOLCK errors.  Problem reported Andreas Schwab in
<http://mail.gnu.org/archive/html/bug-autoconf/2003-09/msg00141.html>.

2003-09-30  Akim Demaille  <[EMAIL PROTECTED]>

* config/announce-gen (&print_news_deltas): Extracted from...
(&print_changelog_deltas): here.
(&news_file): Rename as...
(@news_file): this.

2003-09-30  Nicolas Joly  <[EMAIL PROTECTED]>

* lib/autoconf/fortran.m4 (_AC_PROG_FC): Remove files which might
have been created when invoking the compiler.
* tests/fortran.at (GNU Fortran 77): Quote $G77.

2003-09-29  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.57e.

* config/mkinstalldirs: Upgrade.

2003-09-28  Paul Eggert  <[EMAIL PROTECTED]>

* lib/m4sugar/m4sh.m4 (AS_SHELL_SANITIZE): Set DUALCASE=1, for MKS sh.
Problem reported by Lars J. Aas in
<http://mail.gnu.org/archive/html/autoconf/2003-07/msg00042.html>.
(_AS_MKDIR_P_PREPARE): Change "rm -fr ./-p" to the more-conservative
"test -d ./-p && rmdir ./-p".  Suggested by Andreas Schwab in:
    http://mail.gnu.org/archive/html/autoconf-patches/2003-09/msg00039.html

2003-09-26  Akim Demaille  <[EMAIL PROTECTED]>

* lib/autoconf/status.m4 (_AC_OUTPUT_COMMANDS): Make sure the
directory for AC_CONFIG_COMMANDS' first argument exists.
This makes valid the invocation of _AC_SRCPATH that follows.
Reported by Eric Sunshine.
* doc/autoconf.texi (Configuration Commands): Adjust.

2003-09-26  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autoscan.in (Autom4te::FileUtils): Use it for find_file.
Reported by Ralf Corsepius.

2003-09-26  Akim Demaille  <[EMAIL PROTECTED]>

* lib/autoconf/general.m4 (AC_HELP_STRING): Don't overquote the
arguments.
Actually, use AU_ALIAS.
From Bruno Haible.

2003-09-26  Paul Eggert  <[EMAIL PROTECTED]>

* lib/m4sugar/m4sh.m4 (_AS_MKDIR_P_PREPARE): If mkdir -p . fails,
rm -fr ./-p to remove junk left behind on NextStep and OpenStep.
Problem reported by Eric Sunshine in:
http://mail.gnu.org/archive/html/autoconf-patches/2002-12/msg00014.html

2003-09-26  Akim Demaille  <[EMAIL PROTECTED]>

The test suite are sometimes assigning timings incorrectly.
Reported by Henk Krus.
Diagnosed by Nicolas Joly.

* lib/autotest/general.m4 (AT_CLEANUP): Rename AT_help as
AT_help_all.
Instead of making AT_help a sequence of assignments to grow
$at_help_all, just make AT_help_all be the growing contents of
$at_help_all, and make a single assignment in...
(AT_INIT): here.
(at_times_skip): Flip the meaning and rename as...
(at_times_p): this.
(AT_INIT): When summarizing the test that ran, remove
$at_times_file after use, and check it is present before trying to
use it.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Autoconf 2.57d released

[Akim Demaille]

<#secure method=pgpmime mode=sign>

This is our candidate release for Autoconf 2.58.  We plan to release
it soon, so that Automake 1.8 can be released, hence Libtool 1.6, so
that GNU M4 2.0 can be shipped, enabling Autoconf 2.60 ;)

Please, test it thoroughly.

Akim, Alexandre, Jim, Paul, and Tom.

Here are the compressed sources:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.gz   (1.2MB)
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.bz2  (837KB)

And here are xdelta-style diffs:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57b-2.57d.xdelta   (26KB)

Here are GPG detached signatures:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.gz.asc
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.bz2.asc

Here are the MD5 and SHA1 signatures:

2fd6b2ce93c20272114580696b873b13  autoconf-2.57d.tar.gz
11283066884ee9dac83b9e6d9a7870f4  autoconf-2.57d.tar.bz2
f1bf3224ee351de53229c8e3957ac888  autoconf-2.57b-2.57d.xdelta
810ea71de4c866970f76079036847c63ad605d77  autoconf-2.57d.tar.gz
be65e491f94df9e1fa0aa272df78848d0ef2ac84  autoconf-2.57d.tar.bz2
92306a504a352c140c7795839cfe374f7e931046  autoconf-2.57b-2.57d.xdelta

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 became a significant problem since aclocal and automake can
  run autoconf behind the scene.

** autoheader warnings
  The warnings of autoheader can be turned off, using --warning.
  For instance, -Wno-obsolete disables the complaints about acconfig.h
  and other deprecated constructs.

* Major changes in Autoconf 2.57a

** New macros
  AC_C_RESTRICT, AC_INCLUDES_DEFAULT.

** AC_DECL_SYS_SIGLIST
  Works again.

** AC_FUNC_MKTIME
  Now checks that mktime is the inverse of localtime.

** Improve DJGPP portability
  The Autoconf tools and configure behave better under DJGPP.

** Present But Cannot Be Compiled
  New FAQ section dedicated to the mystic

configure: WARNING: pi.h: present but cannot be compiled
configure: WARNING: pi.h: check for missing prerequisite headers?
configure: WARNING: pi.h: proceeding with the preprocessor's result
  messages.

** Concurrent executions of autom4te
  autom4te now locks its internal files, which enables concurrent
  executions of autom4te, likely to happen if automake, autoconf,
  autoheader etc. are run simultaneously.

** Libtool
  Use of Libtool 1.5 and higher is encouraged.  Compatibility with
  Libtool pre-1.4 is not checked.

** Autotest
  Testsuites no longer rerun failed tests in verbose mode; instead,
  failures are logged while the test is run.

  In addition, expected failures can be marked as such.



ChangeLog entries:

**
ChangeLog
**
2003-09-25  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.57d.

* bin/Makefile.am (edit): Handle '@configure_input@'.
(autoconf, autoheader, autom4te, autoreconf, autoscan, autoupdate)
(ifnames): chmod -w.
* tests/wrapper.as (AUTOCONF, AUTOM4TE, ): Point to tests/
executables, not bin/ executables!  Otherwise all the magic needed
to find non installed files is turned off.  This caused a failure
of test 40 and 41 that ran aclocal 1.8 which in turn ran autom4te
as found in its environment (sent by tests/autoreconf): pointing
to bin/autom4te that could not find its files.
* tests/mktests.sh: Force the replacement of generated files, for
the sake of "mv" program that are interactive when overwriting a
-w file.
* config/install-sh: Upgrade from CVS Automake.

2003-09-23  Paul Eggert  <[EMAIL PROTECTED]>

* doc/autoconf.texi (Limitations of Builtins): Document test -h
versus test -L issues.

2003-09-23  Daniel Jacobowitz  <[EMAIL PROTECTED]> and
Paul Eggert <[EMAIL PROTECTED]>

Trivial change to support GCC's configuration procedure.
* lib/autoconf/c.m4 (AC_PROG_CPP_WERROR): New macro.
* lib/autoconf/headers.m4 (_AC_CHECK_HEADER_MONGREL): Don't warn
about inconsistency if the preprocessor is set to give errors for
any warning.
* doc/autoconf.texi (C Compiler Characteristics): Document this.

2003-09-13  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* Makefile.am (autom4te-update, autom4te_files): Fetch Struct.pm
and XFile.pm from Automake.
    * lib/Autom4te/XFile.pm: Update from Automake.

2003-09-12  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.57c.

2003-09-12  Akim Demaille  <[EMAIL PROTECTED]>

* config/config.guess, 

Autoconf 2.56 is released

[Akim Demaille]

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 might require 2.55.  See
below for the list of user visible changes.

Running `autoreconf -fv' should be enough.


   - Why should I upgrade from 2.13?

This version is no longer maintained.  It does not address recent
architectures, recent compilers etc.  We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions.  Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.


   - Where can I find it?

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.56.tar.gz   (1.1 MB)
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.56.tar.bz2  (795 KB)
  ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.54-2.56.delta   (7 KB)

and soon from the mirrors listed on http://www.gnu.org/order/ftp.html.


Here are the MD5 and SHA1 signatures:

0e142e9bc890786845950e84ffb52adf  autoconf-2.56.tar.gz
1b0ecb66f03af3f745981c7d8bfc2a91  autoconf-2.56.tar.bz2
edcb98aa66f5c74a579109aef9cf3270  autoconf-2.55-2.56.xdelta
afff4a43d0b71a05de7b72e5a493a3e94219160c  autoconf-2.56.tar.gz
5d2b082c2c76476a28a3b7bc0b537ccf6b5ad6f6  autoconf-2.56.tar.bz2
e1befdcb8d1032964021e29d6ad17975a766aa13  autoconf-2.55-2.56.xdelta


NEWS:

Release tips:

   Have your configure.ac checked by autoscan ("autoscan").
   Try the warning options ("autoreconf -fv -Wall").

** Documentation

- AC_CHECK_HEADER, AC_CHECK_HEADERS
  More information on proper use.

- Writing Test Programs

  This sections explains how to write good test sources to use with
  AC_COMPILE_IFELSE etc.  It documents AC_LANG_PROGRAMS and so forth.

- AC_FOO_IFELSE vs. AC_TRY_FOO

  Explains why Autoconf moves from AC_TRY_COMPILE etc. to
  AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.

** autoreconf

- Is more robust to different Gettext installations.

- Produces messages (when --verbose) to be understood by Emacs'
  compile mode.

- Supports -W/--warnings.

- -m/--make
  Once the GNU Build System reinstalled, run `./config.status
  --recheck && ./config.status && make' if possible.

** autom4te

- Supports --cache, and --no-cache.

- ~/.autom4te.cfg makes it possible to disable the caching mechanism
  (autom4te.cache).  See `Customizing autom4te' in the documentation.

** Obsolete options

  Support for the obsoleted options -m, --macrodir, -l, --localdir is
  dropped in favor of the safer --include/--prepend-include scheme.

** Macros

- New macros
  AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
  AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_LANG_CALL,
  AC_LANG_FUNC_TRY_LINK, AC_MSG_FAILURE, AC_PREPROC_IFELSE.

- Obsoleted
  Obsoleted macros are kept for Autoconf backward compatibility, but
  should be avoided in configure.ac.  Running autoupdate is advised.
  AC_DECL_SYS_SIGLIST.

** Bug Fixes

- Portability of the Autoconf package to Solaris.

- Spurious warnings caused by config.status.
  This bug is benign, but painful: on some systems (typically
  FreeBSD), warnings such as:

 config.status: creating Makefile
 mv: Makefile: set owner/group (was: 1357/0): Operation not permitted

  could be issued.  This is fixed.

- Parallel Builds
  Simultaneous executions of config.status are possible again.

- Precious variables accumulation

  config.status could stack several copies of the precious variables
  assignments.


** Plans for 2.57

- ./configure 

  The compatibility hooks with the old scheme will be completely
  removed.  Please, advice/use `--build', `--host', and `--target'
  only.

- AC_CHECK_HEADER, AC_CHECK_HEADERS

  The tests will be stricter, please make sure your invocations are
  valid.

- shell functions

  Shell functions will gradually be introduced, probably starting with
  Autotest.  If you know machines which are in use that you suspect
  *not* to support shell functions, please run the test suite of
  Autoconf 2.55 on it, and report the results to
  [EMAIL PROTECTED]


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [shell functions, was RE: solving of name conflicts inincluded.a]

[Akim Demaille]

 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.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [shell functions, was RE: solving of name conflicts in included.a]

[Akim Demaille]

> "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 shell functions, it just says it
will some day.  If you want to use shell functions, don't do it
pretending Autoconf did first :)

Also, Autoconf will try to find a shell that supports functions.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Autoconf 2.55 is released!

[Akim Demaille]

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 Gettext release might require 2.55.

Running `autoreconf -fv' should be enough.


   - Why should I upgrade from 2.13?

This version is no longer maintained.  It does not address recent
architectures, recent compilers etc.  We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions.  Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.


   - Where can I find it?

  ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.55.tar.gz (1.1 MB)
  ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.55.tar.bz2(794 KB)
  ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.54-2.55.delta  (70 KB)

and soon from the mirrors listed on http://www.gnu.org/order/ftp.html.


Here are the MD5 and SHA1 signatures:

d3e8ad97aa69853778125177967ed573  autoconf-2.55.tar.gz
4517bb0669b949935967f31329a29c0c  autoconf-2.55.tar.bz2
c991edb76acbf686bed4ce1cb7a35cc2  autoconf-2.54-2.55.xdelta
69554487aec8606a17c53db2c7c7964be7138946  autoconf-2.55.tar.gz
d6d7cf9a2df8736c2930d1e6104de9c7a8ccbaff  autoconf-2.55.tar.bz2
717df2957e85ad4de9c3c651a5b3eff1b01e3857  autoconf-2.54-2.55.xdelta

NEWS:

Release tips:

   Have your configure.ac checked by autoscan ("autoscan").
   Try the warning options ("autoreconf -fv -Wall").

** Documentation

- AC_CHECK_HEADER, AC_CHECK_HEADERS
  More information on proper use.

- Writing Test Programs

  This sections explains how to write good test sources to use with
  AC_COMPILE_IFELSE etc.  It documents AC_LANG_PROGRAMS and so forth.

- AC_FOO_IFELSE vs. AC_TRY_FOO

  Explains why Autoconf moves from AC_TRY_COMPILE etc. to
  AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.

** autoreconf

- Is more robust to different Gettext installations.

- Produces messages (when --verbose) to be understood by Emacs'
  compile mode.

- Supports -W/--warnings.

- -m/--make
  Once the GNU Build System reinstalled, run `./config.status
  --recheck && ./config.status && make' if possible.

** autom4te

- Supports --cache, and --no-cache.

- ~/.autom4te.cfg makes it possible to disable the caching mechanism
  (autom4te.cache).  See `Customizing autom4te' in the documentation.

** Obsolete options

  Support for the obsoleted options -m, --macrodir, -l, --localdir is
  dropped in favor of the safer --include/--prepend-include scheme.

** Macros

- New macros
  AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
  AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_LANG_CALL,
  AC_LANG_FUNC_TRY_LINK, AC_MSG_FAILURE, AC_PREPROC_IFELSE.

- Obsoleted
  Obsoleted macros are kept for Autoconf backward compatibility, but
  should be avoided in configure.ac.  Running autoupdate is advised.
  AC_DECL_SYS_SIGLIST.

** Bug Fixes

- Portability of the Autoconf package to Solaris.

- Spurious warnings caused by config.status.
  This bug is benign, but painful: on some systems (typically
  FreeBSD), warnings such as:

 config.status: creating Makefile
 mv: Makefile: set owner/group (was: 1357/0): Operation not permitted

  could be issued.  This is fixed.

- Parallel Builds
  Simultaneous executions of config.status are possible again.

- Precious variables accumulation

  config.status could stack several copies of the precious variables
  assignments.


** Plans for 2.56

- ./configure 

  The compatibility hooks with the old scheme will be completely
  removed.  Please, advice/use `--build', `--host', and `--target'
  only.

- AC_CHECK_HEADER, AC_CHECK_HEADERS

  The tests will be stricter, please make sure your invocations are
  valid.

- shell functions

  Shell functions will gradually be introduced, probably starting with
  Autotest.  If you know machines which are in use that you suspect
  *not* to support shell functions, please run the test suite of
  Autoconf 2.55 on it, and report the results to
  [EMAIL PROTECTED]


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Touching the PATH

[Akim Demaille]

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 'esyscmd(m4 --version)' | PATH=`pwd`:$PATH m4

m4: error while loading shared libraries: m4.so.0: cannot open shared object file: No 
such file or directory

What's wrong?

What is wrong is that the PATH is not the one I passed:

~/src/m4/m4-1.4q/=build/tests % echo 'esyscmd(echo $PATH)' | PATH=`pwd`:$PATH m4   

/home/akim/src/m4/m4-1.4q/=build/src/.libs:/home/akim/src/m4/m4-1.4q/=build/tests:/home/akim/bin:/home/akim/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

and therefore, it is not the m4 I wanted to run that is run:

~/src/m4/m4-1.4q/=build/tests % echo 'esyscmd(which m4)' | PATH=`pwd`:$PATH m4
/home/akim/src/m4/m4-1.4q/=build/src/.libs/m4  

Which apparently, didn't get the variables it wanted.

This is because of the following lines in ltmain,.sh:

  $echo >> $output "\
  # Export the path to the program.
  PATH=\"\$progdir:\$PATH\"
  export PATH

  exec \$program \${1+\"\$@\"}


Why not running directly the program?  Well, because:

1997-01-28  Gordon Matzigkeit  <[EMAIL PROTECTED]>

* ltmain.sh.in (link): Export the PATH variable in order to find
the program, rather than giving a full path.  This helps give the
program a less confusing value for argv[0].


but this is no longer relevant!!!  Just look at the poor name reported
by the program:

remo% ./m4 --help | sed 1q
Usage: lt-m4 [OPTION]... [FILE]...

the name is already broken by the fact that lt- is prepended.

So, because playing with PATH (and with any user var actually) is a
bad idea, I vote for the replacement of the code above by:

  $echo >> $output "\
  exec \$progdir/\$program \${1+\"\$@\"}

Comments?


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Autoconf 2.54c is relased

[Akim Demaille]

The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the second beta of forthcoming 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 Gettext release might require 2.55.

Running `autoreconf -fv' should be enough.


   - Why should I upgrade from 2.13?

This version is no longer maintained.  It does not address recent
architectures, recent compilers etc.  We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions.  Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.


   - Where can I find it?

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54c.tar.gz   (1.1 MB)
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54c.tar.bz2  (792 KB)

And here are xdelta-style diffs

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54b-2.54c.xdelta   (17 KB)

Here are the MD5 and SHA1 signatures:

ab431fb26babf82de8fda486afb94350  autoconf-2.54c.tar.gz
db32dbbcd1bf2f8ca7713faa58bc905e  autoconf-2.54c.tar.bz2
39bdbfc39b0581bda303e3b42a550714  autoconf-2.54b-2.54c.xdelta
807d67c59445ddac573dd8c9a42ac668b83020f0  autoconf-2.54c.tar.gz
9968922141aaf313ed145fe19d27669fd5f89189  autoconf-2.54c.tar.bz2
dd01917057f9f456e96259734ebc56a2b22f11ef  autoconf-2.54b-2.54c.xdelta

NEWS:

Release tips:

   Have your configure.ac checked by autoscan ("autoscan").
   Try the warning options ("autoreconf -fv -Wall").

** Documentation

- AC_CHECK_HEADER, AC_CHECK_HEADERS
  More information on proper use.

- Writing Test Programs

  This sections explains how to write good test sources to use with
  AC_COMPILE_IFELSE etc.  It documents AC_LANG_PROGRAMS and so forth.

- AC_FOO_IFELSE vs. AC_TRY_FOO

  Explains why Autoconf moves from AC_TRY_COMPILE etc. to
  AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.

** autoreconf

- Is more robust to different Gettext installations.

- Produces messages (when --verbose) to be understood by Emacs'
  compile mode.

- Supports -W/--warnings.

- -m/--make
  Once the GNU Build System reinstalled, run `./config.status
  --recheck && ./config.status && make' if possible.

** autom4te

- Supports --cache, and --no-cache.

- ~/.autom4te.cfg makes it possible to disable the caching mechanism
  (autom4te.cache).  See `Customizing autom4te' in the documentation.

** Obsolete options

  Support for the obsoleted options -m, --macrodir, -l, --localdir is
  dropped in favor of the safer --include/--prepend-include scheme.

** Macros

- New macros
  AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
  AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_LANG_CALL,
  AC_LANG_FUNC_TRY_LINK, AC_MSG_FAILURE, AC_PREPROC_IFELSE.

- Obsoleted
  Obsoleted macros are kept for Autoconf backward compatibility, but
  should be avoided in configure.ac.  Running autoupdate is advised.
  AC_DECL_SYS_SIGLIST.

** Bug Fixes

- Portability of the Autoconf package to Solaris.

- Spurious warnings caused by config.status.
  This bug is benign, but painful: on some systems (typically
  FreeBSD), warnings such as:

 config.status: creating Makefile
 mv: Makefile: set owner/group (was: 1357/0): Operation not permitted

  could be issued.  This is fixed.

- Parallel Builds
  Simultaneous executions of config.status are possible again.

- Precious variables accumulation

  config.status could stack several copies of the precious variables
  assignments.


** Plans for 2.56

- ./configure 

  The compatibility hooks with the old scheme will be completely
  removed.  Please, advice/use `--build', `--host', and `--target'
  only.

- AC_CHECK_HEADER, AC_CHECK_HEADERS

  The tests will be stricter, please make sure your invocations are
  valid.

- shell functions

  Shell functions will gradually be introduced, probably starting with
  Autotest.  If you know machines which are in use that you suspect
  *not* to support shell functions, please run the test suite of
  Autoconf 2.55 on it, and report the results to
  [EMAIL PROTECTED]


ChangeLog entries:

**
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.
* config/texinfo.tex: Update.

2002-11-03  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autoreconf.in (&autoreconf_current_directory): New, extracted
from...
   

Autoconf 2.54a is released

[Akim Demaille]

The Autoconf team is happy to annonce the first beta of forthcoming
Autoconf 2.55.  Download, compile, install, torture, and enjoy!

Akim, Alexandre, Jim, Paul, and Tom

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54a.tar.gz   (1.1 MB)
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54a.tar.bz2  (779 KB)

And here are xdelta-style diffs

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54-2.54a.xdelta   (44 KB)

Here are the MD5 and SHA1 signatures:

3c5ae43575fd82eede45285c4e993d9b  autoconf-2.54a.tar.gz
921076ed637757bcedf6aac4a072e3f8  autoconf-2.54a.tar.bz2
e612de9ceb46d8561c5f81e424a6b39d  autoconf-2.54-2.54a.xdelta
2168b9280a31e516b5b3a807c7d234adc23247d3  autoconf-2.54a.tar.gz
a0703a4829bdc1249ee775ac3a4123c6c85a84fb  autoconf-2.54a.tar.bz2
17ed07dc238d8b369d61bad8fbd852733fc79760  autoconf-2.54-2.54a.xdelta

NEWS:

** Documentation

- AC_CHECK_HEADER, AC_CHECK_HEADERS
  More information on proper use.

** autoreconf

- Is more robust to different Gettext installations.

- Produces messages (when --verbose) to be understood by Emacs'
  compile mode.

** Obsolete options
  Support for the obsoleted options -m, --macrodir, -l, --localdir is
  dropped in favor of the safer --include/--prepend-include scheme.

** Customization

- ~/.autom4te.cfg makes it possible to disable the caching mechanism
  (autom4te.cache).  See `Customizing autom4te' in the documentation.

** Macros

- New macros
  AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL.

- Obsoleted
  Obsoleted macros are kept for Autoconf backward compatibility, but
  should be avoided in configure.ac.  Running autoupdate is advised.
  AC_DECL_SYS_SIGLIST.

** Bug Fixes

- Portability of the Autoconf package to Solaris.

- Spurious warnings caused by config.status.
  This bug is benign, but painful: on some systems (typically
  FreeBSD), warnings such as:

 config.status: creating Makefile
 mv: Makefile: set owner/group (was: 1357/0): Operation not permitted

  could be issued.  This is fixed.

- Parallel Builds
  Simultaneous executions of config.status are possible again.

- Precious variables accumulation

  config.status could stack several copies of the precious variables
  assignments.


** Plans for 2.56

- ./configure 

  The compatibility hooks with the old scheme will be completely
  removed.  Please, advice/use `--build', `--host', and `--target'
  only.

- AC_CHECK_HEADER, AC_CHECK_HEADERS

  The tests will be stricter, please make sure your invocations are
  valid.

- shell functions

  Shell functions will gradually be introduced, probably starting with
  Autotest.  If you know machines which are in use that you suspect
  *not* to support shell functions, 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.
(automake_repo): Update to redhat.com.
(cvs_file): New.
Adjust to the fact that ansi2knr is now hosted by Automake.
* Makefile.am (cvs_files): Add install-sh and mkinstalldirs.
* config/config.guess, config/mkinstalldirs, config/texinfo.tex:
Update from masters.
* lib/autoscan/Makefile.am (EXTRA_DIST, nodist_autoscanlib_DATA):
autoscan.pre is not to be installed, and autoscan.list is not to
be shipped.
(CLEANFILES): Add autoscan.list.
(autoscan.list): Disable the cache.
* bin/Makefile.am: Include freeze.mk.

2002-10-25  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autom4te.in (&load_configuration): Take the file as
argument.
(&parse_args): Handle -C, --cache.
($help): Adjust.
(MAIN): Load ~/.autom4te.cfg and ./.autom4te.cfg.
* lib/autom4te.in (Autoconf): Pass --cache=autom4te.cache.
* doc/autoconf.texi (Invoking autom4te): Document --cache.
Now a subsection of...
(Using autom4te): This new section.
(Customizing autom4te): New.
    (autom4te.cache): Adjust.

2002-10-25  Akim Demaille  <[EMAIL PROTECTED]>

* doc/autoconf.texi (Generic Headers): More information on how to
    use AC_CHECK_HEADERS.

2002-10-25  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autoconf.as, bin/autoconf.in, bin/autoupdate.in ($help):
Space changes.

2002-10-25  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autoscan.in (output): Output AC_PREREQ.
(%needed_macros): Add AC_PREREQ so that configure.ac without one
be reported.

2002-10-23  Akim Demaille  <[EMAIL PROTECTED]>

* doc/autoconf.texi (Particular Headers): In AC_HEADER_STDBOOL,
document _Bool.

2002-10-23  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autom4te.in (handle_traces): Handle @&t@ in traces.
Reported by Peter Eisentraut.

2002-10-23  Akim Dema

Re: Libtool 1.4.3

[Akim Demaille]

| > 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 grieves
| > against Autoconf, but using things that were never documented.
| 
| You have lost me.  Why should autoconf document any valid m4
| command?

Because Autoconf is not M4!  Because such a large framework must make
provisions precisely so that the whole architecture work.  Ans esyscmd
is teh best example of what cannot be kept.

| > esyscmd is definitely excluded from our framework.
| 
| Then you need to document that.  Neither 2.13's nor 2.54's
| autoconf.info says anything to that effect.

OK.  I agree that

| Programming in M4
| *
| 
|Autoconf is written on top of two layers: "M4sugar", which provides
| convenient macros for pure M4 programming, and "M4sh", which provides
| macros dedicated to shell script generation.
| 
|As of this version of Autoconf, these two layers are still
| experimental, and their interface might change in the future.  As a
| matter of fact, _anything that is not documented must not be used_.

is not clear enough, it seems to refer to M4sugar and M4sh only.  And

| Changed Macro Writing
| -
| 
[...]
|If you were doing tricky things with undocumented Autoconf internals
| (macros, variables, diversions), check whether you need to change
| anything to account for changes that have been made.  Perhaps you can
| even use an officially supported technique in version 2 instead of
| kludging.  Or perhaps not.

is hidden.


| > But you kept developping your Autoconf instead of coming and
| > deciding for a solution.
| 
| I cannot parse that sentence.

Sorry :)  I mean, when you clear hit a limitation of a tool,
contacting the developper of the tools will certainly provide a better
solution that doing something on your side.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Akim Demaille]

| > 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 autoconf -f then.

| These files are sourced using
| 
| esyscmd(./scripts/config-stubs ext)
| 
| The shell script prints out an sinclude() line for each
| existing config.m4 in a particular sub-directory (e.g.
| ext/mysql, ext/session).  Apparently, autoconf/autom4te does
| not keep track of the time stamp of each sourced file which
| then causes the described issue.

You know, you are typically the kind of people who has valid grieves
against Autoconf, but using things that were never documented.
esyscmd is definitely excluded from our framework.  But you kept
developping your Autoconf instead of coming and deciding for a
solution.


| Oh, btw, has autoconf 2.5x stopped to generate empty "case..esac"
| constructs?  FreeBSD's /bin/sh bombed out on that, and it
| violated POSIX.

How do I know?  Did you send a bug report?  Do you have a test case?

And BTW, do PHP's extensions finally produce valid HTML code?


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Akim Demaille]

> "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 find a tarball somewhere (I'm bing cut from CVS
currently), and read the M4 code.  I'll subscribe to libtool-patches too.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Akim Demaille]

> "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 it didn't
Russ> happen.  It very clearly did happen.  Calling the autoconf
Russ> scripts that worked in autoconf 2.13 but not in 2.5x "broken" is
Russ> a deflection that I'd be more sympathetic to if the ways in
Russ> which they were "broken" were clearly documented in autoconf
Russ> 2.13, but they weren't.  Which means that the language
Russ> definition was changed (to something much more precise, mind),
Russ> not that scripts that followed the previous language definition
Russ> such as it was were broken.

I don't want to dive into this debate, and I think that Russ' summary
is very satisfying in that it exposes the point of view of all the
parties.

Whatever your opinion is, this debate is anyway a total loss of time
for all of us (except for having the opportunity of reading the few
usual good laughs from TEDdy Bear, the great clown of our mailing
lists) since Autoconf will not be more 2.13 compatible in the future.

If people consider we deliberatedly broken bugward compatibility, then
fine, you're free to be wrong.  It's not what happened (and I can tell
you that a lot of code would not have been written if that was our
intention), but I don't care what people think wrt this now,
because...

Because today the only reasonable attitude is asking ourselves how can
we help people making the move.  I worked *immensely* on autoupdate,
it took me days to write such a complex tool.  I wrote documentation
explaining proper Autoconf programming.  I added sections to ease the
transition.  I made public calls for people looking for help.  I'm
ready to do more, but please, tell me what is needed.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Akim Demaille]

> "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 hitting a M4 limitation
here.  Hopefully future version of GNU M4 will help.

Sascha> and contains a dependency-ignorant cache system.

Err.  It doesn't compute.

What do you mean?



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Akim Demaille]

> "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 big question which must be answered first: will it have
to be Autoconf 2.13 compatible?

I *strongly* suggest that it must not.  It should AC_PREREQ 2.54
immediately.  Then, I'm fine with checking the M4 code and making it
up to date.  If needed, I'll wrap a 2.55 with whatever is needed to
have Libtool work better with Autoconf.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: autoreconf misses ltmain.sh

[Akim Demaille]

| > 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  2002-09-24 06:35:04.496461535 -0700
| @@ -38,3 +38,12 @@
|  /*--.
|  | Sane for full scale use.  |
|  `--*/
| +
| +* Interoperability bugs
| +
| +** AC_CONFIG_AUX_DIR and libtool 1.4.2.
| +
| +Autoconf-generated scripts that use AC_CONFIG_AUX_DIR do not work with
| +libtool 1.4.2.  Robert Boehne and Michael Matz have published a patch
| +for libtool in:
| +.

Please, install!


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Automake 1.6d available (beta for Automake 1.7)

[Akim Demaille]

| 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.

It's already the case, as you just proved.



I appreciate very much your suggestions, but I have another: run the
betas.  Once there will be enough people running the betas, there will
probably be less bugs released.  As of today, I run CVS Autoconf
etc. on a large set of packages, including the very demanding
Coreutils.  Plus I send announcements for betas.  After this, I feel
in peace with myself when I release.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: autoreconf misses ltmain.sh

[Akim Demaille]

> "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 mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: autoreconf misses ltmain.sh

[Akim Demaille]

| 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.
| >  Ralf> => There doesn't exist any officially released version of libtool that
| >  Ralf> is usable with autoconf-2.54 and automake-1.7
| > 
| > Not exactly: there is no release of Libtool that honors
| > AC_CONFIG_AUX_DIR in configure.*ac*.
| > 
| >  Ralf> .. still nobody wanting to care to fix it?
| > 
| > AFAICT it's fixed in CVS Libtool.
| 
| We are talking about released SW rsp. to be released SW here.
| 
| The current situation is: libtool and autoreconf do not interact
| together, rendering autoreconf entirely useless and unreliable in total
| in many situations, no matter if libtool is the culprit or not.
| 
| Pointing users to cvs versions is acceptable as long a tool is in
| development, however once a tool is release, this situation changes.
| Read: Users will yell at autoconf, because _it_ can't deal with released
| versions of libtool.
| 
| In my opinion it is prohibitive and stupid not to have a libtool release
| that can properly interact with autoconf.

This is my opinion too, and I have regularly sent messages to the
Libtool lists, but without affect.  They are still in CC of these
messages, but without any answer.

So as was kindly suggested by TED, we should have autoreconf work
around Libtool problems.  I have not read all the details yet, but
does anybody know what we must do to cope with Libtool 1.4.2?  Or,
does anybody know when another Libtool will be released?


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Configure tool/cvs repository trouble

[Akim Demaille]

> "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 a cvs repository?

There is no consensus, but autoreconf tries to address the issue f
``bootstrapping'' the package.  autoreconf 2.53 is not too bad, but
CVS autoreconf does quite a good job.  When I have such dependencies,
I always

autoreconf -fvi

and the right thing happens.  Gettext 0.11.3 will make it even easier
for packages that depend on Gettext (I mean, having installed 0.11.3
will make it work for _any_ version of Gettext, including oldies such
as 0.10.35 etc.).

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool and gcj

[Akim Demaille]

> "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?  Implementing this seems single,
Per> except for the interaction with --with-gcj.

I leave this decision to you and Tom, I'm not a Java programmer, and
I'm unable to make the decision.  Nevertheless, I'd like to suggest
that you introduce one or several languages named Java-whatever.  Have
a look at lib/autoconf/c.m4, lib/autoconf/fortran.m4 etc. for inspiration.

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Autoconf 2.53 is released

[Akim Demaille]

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.tar.bz2  (743 kB)

And here are xdelta-style diffs

  ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.52-2.53.xdelta   (215 kB)

Here are the MD5 and SHA1 signatures for the compressed tar files:

42948310deb847982004a3b0d936f7bb  autoconf-2.53.tar.gz
c121b003f51e293c2bf5a6105c721388  autoconf-2.53.tar.bz2
a9fe8460b4ed6f279f3d3f8a73eb39b19e93dc98  autoconf-2.53.tar.gz
c99aa737c0fe24c1cfcf0701e614e69f3ff07209  autoconf-2.53.tar.bz2

NEWS:

** Requirements

  Perl 5.005_03 or later is required: autom4te is written in Perl and is
  needed by autoconf.  autoheader, autoreconf, ifnames, and autoscan are
  rewritten in Perl.

** Documentation

- AC_INIT
  Argument requirements, output variables, defined macros.
- M4sugar, M4sh, Autotest
  First sketch.
- Double quoting macros
  AC_TRY_CPP, AC_TRY_COMPILE, AC_TRY_LINK and AC_TRY_RUN.
- Licensing
  The Autoconf manual is now distributed under the terms of the GNU FDL.
- Section `Hosts and Cross-Compilation'
  Explains the rationale for the 2.5x changes in the cross-compilation
  chain, and in the relationships between build, host, and target
  types.
  Emphasizes that `cross-compilation' == `--host is given'.
  If you are working on compilers etc., be sure to read this section.
- Section `AC_LIBOBJ vs. LIBOBJS'
  Explains why assigning LIBOBJS directly is now an error.
  Details how to update the code.

** configure

- $LINENO
  Now used instead of hard coded line numbers.
  This eases the comparison of `configure's, and diminishes the
  pressure over control version archives.
  Automatic replacement for shells that don't support this feature.
- New output variables
  @builddir@, @top_builddir@, @abs_srcdir@, @abs_top_srcdir@, @abs_builddir@,
  @abs_top_builddir@.

** Emacs

  Autoconf and Autotest modes are provided.

** Executables

- autom4te
  New, used by the Autoconf suite to cache and speed up most processing.
- --force, -f
  Supported by autom4te, autoconf and autoheader.
- --include, -I
  Replaces --autoconf-dir and --localdir in autoconf, autoheader,
  autoupdate, and autoreconf.
- autoreconf
  No longer passes --cygnus, --foreign, --gnits, --gnu, --include-deps:
  automake options are to be given via AUTOMAKE_OPTIONS.
- autoreconf
  Runs gettextize and libtoolize when appropriate.
- autoreconf
  --m4dir is no longer supported.
- autoreconf
  Now runs only in the specified directories, defaulting to `.',
  but understands AC_CONFIG_SUBDIRS for dependent directories.
  Before, it used to run on all the `configure.ac' found in the
  current tree.
  Independent packages are properly updated.

** Bug fixes

- The top level $prefix is propagated to the AC_CONFIG_SUBDIRS configures.
- AC_TRY_RUN
  Under the user pressure, $? is finally available.  Probably a mistake.
- AC_F77_LIBRARY_LDFLAGS now supports the HP/UX f90 compiler.
- Precious variables accumulation
  config.status could stack several copies of the precious variables
  assignments.
- AC_PATH_PROG and family.
  Works properly when given a literal path.
- AC_FUNC_SETPGRP
  Somewhere since 2.13, the result had been reversed.

** C Macros

- AC_C_BIGENDIAN supports the cross-compiling case.
- AC_C_BIGENDIAN accepts ACTION-IF-TRUE, ACTION-IF-FALSE, and
  ACTION-IF-UNKNOWN arguments.  All are facultative, and the default
  for ACTION-IF-TRUE is to define WORDS_BIGENDIAN like AC_C_BIGENDIAN
  always did.
- AC_C_LONG_DOUBLE now succeeds only if `long double' has more range or
  precision than `double'.

** Generic macros

- AC_INIT
  It now defines the preprocessor symbols PACKAGE_NAME,
  PACKAGE_TARNAME, PACKAGE_VERSION, PACKAGE_STRING, and
  PACKAGE_BUGREPORT.

- AC_INIT
  Admits a fourth optional parameter: the tar name.

- AC_CONFIG_COMMANDS, HEADERS, FILES, LINKS.
  Provide the user with srcdir, ac_srcdir, ac_top_srcdir, ac_builddir,
  ac_top_builddir, ac_abs_srcdir, ac_abs_top_srcdir, ac_abs_builddir,
  ac_abs_top_builddir.

- AC_CONFIG_COMMANDS, HEADERS, FILES, LINKS and AC_OUTPUT.
  Are much less expensive when using long lists of files.

- AC_PREFIX_PROGRAM
  Works with shell variables, and non alphanumeric names.

** Library macros

- AC_FUNC_STRERROR_R now sets STRERROR_R_CHAR_P, not HAVE_WORKING_STRERROR_R,
  because POSIX 1003.1-200x draft 7 says strerror_r returns int, not char *.

- AC_FUNC_STRTOD substitutes POW_LIB.

- AC_FUNC_STRNLEN
  New.

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool and gcj

[Akim Demaille]

> "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
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: distcheck fails after libtoolizing

[Akim Demaille]

> "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".  What could be causing this problem?

Maybe Autoconf.  Look in configure the section about a.out, a.exe
etc.  Maybe 2.52 was not cleaning it properly.

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Autoconf 2.52g is released

[Akim Demaille]

The following message is a courtesy copy of an article
that has been posted to gnu.utils.bug as well.


Of course there are still many things that ought to be done in
Autoconf, nevertheless, there is no point in waiting for the day where
Autoconf will be complete (as by definition, there is always something
wrong for someone).

We aim at releasing 2.53 within the next months.  This is also a call
for people ready to:

- improve the documentation
- upgrade existing specific macros
- import into Autoconf wide spread specific macros

Thanks!

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.52g.tar.gz   (959 kB)
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.52g.tar.bz2  (735 kB)

And here are xdelta-style diffs

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.52f-2.52g.xdelta   (50 kB)

Here are the MD5 and SHA1 signatures for the compressed tar files:

dcfbcb09bd49c4d3bb241ec77cd79bdf  autoconf-2.52g.tar.gz
28aaa993b7f105ec4fcebf99ecfaf5bd  autoconf-2.52g.tar.bz2
5bfb084cecb6c15583ecafcc4f4e0eff221e6e1c  autoconf-2.52g.tar.gz
1263c961cabc603186de2b5aeac07ddec9e76267  autoconf-2.52g.tar.bz2

NEWS:

** Requirements

  Perl 5.005_03 or later is required: autom4te is written in Perl and is
  needed by autoconf.  autoheader, autoreconf, ifnames, and autoscan are
  rewritten in Perl.

** Documentation

- AC_INIT
  Argument requirements, output variables, defined macros.
- M4sugar, M4sh, Autotest
  First sketch.
- Double quoting macros
  AC_TRY_CPP, AC_TRY_COMPILE, AC_TRY_LINK and AC_TRY_RUN.
- Licensing
  The Autoconf manual is now distributed under the terms of the GNU FDL.

** configure

- $LINENO
  Now used instead of hard coded line numbers.
  This eases the comparison of `configure's, and diminishes the
  pressure over control version archives.
  Automatic replacement for shells that don't support this feature.
- New output variables
  @builddir@, @top_builddir@, @abs_srcdir@, @abs_top_srcdir@, @abs_builddir@,
  @abs_top_builddir@.

** Emacs

  Autoconf and Autotest modes are provided.

** Executables

- autom4te
  New, used by the Autoconf suite to cache and speed up most processing.
- --force, -f
  Supported by autom4te, autoconf and autoheader.
- --include, -I
  Replaces --autoconf-dir and --localdir in autoconf, autoheader,
  autoupdate, and autoreconf.
- autoreconf
  No longer passes --cygnus, --foreign, --gnits, --gnu, --include-deps:
  automake options are to be given via AUTOMAKE_OPTIONS.
- autoreconf
  Runs gettextize and libtoolize when appropriate.
- autoreconf
  --m4dir is no longer supported.
- autoreconf
  Now runs only in the specified directories, defaulting to `.',
  but understands AC_CONFIG_SUBDIRS for dependent directories.
  Before, it used to run on all the `configure.ac' found in the
  current tree.
  Independent packages are properly updated.

** Bug fixes

- The top level $prefix is propagated to the AC_CONFIG_SUBDIRS configures.
- AC_TRY_RUN
  Under the user pressure, $? is finally available.  Probably a mistake.
- AC_F77_LIBRARY_LDFLAGS now supports the HP/UX f90 compiler.
- Precious variables accumulation
  config.status could stack several copies of the precious variables
  assignments.

** C Macros

- AC_C_BIGENDIAN supports the cross-compiling case.
- AC_C_BIGENDIAN accepts ACTION-IF-TRUE, ACTION-IF-FALSE, and
  ACTION-IF-UNKNOWN arguments.  All are facultative, and the default
  for ACTION-IF-TRUE is to define WORDS_BIGENDIAN like AC_C_BIGENDIAN
  always did.
- AC_C_LONG_DOUBLE now succeeds only if `long double' has more range or
  precision than `double'.

** Generic macros

- AC_INIT
  It now defines the preprocessor symbols PACKAGE_NAME,
  PACKAGE_TARNAME, PACKAGE_VERSION, PACKAGE_STRING, and
  PACKAGE_BUGREPORT.

- AC_CONFIG_COMMANDS, HEADERS, FILES, LINKS.
  Provide the user with srcdir, ac_srcdir, ac_top_srcdir, ac_builddir,
  ac_top_builddir, ac_abs_srcdir, ac_abs_top_srcdir, ac_abs_builddir,
  ac_abs_top_builddir.

- AC_CONFIG_COMMANDS, HEADERS, FILES, LINKS and AC_OUTPUT.
  Are much less expensive when using long lists of files.

** Library macros

- AC_FUNC_STRERROR_R now sets STRERROR_R_CHAR_P, not HAVE_WORKING_STRERROR_R,
  because POSIX 1003.1-200x draft 7 says strerror_r returns int, not char *.

- AC_FUNC_STRTOD substitutes POW_LIB.

- AC_FUNC_STRNLEN
  New.

ChangeLog entries:

**
ChangeLog   24 Jan 2002 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.

2002-01-24  Akim Demaille  <[EMAIL PROTECTED]>

* lib/m4sugar/m4sh.m4 (_AS_LINENO_PREPARE): Use PATH_SEPARATOR.
(_AS_PATH_SEPARATOR_PREPARE): Don't expect $SHELL to be
Bourne. U

Re: Potential bash 2.05 issues with 'set'

[Akim Demaille]

> "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

Re: Potential bash 2.05 issues with 'set'

[Akim Demaille]

> "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!  ;)

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool and echo (Was: bison-1.29c 'configure' problems on Solaris 8)

[Akim Demaille]

>>>>> "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 instance it would help Libtool which needs a good
>> `echo'.

Paul> Could you give more details about this?  What 'echo' features
Paul> does Libtool need, other than those features standardized by
Paul> POSIX?

This I won't be able to answer correctly, Libtool people should know
better than I do.

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: _LT_AC_TAGCONFIG versus Cray sed

[Akim Demaille]

> "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 appending configuration tag "CXX" to libtool

Kevin> which I think might be from _LT_AC_TAGCONFIG,

Kevin> case `$echo "X$tagname" | $Xsed -e
Kevin> 's/[[-_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890,/]]//g'`
Kevin> in

Kevin> There was a discussion not so long ago about using "/" in a
Kevin> character range when it's also the delimiter, but I forget what
Kevin> the theory was.

Cf. Autoconf's documentation.


`sed'
 Patterns should not include the separator (unless escaped), even
 as part of a character class.  In conformance with POSIX, the Cray
 `sed' will reject `s/[^/]*$//': use `s,[^/]*$,,'.

 Sed scripts should not use branch labels longer than 8 characters
 and should not contain comments.

 Don't include extra `;', as some `sed', such as NetBSD 1.4.2's,
 try to interpret the second as a command:

  $ echo a | sed 's/x/x/;;s/x/x/'
  sed: 1: "s/x/x/;;s/x/x/": invalid command code ;

 Input should have reasonably long lines, since some `sed' have an
 input buffer limited to 4000 bytes.

 Alternation, `\|', is common but POSIX.2 does not require its
 support, so it should be avoided in portable scripts.  Solaris 8
 `sed' does not support alternation; e.g. `sed '/a\|b/d'' deletes
 only lines that contain the literal string `a|b'.

 Anchors (`^' and `$') inside groups are not portable.

 Nested parenthesization in patterns (e.g., `\(\(a*\)b*)\)') is
 quite portable to modern hosts, but is not supported by some older
 `sed' implementations like SVR3.

 Of course the option `-e' is portable, but it is not needed.  No
 valid Sed program can start with a dash, so it does not help
 disambiguating.  Its sole usefulness is helping enforcing
 indenting as in:

  sed -e INSTRUCTION-1 \
  -e INSTRUCTION-2

 as opposed to

  sed INSTRUCTION-1;INSTRUCTION-2

 Contrary to yet another urban legend, you may portably use `&' in
 the replacement part of the `s' command to mean "what was
 matched".  All descendents of Bell Lab's V7 `sed' (at least; we
 don't have first hand experience with older `sed's) have supported

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libltdl & 64-bit lint

[Akim Demaille]

>> 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/listinfo/libtool

Portability of find(1)

[Akim Demaille]

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: \{\}" ...

At least on DU.

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

RFC: Autoconf 2.50 is released

[Akim Demaille]

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

ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.50.tar.gz

b3d78c5aefd53ed69d93182239af65e3  autoconf-2.50.tar.gz
ae8d8bd7718fa6fd6e4b77cb8cb4332ef50dfaa8  autoconf-2.50.tar.gz

Happy configuring!

Akim, Alexandre, Jim, Pavel, Paul, and Tom.

* Major changes in Autoconf 2.50

** Lots of bug fixes
There have been far too many to enumerate them here.  Check out
ChangeLog if you really want to know more.

** Improved documentation
In particular, portability issues are better covered.

** Use of Automake
All the standard GNU Makefile targets are supported.  The layout has
changed: m4/ holds the m4 extensions Autoconf needs for its
configuration, doc/ contains the documentation, and tests/ contains
the test suite.

** Man pages are provided
For autoconf, autoreconf, autoupdate, autoheader, autoscan, ifnames,
config.guess, config.sub.

** autoconf
- --trace
  Provides a safe and powerful means to trace the macro uses.  This
  provide the parsing layer for tools which need to `study'
  configure.in.

- --warnings
  Specify what category of warnings should be enabled.

- When recursing into subdirectories, try for configure.gnu before
  configure to adapt for packages not using autoconf on case-insensitive
  filesystems.

- Diagnostics
  More errors are now caught (circular AC_REQUIRE dependencies,
  AC_DEFINE in the action part of an AC_CACHE_CHECK, too many pops
  etc.).  In addition, their location and call stack are given.

** autoupdate
autoupdate is much more powerful, and is able to provide the glue code
which might be needed to move from an old macro to its newer
equivalent.

You are strongly encouraged to use it to modernize both your
`configure.in' and your .m4 extension files.

** autoheader
The internal machinery of autoheader has completely changed.  As a
result, using `acconfig.h' should be considered to be obsoleted, and
you are encouraged to get rid of it using the AH macros.

** autoreconf
Extensive overhaul.

** Fortran 77 compilers
Globally, the support for Fortran 77 is considerably improved.

Support for automatically determining a Fortran 77 compiler's
name-mangling scheme.  New CPP macros F77_FUNC and F77_FUNC_ are
provided to wrap C/C++ identifiers, thus making it easier and more
transparent for C/C++ to call Fortran 77 routines, and Fortran 77 to
call C/C++ routines.  See the Texinfo documentation for details.

** Test suite
The test suite no longer uses DejaGNU.  It should be easy to submit
test cases in this new framework.

** configure
- --help, --help=long, -hl
  no longer dumps useless items.
- --help=short, -hs
  lists only specific options.
- --help=recursive, -hr
  displays the help of all the embedded packages.
- Remembers environment variables when reconfiguring.
  The previous scheme to set envvar before running configure was
ENV=VAL ./configure
  what prevented configure from remembering the environment in which
  it was run, therefore --recheck was run in an inconsistent
  environment.  Now, one should run
./configure ENV=VAR
  and then --recheck will work properly.  Variables declared with
  AC_ARG_VAR are also preserved.
- cross-compilation
  $build defaults to `config.guess`, $host to $build, and then $target
  to $host.
  Cross-compilation is a global status of the package, it no longer
  depends upon the current language.
  Cross compilation is enabled iff the user specified `--host'.
  `configure' now fails if it can't run the executables it compiles,
  unless cross-compilation is enabled.
- Cache file
  The cache file is disabled by default.  The new options
  `--config-cache', `-C' set the cache to `config.cache'.

** config.status
- faster
  Much faster on most architectures.
- concurrent executions
  It is safe to use `make -j' with config.status.
- human interface improved
  It is possible to invoke
./config.status foobar
  instead of the former form (still valid)
CONFIG_COMMANDS= CONFIG_HEADERS= CONFIG_LINKS= \
CONFIG_FILES=foobar:foo.in:bar.in \
./config.status
  The same holds for configuration headers and links.
  You can instantiate unknown files and headers:
./config.status --header foo.h:foo.h.in --file bar:baz
- has a useful --help
- accepts special file name "-" for stdin/stdout


** Identity Macros
- AC_COPYRIGHT
  Specify additional copyright information.

- AC_INIT
  Now expects the identity of the package as argument.

** General changes.
- Uniform quotation
  Most macros, if not all, now strictly follow the `one quotation
  level' rule.  This results in a more predictable expansion.

- AC_REQUIRE
  A sly bug in the AC_REQUIRE machinery, which could produce incorrect
  configure scripts, was fixed by Axel Thimm.

** Setu

Re: ltconfig fails during 'configure'

[Akim Demaille]

> "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_CANNONICAL_TARGET, which works.  It seems
Robert> to me that AC_CANNONICAL_HOST should set $host, so perhaps
Robert> this is a bug in the Autoconf macro.

???

/tmp % cat configure.ac  nostromo Err 1
AC_INIT
echo 1. $host
AC_CANONICAL_HOST
echo 2. $host
/tmp % ace   nostromo 15:05
/tmp % ./configure   nostromo 15:05
1.
configure: error: cannot find install-sh or install.sh in . ./.. ./../..
/tmp % ./configure --srcdir=$ace nostromo Err 1
1.
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
2. i686-pc-linux-gnu

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Autoconf 2.49c: Release candidate

[Akim Demaille]

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 the documentation
and minor details still need some work.

Since there is a significant number of changes, we would like to ask
maintainers to give a try to this version, so that problems be
identified before the 2.50 release.

Autoconf can be downloaded from

ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.49c.tar.gz

Happy configuring!

Akim, Alexandre, Jim, Pavel, Paul, and Tom.

NEWS:

* Major changes in Autoconf 2.49c   -*- outline -*-

** Lots of bug fixes
Way too many for us to spell them out.  Check out ChangeLog if you
really want to know more.

** Improved documentation
In particular portability issues are better covered.

** Use of Automake
All the standard GNU Makefile targets are supported.  The layout has
changed: m4/ holds the m4 extensions Autoconf needs for its
configuration, doc/ contains the documentation, and tests/ the test
suite.

** Man pages are provided
For autoconf, autoreconf, autoupdate, autoheader, autoscan, ifnames,
config.guess, config.sub.

** autoconf
- --trace
  Provides a safe and powerful means to trace the macro uses.  This
  provide the parsing layer for tools which need to `study'
  configure.in.

- --warnings
  Specify what category of warnings should be enabled.

- When recursing into subdirectories, try for configure.gnu before
  configure to adapt for packages not using autoconf on case-insensitive
  filesystems.

- Diagnostics
  More errors are now caught (circular AC_REQUIRE dependencies,
  AC_DEFINE in the action part of an AC_CACHE_CHECK, too many pops
  etc.).  In addition, their location and call stack are given.

** autoupdate
autoupdate is much more powerful, and is able to provide the glue code
which might be needed to move from an old macro to its newer
equivalent.

You are strongly encouraged to use it both to modernize your
`configure.in', but also your .m4 extension files.

** autoheader
The internal machinery of autoheader has completely changed.  As a
result, using an `acconfig.h' should be considered as obsoleted, and
you are encouraged to get rid of it using the AH macros.

** autoreconf
Deep overhaul.

** Fortran 77 compilers
Globally, the support for Fortran 77 is considerably improved.

Support for automatically determining a Fortran 77 compilers
name-mangling scheme.  New CPP macros F77_FUNC and F77_FUNC_ are
provided to wrap C/C++ identifiers, thus making it easier and more
transparent for C/C++ to call Fortran 77 routines, and Fortran 77 to
call C/C++ routines.  See the Texinfo documentation for details.

** Test suite
The test suite no longer uses DejaGNU.  It should be easy to submit
test cases in this new frame work.

** configure
- --help, --help=long, -hl
  no longer dumps useless items.
- --help=short, -hs
  lists only specific options.
- --help=recursive, -hr
  displays the help of all the embedded packages.
- Remembers environment variables when reconfiguring.
  The previous scheme to set envvar before running configure was
ENV=VAL ./configure
  what prevented configure from remembering the environment in which
  it was run, therefore --recheck was run in an inconsistent
  environment.  Now, one should run
./configure ENV=VAR
  and then --recheck will work properly.  Variables declared with
  AC_ARG_VAR are also preserved.
- cross-compilation
  $build defaults to `config.guess`, $host to $build, and then $target
  to $host.
  Cross-compilation is a global status of the package, it no longer
  depends upon the current language.
  Cross compilation is enabled iff the user specified `--host'.
  `configure' now fails if it can't run the executables it compiles,
  unless cross-compilation is enabled.
- Cache file
  The cache file is disabled by default.  The new options
  `--config-cache', `-C' set the cache to `config.cache'.

** config.status
- faster
  Much faster on most architectures.
- concurrent executions
  It is safe to use `make -j' with config.status.
- human interface improved
  It is possible to invoke
./config.status foobar
  instead of the former form (still valid)
CONFIG_COMMANDS= CONFIG_HEADERS= CONFIG_LINKS= \
CONFIG_FILES=foobar:foo.in:bar.in \
./config.status
  The same holds for configuration headers and links.
  You can instantiate unknown files and headers:
./config.status --header foo.h:foo.h.in --file bar:baz
- has a useful --help


** Identity Macros
- AC_COPYRIGHT
  Specify additional copyright information.

- AC_INIT
  Now expects the identity of the package as argument.

** General changes.
- Uniform quotation
  Most macros, if not all, now strictly follow the `one quotation
  level' rule.  This results in a more predictable expansion.

- AC_REQUIRE
  A sly b

Re: CVS Autotools

[Akim Demaille]

> "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://mail.gnu.org/mailman/listinfo/libtool

Re: CVS Autotools

[Akim Demaille]

>>>>> "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> The following simple configure.in seems to be causing problems,
Raja> with the latest CVS libtool from the multi-language-branch, and
Raja> CVS autoconf.

Raja>   AC_INIT
Raja>   AC_PROG_LIBTOOL
Raja>   AC_PROG_CXX
Raja>   AC_OUTPUT

The way Libtool changes some Autoconf macros is doomed to failure.  We
can't proceed this way.  Something must be decided.  I'd suggest that
we target, after 2.50 and 1.4, some release of Autoconf together with
Libtool, adjusted one for the other?

Autoconf will provide hooks where Libtool needs them, but we can't
continue with Libtool redefining internals.  And I'm very afraid this
is not doable when targeting both 2.13 and 2.50.

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

ac_ (Was: Remove -fPIC -DPIC under DJGPP)

[Akim Demaille]

+*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/listinfo/libtool

CVS Autotools

[Akim Demaille]

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

Re: Forbidden strings

[Akim Demaille]

> "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?_ as a variable or function.  I as a
Earnie> user should never declare _A?_ as a variable or function.

Let it be for elegance: why would you want to run _AU_DEFUN instead of
AU_DEFUN etc.  Leading underscore has another meaning: private.  _AC_
is private to Autoconf, _AU_ to autoupdate etc.  That's a different
issue.

And anyway, you just delay the problem to the day someone will need
_AR_FLAGS, or _AC_OPTIONS.

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Forbidden strings

[Akim Demaille]

> "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> ownership of all of A?_.  That looks a little bit
Alexandre> exagerated to me.

Still, why should we struggle for AR_ and not for AC_?  How can we
decide that users must not use AC_ in their configure.in?  I
personally think it is saner to get all these A?_* names, because we
already use many of them and will use even more in the future, and to
provide a means to declare what are the symbols to allow, as compared
to catching only a random number of A[CHUMS]_ and provide no escape.

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Forbidden strings

[Akim Demaille]

> "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 based on a
simple fact: if today the Libtool team needs AR, maybe tomorrow they
will want AC_.  Them, or anybody else.  So just putting the feet where
it seems sane ([ACUHTS]) seems just a means to hide the problem to me.
That's also why I insisted on having autoconf.sh produce configure
even if there are forbidden strings in it: how can you be sure that's
not what meant the author.

So, how about something like a special comment/macro stating what are
the *words* that are allowed.  Something like

m4_accept_literals([AR_FLAGS], [lt_cv_AR_FLAGS])

then autoconf.sh would just gather these guys, and say nothing about
them.

Akim

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Forbidden strings

[Akim Demaille]

> "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

Re: Forbidden strings

[Akim Demaille]

> "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?  Not necessarily *_m4_*, but at least
_m4_*.

>> What should we do?

Pavel> Return to A[CHMSTU]

I'd rather take almost the full range and except AR if we need to.

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Forbidden strings

[Akim Demaille]

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:5870: error: undefined macro: lt_AR_FLAGS
configure:5870: error: undefined macro: AR_FLAGS

What should we do?

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Patch] interlibrary dependency parsing in libltdl from CVS HEAD

[Akim Demaille]

> "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 should never be empty, nor contain any IFS, so it shouldn't
matter to have quotes, and in fact it would hide problems.

But maybe I just don't know enough about libtool :)

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [PATCH] Fix for bootstrapping with latest CVS Autoconf

[Akim Demaille]

> "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/listinfo/libtool

Re: [PATCH] Fix for bootstrapping with latest CVS Autoconf

[Akim Demaille]

| 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 backquotes are
| interpreted, and issues a warning (even though it works correctly) in
| case they're written the way it used to work with autoconf 2.13.
| 
| Replacing \` with ' is even worse, because then the shell won't
| expand the variable within `', as we want it.

That's why Morten used ' only :)

| The only way to do it so that it works with both autoconf 2.13 and CVS
| autoconf, without triggering the warning in CVS autoconf, is this
| (from CVS automake's missing.m4):
| 
|   am_backtick='`'
|   AC_MSG_WARN([${am_backtick}$VAR' ...])

This is s heavy :( As I proposed to Pavel, I'm OK with moving this
warning from `syntax' to `obsolete' for 2.50, and move it back to
`syntax' in 2.51 or later.  This way, every body is happy.  ?

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: changequote used incorrectly

[Akim Demaille]

> "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.

Re: changequote used incorrectly

[Akim Demaille]

| 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 quote characters
| > to `<<' and `>>'.
| 
| (not a good recommendation ;-)

Yes, this is a bad recommendation.  And in fact you frightened me
Pavel, by current you mean 2.13, right?  I could not find this horror
in the CVS documentation.  But there is an answer to the above
statement:

>   It is frequent to read Autoconf programs with snippets like:
>
> AC_TRY_LINK(
> changequote(<<, >>)dnl
> <<#include 
> #ifndef tzname /* For SGI.  */
> extern char *tzname[]; /* RS6000 and others reject char **tzname.  */
> #endif>>,
> changequote([, ])dnl
> [atoi (*tzname);], ac_cv_var_tzname=yes, ac_cv_var_tzname=no)
>
>which is incredibly useless since `AC_TRY_LINK' is _already_ double
>quoting, so you just need:
>
> AC_TRY_LINK(
> [#include 
> #ifndef tzname /* For SGI.  */
> extern char *tzname[]; /* RS6000 and others reject char **tzname.  */
> #endif],
> [atoi (*tzname);],
> [ac_cv_var_tzname=yes],
> [ac_cv_var_tzname=no])
>
>The M4 fluent reader noted that these two writings are rigorously
>equivalent, since `m4' swallows both the `changequote(<<, >>)' and `<<'
>`>>' when it "collects" the arguments: these quotes are not part of the
>arguments!
>
>   Simplified, the example above is just doing this:
>
> changequote(<<, >>)dnl
> <<[]>>
> changequote([, ])dnl
>
>instead of simply
>
> [[]]
>
>   With macros which do not double quote their arguments (which is the
>rule), double quote the (risky) literals:
>
> AC_LINK_IFELSE([AC_LANG_PROGRAM(
> [[#include 
> #ifndef tzname /* For SGI.  */
> extern char *tzname[]; /* RS6000 and others reject char **tzname.  */
> #endif]],
> [atoi (*tzname);])],
>[ac_cv_var_tzname=yes],
>[ac_cv_var_tzname=no])
>

So in the case Pavel fixed, I'd suggest to follow the advice of Lars.

Akim

Re: Ensuring compatibility between libtool components

[Akim Demaille]

> "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 ltconfig and ltmain.sh into the build dir,
Alexandre> then proceed to the usual configuration stuff.

Why not using something more simple, such as passing an envvar with
the version or things like this?

In fact, I don't know too well what is the exact problem you're
fighting with, but if I understand correctly, AC_PROG_LIBTOOL runs
ltconfig, so when running it, it sure can pass its version by envvar
and have ltconfig check it.  Conversely, since AC_PROG_LIBTOOL will
run ltconfig, it sure knows where it is, so it can run a simple grep
to fetch the version, and ensure the comparison.

Autoconf has already comparable machinery for AC_PREREQ.  I can make
it ``public'' for you to use it.

I don't want to document it, since it would be tempting for people to
use it.

Or you can just import the corresponding code.

Re: Why does ltconfig unset CC?

[Akim Demaille]

| +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_PROG_CXX])[AC_LIBTOOL_CXX
| +])])
| +#
| +# Quote A][M_PROG_GCJ so that aclocal doesn't bring it in needlessly.
| +# If either AC_PROG_GCJ or A][M_PROG_GCJ have already been expanded, run
| +# AC_LIBTOOL_GCJ immediately, otherwise, hook it in at the end of both.
| +  AC_PROVIDE_IFELSE([AC_PROG_GCJ],
| +[AC_LIBTOOL_GCJ],
| +[AC_PROVIDE_IFELSE([A][M_PROG_GCJ],
| +[AC_LIBTOOL_GCJ],
| + [ifdef([AC_PROG_GCJ],
| +[define([AC_PROG_GCJ], defn([AC_PROG_GCJ])[AC_LIBTOOL_GCJ
| +])])#
| +  ifdef([A][M_PROG_GCJ],
| +[define([A][M_PROG_GCJ], defn([A][M_PROG_GCJ])[AC_LIBTOOL_GCJ
| +])])])])])

The comments here are typically `dnl' comments: they address Autoconf
expansion issues.  I have nothing against this personally, # is more
readable than dnl, but it is just so that you remember that this means
the comments will show up in `configure', in place where they will
make no sense.

The fact that you meant to talk about names of macros (hence `break'
them so that autoconf does not complain) is a clear sign of it.

Re: [PATCH] "Fix" to libtool.m4 to work with current CVS autoconf

[Akim Demaille]

| 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.

Re: Target for libtool?

[Akim Demaille]

> "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 already seen code that tested whether target =
Alexandre> NONE, so it might be wise to keep it unchanged.

:(

It's a lot more code for free.  I cannot understand what drove the
choice of NONE for some default values :(

Can't we go and see the people who do that and tell here how to adjust
their code?  I've looked in several `configure.in', and none include
such thing.  And it is not documented (but this is a stupid argument,
agreed: people had to know the default to use it).

Akim

~/src % fgrep NONE **/configure.in
bash-2.04/configure.in: test "x$prefix" = xNONE && _rl_prefix=$ac_default_prefix || 
_rl_prefix=${prefix}
bash-2.04/configure.in: test "x$exec_prefix" = xNONE && _rl_exec_prefix=${_rl_prefix} 
|| _rl_exec_prefix=${exec_prefix}
bc/configure.in:if test "${prefix}" = "NONE" ; then 
egcs/gcc/configure.in:  if test "x$exec_prefix" = xNONE; then
egcs/gcc/configure.in:  if test "x$prefix" = xNONE; then
egcs/gcc/configure.in:if test x$exec_prefix = xNONE -o x$exec_prefix = x$prefix; then
emacs/configure.in:if test "${x_libraries}" != NONE && test -n "${x_libraries}"; then
emacs/configure.in:if test "${x_includes}" != NONE && test -n "${x_includes}"; then
emacs/configure.in:  if test "${x_libraries}" != NONE && test -n "${x_libraries}"; then
emacs/configure.in:test "${prefix}" != NONE &&
emacs/configure.in:test "${exec_prefix}" != NONE &&
libc/sysdeps/unix/sysv/linux/configure.in:  if test "x$prefix" != xNONE; then


Packages:

Abison ace ace-sourceware ac-trunk automake automake/tests/testSubDir
bash-2.04 bash-2.04/lib/termcap/grot bc bi++/gnu/bison bison bison-cvs
bison-old cvs-utils egcs egcs/etc egcs/gcc emacs flex fu gawk
gawk/gawk-3.1.84/=build/gawk-3.1.84 gawk/gawk-3.1.84 gzip-1.3 libc
libc/posix/glob libc/sysdeps/generic libc/sysdeps/mach/hurd
libc/sysdeps/unix/common libc/sysdeps/unix
libc/sysdeps/unix/sysv/linux/alpha libc/sysdeps/unix/sysv/linux
libc/sysdeps/unix/sysv/sysv4/solaris2 m4-1.4n make recode sed shtool
textutils tiger wdiff-0.5g

Re: Target for libtool?

[Akim Demaille]

> "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 :(

Akim

Re: AM_ENABLE_SHARED?

[Akim Demaille]

>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:

Alexandre> 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> AC_PROG_LIBTOOL

>> Will probably disappear if you move to AC_, not AM_.  Untested.

Alexandre> Why would it disappear?  One just `indir's the other.

Hm, I don't know.  Massive thinko.  It looked nice and pro to say
that.  

I should stop smoking the grass and start walking on it :)

Akim

Re: assorted problems

[Akim Demaille]

> "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 obsolete.
>> configure.in:29: warning: AC_C_CONST was called before
>> AC_PROG_CC_STDC

Erez> I've asked about it a while back, and was told that these were
Erez> new changes in autoconf/automake and that you wanted to wait
Erez> until autconf became more stable.  It's been a while since those
Erez> changes were put in, no?  Shouldn't libool try to keep up w/
Erez> autoconf?  I think it has to, b/c once the new autoconf is
Erez> released, you'd pretty much have to update libtool so the
Erez> warnings go away (else you'll get many similar user complaints).

The picture is no longer to have the three amigos released together.
In particular, neither next Automake nor next Libtool will use newer
names.

It took quite a while until people, especially Alexandre, managed to
convince me that those warnings are frightening people, so there will
be an option in autoconf to enable those warnings.

AC_LANG_C and so on are broken, so from the point of view of Autoconf
we have to move to AC_LANG(C).  There are plenty of other macros which
changed or are obsoleted.  But it is probably too soon to have
Automake and Libtool depend upon it.

Nevertheless, once next Autoconf and next Libtool are released,
Autoconf will be, and shortly afterwards there should be a release of
Automake and Libtool using the newer Autoconf.

Akim

Re: AM_ENABLE_SHARED?

[Akim Demaille]

> "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.