FYI: fix bogus merge (Libtool HEAD)
Hi Patrick, Regarding your recent problem report[1] with a m4 loop in CVS autotools: While I can reproduce it over here, I have not found its cause yet. But it turned up another bug in Libtool CVS HEAD, presumably caused by a bogus CVS merge. Checked in the patch below as obvious. (This bug shows up only if you do `sinclude(libtool.m4)', not if aclocal pulls in the macros.) Cheers, Ralf [1] http://lists.gnu.org/archive/html/libtool/2005-07/msg00023.html 2005-07-11 Ralf Wildenhues [EMAIL PROTECTED] * m4/libtool.m4 (_LT_CHECK_XSI_SHELL): Fix bogus merge. Reported by Patrick Welche [EMAIL PROTECTED]. Index: m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v retrieving revision 1.202 diff -u -r1.202 libtool.m4 --- m4/libtool.m4 8 Jul 2005 14:59:59 - 1.202 +++ m4/libtool.m4 11 Jul 2005 12:04:53 - @@ -6213,8 +6213,6 @@ = c,a/b,, ) /dev/null 21 \ xsi_shell=yes AC_MSG_RESULT([$xsi_shell]) -]) -fi _LT_CONFIG_LIBTOOL_INIT([xsi_shell='$xsi_shell']) ])# _LT_CHECK_XSI_SHELL
RE: MSYS+MSVC for libtool branch-2-0, take 2
On Mon, 11 Jul 2005, Peter Ekberg wrote:
You don't seem to understand what's going on... On MSYS there
is no official way to convert a posix path to a win32 path
(like cygpath on Cygwin). But if you execute any executable
outside of the MSYS /bin or /usr/bin directories (and perhaps
other places as well?), any argument that looks like a posix
path is converted to a win32 path on the assumption that all
such executables expect win32 paths. The problem is that in
this case the conversion needs to be done not on an argument,
but on an environment variable that MSYS does not autoconvert.
So, it needs to be converted manually. So, since there is no
official way to convert paths, I run a program outside of MSYS
and as one of its arguments I have the posix path to be
converted. The program I have chosen to run is the command
This is the script I run under MSYS or Cygwin to convert a POSIX path
to a win32 paths with varying amount of escaping in case the result
needs to be handled by a script later. It has been pointed out to me
that Windows converts forward slashes to backslashes so it is not
necessary to generate backslashes, but paths are often seen by Windows
users so I try to generate paths which are familiar to them.
#!/bin/sh
# Copyright (C) 2003 GraphicsMagick Group
#
# This program is covered by multiple licenses, which are described in
# Copyright.txt. You should have received a copy of Copyright.txt with this
# package; otherwise see http://www.graphicsmagick.org/www/Copyright.html.
#
# Convert the specified POSIX path to a Windows path under MinGW and Cygwin
# The optional second parameter specifies the level of backslash escaping
# to apply for each Windows backslash position in order to support varying
# levels of variable substitutions in scripts.
#
# Note that Cygwin includes the 'cygpath' utility, which already provides
# path translation capability.
#
# Written by Bob Friesenhahn [EMAIL PROTECTED] June 2002
#
arg=$1
escapes=0
if test -n $2
then
escapes=$2
fi
if test $escapes -gt 3
then
echo $0: escape level must in range 0 - 3
exit 1
fi
result=''
length=0
max_length=0
mount | sed -e 's:\\:/:g' | (
IFS=\n
while read mount_entry
do
win_mount_path=`echo $mount_entry | sed -e 's: .*::g'`
unix_mount_path=`echo $mount_entry | sed -e 's:.* on ::;s: type .*::'`
temp=`echo $arg | sed -e s!^$unix_mount_path!$win_mount_path!`
if test $temp != $arg
then
candidate=$temp
length=${#unix_mount_path}
if test $length -gt $max_length
then
result=$candidate
max_length=$length
fi
fi
done
if test -z $result
then
echo $0: path \$arg\ is not mounted
exit 1
fi
case $escapes in
0)
echo $result | sed -e 's:/:\\:g'
;;
1)
echo $result | sed -e 's:/::g'
;;
2)
echo $result | sed -e 's:/::g'
;;
3)
echo $result | sed -e 's:/::g'
;;
esac
exit 0;
)
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
RE: MSYS+MSVC for libtool branch-2-0, take 2
On Mon, 11 Jul 2005, Peter Ekberg wrote: Yes, I came across that one, but it seemed heavy handed for the job at hand. I think my approach is neater, but I'm biased :-) In what way is your script better than my version that simply uses the cmd script from MSYS? I am not sure that my script is better. It just happens to work identically across MSYS and Cygwin without using tools peculiar to either environment. All it needs is 'mount' and 'sed'. Neither approach has a chance to work in a cross compile setup, which was the objection to my approach... Quite true. Cross compile needs special care. It is quite rare for Windows executables to include hard-coded paths. This is much more common for Unix. So Unix software which is quickly ported to Windows may need to include some hard-coded paths. Windows software doesn't have any notion of an installation prefix except for at software install time. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: branch 2.0, make install DESTDIR=
Hi Charles,
* Charles Wilson wrote on Sun, Jul 10, 2005 at 08:46:26PM CEST:
is broken -- at least on cygwin, but probably everywhere.
*snip*
tar: configure: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
tar: configure: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
chown -R root
/usr/src/libtool/devel/CVS/libtool-b2.0/.inst/usr/local/share/libt
ool/libltdl \
chgrp -R root
/usr/src/libtool/devel/CVS/libtool-b2.0/.inst/usr/local/share/libt
ool/libltdl || :
chown: `root': invalid user
chmod +x
/usr/src/libtool/devel/CVS/libtool-b2.0/.inst/usr/local/share/libtool/config.guess
chmod: cannot access
`/usr/src/libtool/devel/CVS/libtool-b2.0/.inst/usr/local/share/libtool/config.guess':
No such file or directory
(A) cross-platform? There is no configure script in $SRCDIR/libltdl --
although there is a configure.ac. This looks like some disagreement
over whether libltdl is a sub-configure'd project or configured directly
as part of the overall libtool's configure.
I know. This has been broken for quite a while. There is a pending
patch by Gary to fix this, which is why I did not suggest a change of my
own. Unfortunately, it has been pending for quite a while.
It should not be a cause for `make install' failure, though.
(B) cygwin-specific: There is no root user. There might be a SYSTEM
user which is somewhat similar, and Administrator which is somewhat
similar in other ways -- but regardless there is no facility to do CHOWN
unless you're building as Administrator (not SYSTEM). Basically, this
whole chown idea in libtool's installation is fscked-up w.r.t. cygwin.
OK. Does `id -u' tell you whether you are SYSTEM (id 0?) or not?
What would be an appropriate solution for cygwin?
Please also note that discussion about how to resolve this best is still
going on[1]. I'm sorry that this caught you. It should not have been
the cause for the installation failure (except for the annoying but
harmless warning messages), though.
(C) ${instdir}/usr/local/share/libtool/config.guess doesn't exist
because it's actually called
${instdir}/usr/local/share/libtool/config/config.guess
ACK. Similarly as in (A), there is a patch pending. This should be the
root cause of the failure of `make install'.
Does anybody TEST this stuff before checking it in?
Yes, I do test almost all of my patches. There are more things broken
in branch-2-0 -- you will notice that the installed `libtoolize' does
not work either, because of the same issue, same pending fix.
Gary: if you would like me to propose a patch for (C) while you are
working on your patch, I can do so -- but only today. I'll be without
net access for a few weeks with few exceptions.
Cheers,
Ralf
[1] http://lists.gnu.org/archive/html/bug-libtool/2005-07/msg1.html
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Hi Keith, * Keith Packard wrote on Fri, Jul 08, 2005 at 11:42:57PM CEST: On Fri, 2005-07-08 at 11:23 +0200, Simon Richter wrote: Now I'm wondering whether it would make sense to add a switch to libtool that makes it not install those two things, such as -old-abi. I have to support two of these library versions as 'current' for other reasons, so applications need to be able to link against either libXaw7 or libXaw8 at build time, so I need two unversioned .so files... *snip* Yes, there are probably too many constraints on the solution space. Re-reading this thread, I would be inclined to accept a patch which implements your original proposal, given that a way can be found how it degrades gracefully on the different/not-so-flexible shared library systems mentioned. That is, unless the other maintainers oppose. (I personally won't there to review it for a while though, sorry.) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris
Hi Bruno, * Bruno Haible wrote on Mon, Jul 11, 2005 at 01:23:26PM CEST: The modules in gnulib are normally used in a directory that creates a single library, say libfoo.la, and in this case a line like all-local $(lib_OBJECTS): $(ARGZ_H) is meant to be changed to all-local $(libfoo_la_OBJECTS): $(ARGZ_H) If, in the case of libltdl, the directory creates several libraries, then yes your patch looks OK: Thanks. Fortunately, meanwhile I have found a different, IMHO easier way to fix this instead. Your comment is still valuable as clarification of allowed usage. Cheers, Ralf +## Make sure argz.h will be created before it is needed: +lib_OBJECTS = \ + $(dlopen_la_OBJECTS) \ + $(dld_link_la_OBJECTS) \ + $(dyld_la_OBJECTS) \ + $(load_add_on_la_OBJECTS) \ + $(loadlibrary_la_OBJECTS) \ + $(shl_load_la_OBJECTS) \ + $(libltdl_la_OBJECTS) \ + $(libltdlc_la_OBJECTS) + ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris
Ralf Wildenhues wrote: It's a bit tricky to reproduce: You need a system which has no argz.h, then configure, then `make check' without prior make. If you had ever run `make' before in this build tree, even after `make clean' the dependency information is stored in libltdl/.deps/*.Plo, and thus hides this bug. Now the gnulib snippet in libltdl/Makefile.am leaves us with the possibility of using the lib_OBJECTS variable to fix this(?). Several questions (thus the crosspost to all of these lists): - Is it ok/supposed by gnulib to use lib_OBJECTS for this? - Is it ok by Automake to use the *_OBJECTS variables it created, i.e., may they be treates as exported interface? The modules in gnulib are normally used in a directory that creates a single library, say libfoo.la, and in this case a line like all-local $(lib_OBJECTS): $(ARGZ_H) is meant to be changed to all-local $(libfoo_la_OBJECTS): $(ARGZ_H) If, in the case of libltdl, the directory creates several libraries, then yes your patch looks OK: +## Make sure argz.h will be created before it is needed: +lib_OBJECTS = \ + $(dlopen_la_OBJECTS) \ + $(dld_link_la_OBJECTS) \ + $(dyld_la_OBJECTS) \ + $(load_add_on_la_OBJECTS) \ + $(loadlibrary_la_OBJECTS) \ + $(shl_load_la_OBJECTS) \ + $(libltdl_la_OBJECTS) \ + $(libltdlc_la_OBJECTS) + Bruno ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: how to use circular dependencies
Hi Tom, * tom fogal wrote on Fri, Jul 08, 2005 at 08:14:51PM CEST: Hi all, I'm trying to get libtool to link a program that depends on a circular list of static (libtool) libraries. I'm using a command line like: ../../libtool --mode=link --preserve-dup-deps g77 -Wall -I../include -O0 -o partrj -static *.o ../ui/libParTrjUI.la ../models/libSPPModels.la ../share/libSPPShare.la ../models/libSPPModels.la ../grid/libSPPgrid.la ../fields/libSPPFields.la ../share/libSPPShare.la ../menus/libParTrjMenu.la ../strings/src/libSPPStrings.la ../hash/libHash.la ../dbg/libSPPdbg.la ../t89files/libSPPt89.la unfortunately this ends up not working because libtool is removing/reordering some of the libraries: I presume this is because the libraries have interdependencies listed in the respective .la files. g77 -Wall -I../include -O0 -o partrj bunch of .o files ../ui/.libs/libParTrjUI.a ../models/.libs/libSPPModels.a ../grid/.libs/libSPPgrid.a ../fields/.libs/libSPPFields.a ../share/.libs/libSPPShare.a ../menus/.libs/libParTrjMenu.a ../strings/src/.libs/libSPPStrings.a ../hash/.libs/libHash.a ../dbg/.libs/libSPPdbg.a ../t89files/.libs/libSPPt89.a --preserve-dup-deps doesn't seem to have an effect. I also tried remaking the command line using -L and -l options instead of explicitly specifying the .la file, with the same effect of libtool stripping out libraries from the link line. Hmm. Is the package that contains these libraries freely available online? If not: could you show the corresponding link lines for the libraries? (Either the Makefile.am snippets, or whatever `make' makes of it as libtool command line; plus libtool's output.) I found a post on libtool-patches from 2002, where someone else had run into this issue. They expected linker flags of -Wl,-( libs -Wl,-) to fix it. I changed my link line above to use these linker flags in the libtool command line, but I still get the same error. It appears as if the patch was never applied (why?)? Are you talking about this? http://lists.gnu.org/archive/html/libtool-patches/2002-09/msg7.html I can only guess it was not applied because it's a hack.. I am using libtool version '1.5.18 (1.1220.2.246 2005/05/16 10:00:18'. What am I doing wrong? How can one link in circular dependencies using libtool? Oh, most likely they are broken, but to be honest, I have no idea. We don't have a proper test for them, so we can't expect them to stay unbroken. The reason I have asked for details above is that we may be able to generate a decent test case from your situation, and then work from that. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Mon, 2005-07-11 at 13:58 +0200, Ralf Wildenhues wrote:
Re-reading this thread, I would be inclined to accept a patch which
implements your original proposal, given that a way can be found how it
degrades gracefully on the different/not-so-flexible shared library
systems mentioned. That is, unless the other maintainers oppose.
Ok, I've created a '-sobase' option in link mode and tested it on
GNU/Linux. It changes the -soname option passed to the linker so that
instead of using ${libname} for the first part of the soname, it uses
the -sobase parameter. It also includes this generated name as one of
the library_names so that when the library is installed, a symlink to
the soname
is made.
-keith
Index: config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v
retrieving revision 1.73
diff -u -p -r1.73 ltmain.m4sh
--- config/ltmain.m4sh 8 Jul 2005 13:45:59 - 1.73
+++ config/ltmain.m4sh 11 Jul 2005 19:25:05 -
@@ -348,6 +348,7 @@ The following components of LINK-COMMAND
-R[[ ]]LIBDIR add LIBDIR to the runtime path of programs and libraries
-shared only do dynamic linking of libtool libraries
-shrext SUFFIXoverride the standard shared library file extension
+ -sobase SOBASESet base of SONAME to SOBASE instead of LIBNAME
-static do not do any dynamic linking of libtool libraries
-version-info CURRENT[[:REVISION[:AGE]]]
specify library version info [[each variable defaults to 0]]
@@ -2484,6 +2485,13 @@ func_mode_link ()
prev=
continue
;;
+ sobase)
+ sobase_name=$arg
+ solib_names_spec=$soname_spec
+ prev=
+ continue
+ ;;
+
weak)
weak_libs=$weak_libs $arg
prev=
@@ -2760,6 +2768,11 @@ func_mode_link ()
continue
;;
+ -sobase)
+prev=sobase
+ continue
+ ;;
+
-static)
# The effects of -static are defined in a previous loop.
# We used to do the same as -all-static on platforms that
@@ -3703,6 +3716,9 @@ func_mode_link ()
realname=$1
shift
libname=`eval \\$ECHO \$libname_spec\`
+ if test -z $sobase_name; then
+ sobase_name=$libname
+ fi
# use dlname if we got it. it's perfectly good, no?
if test -n $dlname; then
soname=$dlname
@@ -4610,7 +4626,7 @@ EOF
fi
if test -n $i ; then
libname=`eval \\$ECHO \$libname_spec\`
- deplib_matches=`eval \\$ECHO \$library_names_spec\`
+ deplib_matches=`eval \\$ECHO \$library_names_spec $solib_names_spec\`
set dummy $deplib_matches; shift
deplib_match=$1
if test `expr $ldd_output : .*$deplib_match` -ne 0 ; then
@@ -4652,7 +4668,7 @@ EOF
fi
if test -n $i ; then
libname=`eval \\$ECHO \$libname_spec\`
- deplib_matches=`eval \\$ECHO \$library_names_spec\`
+ deplib_matches=`eval \\$ECHO \$library_names_spec $solib_names_spec\`
set dummy $deplib_matches; shift
deplib_match=$1
if test `expr $ldd_output : .*$deplib_match` -ne 0 ; then
@@ -4960,12 +4976,15 @@ EOF
# Get the real and link names of the library.
eval shared_ext=\$shrext_cmds\
- eval library_names=\$library_names_spec\
+ eval library_names=\$library_names_spec $solib_names_spec\
set dummy $library_names
shift
realname=$1
shift
+ if test -z $sobase_name; then
+ sobase_name=$libname
+ fi
if test -n $soname_spec; then
eval soname=\$soname_spec\
else
Index: m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.203
diff -u -p -r1.203 libtool.m4
--- m4/libtool.m4 11 Jul 2005 12:11:25 - 1.203
+++ m4/libtool.m4 11 Jul 2005 19:25:07 -
@@ -1745,7 +1745,7 @@ aix3*)
shlibpath_var=LIBPATH
# AIX 3 has no versioning support, so we append a major version to the name.
- soname_spec='${libname}${release}${shared_ext}$major'
+ soname_spec='${sobase_name}${release}${shared_ext}$major'
;;
aix4* | aix5*)
@@ -1786,7 +1786,7 @@ aix4* | aix5*)
# We preserve .a as extension for shared libraries through AIX4.2
# and later when we are not doing run time linking.
library_names_spec='${libname}${release}.a $libname.a'
- soname_spec='${libname}${release}${shared_ext}$major'
+ soname_spec='${sobase_name}${release}${shared_ext}$major'
fi
shlibpath_var=LIBPATH
fi
@@ -1812,7 +1812,7 @@ bsdi[[45]]*)
version_type=linux
need_version=no
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
+ soname_spec='${sobase_name}${release}${shared_ext}$major'
finish_cmds='PATH=\$PATH:/sbin ldconfig $libdir'
shlibpath_var=LD_LIBRARY_PATH
sys_lib_search_path_spec=/shlib /usr/lib /usr/X11/lib /usr/contrib/lib /lib /usr/local/lib
@@ -1849,12 +1849,12 @@ cygwin* | mingw* | pw32*)
case $host_os in
Re: how to use circular dependencies
[EMAIL PROTECTED]Ralf Wildenhues writes: Hi Tom, * tom fogal wrote on Fri, Jul 08, 2005 at 08:14:51PM CEST: Hi all, I'm trying to get libtool to link a program that depends on a circular list of static (libtool) libraries. I'm using a command line like: ../../libtool --mode=link --preserve-dup-deps g77 -Wall -I../include -O0 -o partrj -static *.o ../ui/libParTrjUI.la ../models/libSPPModels.la ../share/libSPPShare.la ../models/libSPPModels.la ../grid/libSPPgrid.la ../fields/libSPPFields.la ../share/libSPPShare.la ../menus/libParTrjMenu.la ../strings/src/libSPPStrings.la ../hash/libHash.la ../dbg/libSPPdbg.la ../t89files/libSPPt89.la unfortunately this ends up not working because libtool is removing/reordering some of the libraries: I presume this is because the libraries have interdependencies listed in the respective .la files. erm.. hopefully? This is all an autoconf/automake generated thing; it appears I was doing what are called 'libtool convenience libraries'. I simply pulled out + posted the line that caused problems. g77 -Wall -I../include -O0 -o partrj bunch of .o files ../ui/.libs/libParTrjUI.a ../models/.libs/libSPPModels.a ../grid/.libs/libSPPgrid.a ../fields/.libs/libSPPFields.a ../share/.libs/libSPPShare.a ../menus/.libs/libParTrjMenu.a ../strings/src/.libs/libSPPStrings.a ../hash/.libs/libHash.a ../dbg/.libs/libSPPdbg.a ../t89files/.libs/libSPPt89.a --preserve-dup-deps doesn't seem to have an effect. I also tried remaking the command line using -L and -l options instead of explicitly specifying the .la file, with the same effect of libtool stripping out libraries from the link line. Hmm. Is the package that contains these libraries freely available online? If not: could you show the corresponding link lines for the unfortunately, no. libraries? (Either the Makefile.am snippets, or whatever `make' makes of it as libtool command line; plus libtool's output.) Sure. /bin/sh ../../libtool --mode=link g77 -Wall -I../include/ -pedantic-errors -fno-f90 -fno-automatic -finit-local-zero -fugly-complex -fugly-init -Wno-globals -g -O2 -o libSPPdbg.la dbg_basics.lo dbg_bevals.lo dbg_constants.lo dbg_harpol.lo dbg_interp.lo dbg_position.lo dbg_ivector.lo dbg_vector.lo dbg_vlstrn.lo ar cru .libs/libSPPdbg.a .libs/dbg_basics.o .libs/dbg_bevals.o .libs/dbg_constants.o .libs/dbg_harpol.o .libs/dbg_interp.o .libs/dbg_position.o .libs/dbg_ivector.o .libs/dbg_vector.o .libs/dbg_vlstrn.o ranlib .libs/libSPPdbg.a creating libSPPdbg.la (cd .libs rm -f libSPPdbg.la ln -s ../libSPPdbg.la libSPPdbg.la) You'll notice that the above has slightly different flags than what you would guess based on earlier lines I've included. Since I reported this, I've determined we don't really /need/ libtool at all, so I removed it from the project. After that I heard the project was missing some flags that should be there, from the source code author, so I've added them in. The line I just gave above is from me changing one of the Makefile.ams to use libtool again. The relevant Makefile.am snippets are: # old way -- using libtool noinst_LTLIBRARIES=libSPPdbg.la libSPPdbg_la_SOURCES= \ dbg_basics.f \ dbg_bevals.f \ dbg_constants.f \ dbg_harpol.f \ dbg_interp.f \ dbg_position.f \ dbg_ivector.f \ dbg_vector.f \ dbg_vlstrn.f [EMAIL PROTECTED]@lib/libSPPstrings.la The new way is the same but s/LTLIBRARIES/LIBRARIES/ and s/la/a/. All the libaries are (were) built in this same manner. I found a post on libtool-patches from 2002, where someone else had run into this issue. They expected linker flags of -Wl,-( libs -Wl,-) to fix it. I changed my link line above to use these linker flags in the libtool command line, but I still get the same error. It appears as if the patch was never applied (why?)? Are you talking about this? http://lists.gnu.org/archive/html/libtool-patches/2002-09/msg7.html Ooops, sorry! I had thought I included the link; mea culpa. Thanks for doing the research again for me =) I can only guess it was not applied because it's a hack.. =( I am using libtool version '1.5.18 (1.1220.2.246 2005/05/16 10:00:18'. What am I doing wrong? How can one link in circular dependencies using libtool? Oh, most likely they are broken, but to be honest, I have no idea. We don't have a proper test for them, so we can't expect them to stay unbroken. The reason I have asked for details above is that we may be able to generate a decent test case from your situation, and then work from that. Well if theres more I can do to help in building a test case, just let me know / ask. -tom ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch 2.0, make install DESTDIR=
Ralf Wildenhues wrote: (B) cygwin-specific: There is no root user. There might be a SYSTEM user which is somewhat similar, and Administrator which is somewhat similar in other ways -- but regardless there is no facility to do CHOWN unless you're building as Administrator (not SYSTEM). Basically, this whole chown idea in libtool's installation is fscked-up w.r.t. cygwin. OK. Does `id -u' tell you whether you are SYSTEM (id 0?) or not? What would be an appropriate solution for cygwin? Please also note that discussion about how to resolve this best is still going on[1]. I'm sorry that this caught you. It should not have been the cause for the installation failure (except for the annoying but harmless warning messages), though. I think you'd want to try to chown to UID 18 (SYSTEM), but the euid of the process running the install will not be 18. It'll Administrator (local machine, not member of Windows Domain) == 500, or Administrator (local machine, but machine is member of domain) == 10500 (unless the domain member offset has been changed to something other than 1). Or it might be J.Q.RandomUser with Administrator privileges. Or a Domain Administrator account. etc. I guess what it boils down to, is on cygwin you should attempt to chown to 18, but ignore failure, because there's no good way to tell if it's going to work other than simply to try it. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
