Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Hi Charles, Charles Wilson wrote: Roumen Petrov wrote: [SNIP] If you can come up with a mechanism to use absolute paths in dlname, which does not break any of the known installation modes, works whether the installation tree(s) are pre-created or NOT, and whether the final installation tree contains symlinks or NOT, AND solves the issue with getting DLLs on w32 into the correct directory AND that the installed .la file correctly describes its location... Then please show us the code. And the test results. On as many systems as Dave has, especially including mingw, cygwin, linux, and various cross environments. Please find attached file libtool-origin-bindir.patch with my idea for absolute path in la-file. [SNIP] -- Chuck Roumen diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index d8c5749..381bef5 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated specially: -all-static do not do any dynamic linking at all -avoid-versiondo not add a version suffix if possible + -bindir BINDIRspecify path to binaries directory (for systems where +libraries must be found in the PATH setting at runtime) -dlopen FILE \`-dlpreopen' FILE if it cannot be dlopened at runtime -dlpreopen FILE link in FILE and add its symbols to lt_preloaded_symbols -export-dynamic allow symbols from OUTPUT-FILE to be resolved with dlsym(3) @@ -1631,10 +1633,10 @@ func_mode_install () dir=$func_dirname_result dir=$dir$objdir - if test -n $relink_command; then - # Determine the prefix the user has applied to our future dir. - inst_prefix_dir=`$ECHO $destdir | $SED -e s%$libdir\$%%` + # Determine the prefix the user has applied to our future dir. + inst_prefix_dir=`$ECHO $destdir | $SED -e s%$libdir\$%%` + if test -n $relink_command; then # Don't allow the user to place us outside of our expected # location b/c this prevents finding dependent libraries that # are installed to the same prefix. @@ -1696,7 +1698,7 @@ func_mode_install () # Do each command in the postinstall commands. lib=$destdir/$realname - func_execute_cmds $postinstall_cmds 'exit $?' + func_execute_cmds inst_prefix_dir=$inst_prefix_dir~$postinstall_cmds 'exit $?' fi # Install the pseudo-library for information purposes. @@ -3674,6 +3676,9 @@ func_mode_link () new_inherited_linker_flags= avoid_version=no +# heuristic location of shared libraries for system without +# shared library path variable different from PATH +dlbindir=../bin dlfiles= dlprefiles= dlself=no @@ -3766,6 +3771,11 @@ func_mode_link () esac case $prev in + bindir) + dlbindir=$arg + prev= + continue + ;; dlfiles|dlprefiles) if test $preload = no; then # Add the symbol object into the linking commands. @@ -4027,6 +4037,11 @@ func_mode_link () continue ;; + -bindir) + prev=bindir + continue + ;; + -dlopen) prev=dlfiles continue @@ -7721,7 +7736,8 @@ EOF # place dlname in correct position for cygwin tdlname=$dlname case $host,$output,$installed,$module,$dlname in - *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;; + *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) + tdlname=$dlbindir/$dlname;; esac $ECHO $output \ # $outputname - a libtool library file diff --git a/libltdl/ltdl.c b/libltdl/ltdl.c index 80b5675..ea5d51f 100644 --- a/libltdl/ltdl.c +++ b/libltdl/ltdl.c @@ -480,7 +480,7 @@ tryall_dlopen_module (lt_dlhandle *handle, const char *prefix, int error = 0; char *filename = 0; size_t filename_len = 0; - size_t dirname_len = LT_STRLEN (dirname); + size_t dirname_len = (*dlname == '/') ? (size_t)0: LT_STRLEN (dirname); assert (handle); assert (dirname); @@ -494,7 +494,7 @@ tryall_dlopen_module (lt_dlhandle *handle, const char *prefix, if (dirname_len 0) if (dirname[dirname_len -1] == '/') --dirname_len; - filename_len = dirname_len + 1 + LT_STRLEN (dlname); + filename_len = (*dlname == '/' ? (size_t)0 : (dirname_len + 1)) + LT_STRLEN (dlname); /* Allocate memory, and combine DIRNAME and MODULENAME into it. The PREFIX (if any) is handled below. */ @@ -502,7 +502,10 @@ tryall_dlopen_module (lt_dlhandle *handle, const char *prefix, if (!filename) return 1; - sprintf (filename, %.*s/%s, (int) dirname_len, dirname, dlname); + if (*dlname == '/') +strncpy (filename, dlname, filename_len + 1); + else +sprintf (filename, %.*s/%s, (int) dirname_len, dirname, dlname); /* Now that we have combined DIRNAME and MODULENAME, if there is also a PREFIX to contend with, simply recurse with the arguments diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 3a65ec4..18710b0 100644 ---
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Dave Korn wrote: Roumen Petrov wrote: The calculation or relative path to dll is based on function XXX_abspath that may produce wrong results. No it doesn't. Like any function, it produces the correct results when given valid inputs, but if you give it bad input, you get GIGO. :) :) :-D I suggest you go read the fine manual about the realpath and abspath functions, because until you understand the difference between these two functions you're just wasting everybody's time. :) *Your suggestion to use realpath instead of abspath requires magic or time-travel before it is even possible, which is why I will waste no time on it.* Reading all above seems to my you mix mail threads and/or lists. I'm concerned that we can't implement a working portable(cross-platform) relative path calculation. But that is exactly what I have done. It works, it is in portable code, it operates the same on all platforms. It has an implicit requirement that you do not pass it a path containing a symlink. As does *everything else* in autotools. :) :) :) Dave, you even don't understand what is wrong. What is better for dlname for installed la-file: absolute or relative path ? That you could even ask such a question demonstrates that you don't understand the subject you are pontificating about. Go and read up about how 'configure' works and what a prefix is. Please, countdown before to post (hint: manual is libtool) . cheers, DaveK Roumen
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote: Dave Korn wrote: *Your suggestion to use realpath instead of abspath requires magic or time-travel before it is even possible, which is why I will waste no time on it.* Reading all above seems to my you mix mail threads and/or lists. Nonsense, I'm not engaged in conversation with you on any other list. This is the one and only threads and/or lists where someone is suggesting I try to use realpath on a directory before it is created; that requires time-travel or magic. :) :) :) Dave, you even don't understand what is wrong. No, I haven't got the faintest idea what's wrong, but whatever your problem is, it can't be solved by computer code. Go and read up about how 'configure' works and what a prefix is. Please, countdown before to post (hint: manual is libtool) . Hint: libtool is one tiny part of a huge interlocking system. cheers, DaveK
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote:
I'm concerned that we can't implement a working portable(cross-platform)
relative path calculation.
In the general case, Roumen, you are correct: there IS no portable
mechanism to compute relative paths when non-portable constructs such as
symbolic links are/may-be involved.
This is not the general case. This is a libtool- and DLL- specific
installation issue; we should not try to rewrite the entire auto* suite
to accommodate a wacky *hypothetical* installation tree organization not
currently supported by any GNU toolset, to fix one small corner case in
libtool.
Frankly, your hypothetical worry is not even a problem that libtool
should attempt to work around, for two reasons:
1) If the installation --prefix (AND DESTDIR/${prefix} as well!) is not
fully created PRIOR to build, then you cannot assume that when it IS
created, it will contain symbolic links, nor will you have ANY idea
where those future, hypothetical symbolic links will hypothetically
point to. So any attempt to use canonical_path or realpath (as opposed
to abspath) is doomed to failure, EVEN on those systems where (a)
realpath/canonical_path is supported, and (b) symbolic links are supported.
2) The current system is just as broken NOW, as libtool with Dave's fix
would be in your hypothetical case. In fact, the current system is EVEN
WORSE than any situation you have yet dreamed up. ../bin is WRONG, even
on non-symlink systems, even with pre-created installation trees, even
when they do or do not contain symlinks: if --bindir and --libdir are
not _exactly_ siblings under the same parent.
We've just been fortunate, because in 99.999% of the cases, --bindir and
--libdir ARE siblings, and are both directly under ${exec_prefix}.
Except for one, really BIG, exception: gcc (and three or four others
Yaakov has mentioned).
So, Dave's patch fixes the current problem, and does NOT make your
hypothetical (and completely unfixable anyway; see #1) case any worse.
The only possibility of fixing your complaint is to change the .la
format to specify the full absolute path to the dlname. Doing THAT
would, instead, break DESTDIR and GNU Coding Standard-required 'make
install prefix=${override_prefix}' installs, without a lot of additional
changes to the .la-.lai installation process. And even then,
computing accurately these absolute paths and fully resolving any
hypothetical symbolic links would require the installation tree (whether
$(prefix), ${override_prefix}, or DESTDIR/${prefix}) to be fully created
prior to 'make'.
Not. Gonna. Happen.
If you can come up with a mechanism to use absolute paths in dlname,
which does not break any of the known installation modes, works whether
the installation tree(s) are pre-created or NOT, and whether the final
installation tree contains symlinks or NOT, AND solves the issue with
getting DLLs on w32 into the correct directory AND that the installed
.la file correctly describes its location...
Then please show us the code. And the test results. On as many systems
as Dave has, especially including mingw, cygwin, linux, and various
cross environments.
Oh, and please make sure you do all of this before the GCC 4.5 stage 1
development window closes, currently scheduled for the end of August.
Otherwise, please stop letting the perfect (IMO, the perfectly
impossible) be the enemy of the good.
:) :) :) Dave, you even don't understand what is wrong.
With respect, Roumen, I believe it is you that are misdiagnosing the
problem.
--
Chuck
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Charles Wilson wrote: Roumen Petrov wrote: Dave Korn wrote: Roumen Petrov wrote: [SNIP] Why? abspath != realpath. That's the point. If you're arguing that all GNU installation tools should use realpath to canonicalize all paths before use, well...maybe that discussion should be held, in some other thread with a broader audience as it affects MUCH more than just libtool. But (a) your desired behavior is not the case now, in a lot of places other than libtool, (b) doing it your way will badly break DESTDIR installations and any installation where the target installation directory tree is not fully created at build/installation time (c) and you'll get a lot of pushback from automake/autoconf on that. Summary: in what way does Dave's patch make libtool behavior worse than current? The calculation or relative path to dll is based on function XXX_abspath that may produce wrong results. The algorithm to calculated absolute path is acceptable only for DOS like file systems. Next implementation of -bindir flag may require changes in automake rule. Otherwise why will pass this flag to libtool ? Next automake rule is not expected to create bindir, right ? I'm not against to be removed current hard-coded libtoll '../bin/xx' DDL rule. The Dave XX_abspath function for test case ported in previous my email produce /work/tmp/test/test-links/b (incorrect). Compare with command readlink -f ../1/../. It is /work/tmp/test/test-links/a (correct !). I'm concerned that we can't implement a working portable(cross-platform) relative path calculation. What is better for dlname for installed la-file: absolute or relative path ? May be is better to put DLL in bindir as is passed to libtool and to write in installed la-file as is ? [SNIP] -- Chuck Roumen
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote: The calculation or relative path to dll is based on function XXX_abspath that may produce wrong results. No it doesn't. Like any function, it produces the correct results when given valid inputs, but if you give it bad input, you get GIGO. I suggest you go read the fine manual about the realpath and abspath functions, because until you understand the difference between these two functions you're just wasting everybody's time. *Your suggestion to use realpath instead of abspath requires magic or time-travel before it is even possible, which is why I will waste no time on it.* I'm concerned that we can't implement a working portable(cross-platform) relative path calculation. But that is exactly what I have done. It works, it is in portable code, it operates the same on all platforms. It has an implicit requirement that you do not pass it a path containing a symlink. As does *everything else* in autotools. What is better for dlname for installed la-file: absolute or relative path ? That you could even ask such a question demonstrates that you don't understand the subject you are pontificating about. Go and read up about how 'configure' works and what a prefix is. cheers, DaveK
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Hi Dave,
sorry for making you go through another round.
Except for the sed issues the following nits are all mechanical, and it
would suffice if you re-checked only your new tests and only on one of
the affected systems.
I consider the patch ready after this round, but I will probably leave a
couple of days for the w32 experts to comment on it, before applying it.
* Dave Korn wrote on Sun, Aug 16, 2009 at 02:55:22AM CEST:
@item -R @var{libdir}
If @var{output-file} is a program, add @var{libdir} to its run-time
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 4bc304c..9954057 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -100,6 +100,149 @@ func_dirname_and_basename ()
# Generated shell functions inserted here.
+pathcar=s,^/\([^/]*\).*$,\1,
+pathcdr=s,^/[^/]*,,
+removedotparts=s,/\(\.\(/\|$\)\)\+,/,g
+collapseslashes=s,/\+,/,g
\+ is a GNU sed extension, \{1,\} is Posix (two instances).
Nested \( \) are not portabled sed, neither are alternations \|.
Anchors $ inside groups are not portable.
The nesting probably works on most systems we care about, but if we can
avoid it then I'd prefer to do so.
(Sorry btw for completely overlooking this the last time.)
+func_relative_path ()
+{
+ *)
+func_dirname $func_relative_path_tlibdir
+func_relative_path_tlibdir=${func_dirname_result}
+if test x$func_relative_path_tlibdir = x ; then
Please double-quote $func_relative_path_tlibdir. The rest of your patch
seems to cope with with spaces in file name components (even if the rest
of Libtool may not).
--- /dev/null
+++ b/tests/bindir.at
+# These routines save the PATH before a test and restore it after,
+# prepending a chosen directory to the path on the platforms where
+# -bindir is needed after saving.
+#
+
+func_save_and_prepend_path ()
+{
+ save_PATH=$PATH
+ if $bindirneeded ; then
+PATH=$1:$PATH
+ fi
+ export PATH
+}
+
+func_restore_path ()
+{
+ PATH=$save_PATH
No 'export PATH' here? (two instances)
+}
+# Check both static and shared versions run. We don't install them
+# here, that will be covered by the later tests; we've rpath'd things
+# so that they can all be run in situ.
+
+AT_CHECK([$LIBTOOL --mode=execute ./main$EXEEXT], [], [stdout])
Please use LT_AT_NOINST_EXEC_CHECK here, to avoid error when cross
compiling. Similar for the other executions of uninstalled programs.
(This macro is defined in tests/testsuite.at.)
+# Ensure libraries can be found on PATH, if we are on one
+# of the affected platforms, before testing the shared version.
+
+func_save_and_prepend_path $curdir/.libs
+AT_CHECK([$LIBTOOL --mode=execute ./.libs/main$EXEEXT], [], [stdout])
eval `$LIBTOOL --config | grep '^objdir='`
func_save_and_prepend_path $curdir/$objdir
LT_AT_NOINST_EXEC_CHECK(... $objdir/...)
I'm afraid the direct execution of programs below .libs may not work
everywhere. I'd have to check to be sure though. It's fine with me
if you run this particular test only on systems of interest to you.
+# In fact, prepending the PATH as above is superfluous on the windows
+# platforms that this feature is primarily aimed at, as the DLL search
+# path always includes the directory from which the app was launched.
+# To make sure it still works even when not side-by-side, we'll install
+# the main executable and execute it from there while the PATH still
+# points to the shared libs in the .libs subdir. On other platforms,
+# the rpaths we set at link time will guarantee it runs from the bindir.
+
+mkdir $curdir/bin
+AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT
$curdir/bin/main$EXEEXT], [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout])
This one should work without $LIBTOOL --mode=execute prepended, no?
In that case, you could use LT_AT_EXEC_CHECK here, again, to avoid
spurious failures when cross compile testing.
If you care about the fact that an installed program does not
accidentally require, or search for, a library in an uninstalled
location, then you can, after the mode=install but before the execution,
clean up the files in the build tree, or even put a poisoned library
into the build tree. I don't think either is necessary to do in this
test (at least the latter seems overkill, as we do it in other tests
already), but please decide for yourself.
+AT_SETUP([bindir install tests])
+curdir=`pwd`
+for libdir in \
+ $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
+ $curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//. \
+ $curdir/usr/lib/ \
+ $curdir/usr/lib \
+ $curdir/baz \
+ $curdir/baz/lib/ ;
Mini nit: this ; is not necessary. :-)
+do
+
+ # Do a basic install with no -bindir option for reference. We use the
sbin/
+ # dir for the main exe to avoid the potential this only works because it's
+ # side-by-side with the libs
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote:
Hi Dave,
sorry for making you go through another round.
:-/ That'll teach me to say unless there's anything else?
+pathcar=s,^/\([^/]*\).*$,\1,
+pathcdr=s,^/[^/]*,,
+removedotparts=s,/\(\.\(/\|$\)\)\+,/,g
+collapseslashes=s,/\+,/,g
\+ is a GNU sed extension, \{1,\} is Posix (two instances).
Nested \( \) are not portabled sed, neither are alternations \|.
Aaarrrgghh *headdesk* no alternations? That's ... just ... it's
not even boolean! Grrnashrollfoamgibber Damn you, ATT! Damn you, Sun!
*shakes fist at crowd of greying bearded sandal-wearing old programmers* See
you in hell, Unix-boys! pulls pin out of a negated character class and
laughs maniacally
Anchors $ inside groups are not portable.
The nesting probably works on most systems we care about, but if we can
avoid it then I'd prefer to do so.
Okeydokey, simplified the SED scripts.
+if test x$func_relative_path_tlibdir = x ; then
Please double-quote $func_relative_path_tlibdir. The rest of your patch
seems to cope with with spaces in file name components (even if the rest
of Libtool may not).
Woops, yes, that was the intention, missed that one. One more quick check
over all the quoting won't hurt while I'm at it.
+func_restore_path ()
+{
+ PATH=$save_PATH
No 'export PATH' here? (two instances)
So I reread the autoconf portable shell bit, found the bit about export, now
I know why it needs re-exporting each time it gets changed; will add the
missing directive.
+AT_CHECK([$LIBTOOL --mode=execute ./main$EXEEXT], [], [stdout])
Please use LT_AT_NOINST_EXEC_CHECK here, to avoid error when cross
compiling. Similar for the other executions of uninstalled programs.
(This macro is defined in tests/testsuite.at.)
Thanks for pointing me at it, can do.
+# Ensure libraries can be found on PATH, if we are on one
+# of the affected platforms, before testing the shared version.
+
+func_save_and_prepend_path $curdir/.libs
+AT_CHECK([$LIBTOOL --mode=execute ./.libs/main$EXEEXT], [], [stdout])
eval `$LIBTOOL --config | grep '^objdir='`
func_save_and_prepend_path $curdir/$objdir
LT_AT_NOINST_EXEC_CHECK(... $objdir/...)
Ah, thanks, that beats hard-coding .libs/.
I'm afraid the direct execution of programs below .libs may not work
everywhere. I'd have to check to be sure though. It's fine with me
if you run this particular test only on systems of interest to you.
I think it's easier to just make it install the test executable.
Also, gah! Can't run a program because it's in a subdirectory? What
kind of hare=brained system is that? Would it help if I gave -rpath $objdir
when linking main as well as for the libs?
+# In fact, prepending the PATH as above is superfluous on the windows
+# platforms that this feature is primarily aimed at, as the DLL search
+# path always includes the directory from which the app was launched.
+# To make sure it still works even when not side-by-side, we'll install
+# the main executable and execute it from there while the PATH still
+# points to the shared libs in the .libs subdir. On other platforms,
+# the rpaths we set at link time will guarantee it runs from the bindir.
+
+mkdir $curdir/bin
+AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT
$curdir/bin/main$EXEEXT], [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout])
This one should work without $LIBTOOL --mode=execute prepended, no?
I have no idea. I just copied the only other things in the testsuite that I
could identify as execution tests. What does it actually *do*?
In that case, you could use LT_AT_EXEC_CHECK here, again, to avoid
spurious failures when cross compile testing.
Point taken.
If you care about the fact that an installed program does not
accidentally require, or search for, a library in an uninstalled
location, then you can, after the mode=install but before the execution,
clean up the files in the build tree, or even put a poisoned library
into the build tree. I don't think either is necessary to do in this
test (at least the latter seems overkill, as we do it in other tests
already), but please decide for yourself.
Deleting the libs from the build tree seems easiest.
+AT_SETUP([bindir install tests])
+curdir=`pwd`
+for libdir in \
+$curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
+$curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//. \
+$curdir/usr/lib/ \
+$curdir/usr/lib \
+$curdir/baz \
+$curdir/baz/lib/ ;
Mini nit: this ; is not necessary. :-)
It's still valid, isn't it? I don't like to make my syntax in a way that
only works because of line breaks.
+ AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -no-undefined -shared -o
libfoo.la $CPPFLAGS $CFLAGS $LDFLAGS foo.lo bar.lo baz.lo -rpath
$libdir],[0],[ignore],[ignore])
Please drop -shared, it should be unnecessary.
Ok, will do.
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
* Dave Korn wrote on Sun, Aug 16, 2009 at 06:26:11PM CEST:
Ralf Wildenhues wrote:
sorry for making you go through another round.
:-/ That'll teach me to say unless there's anything else?
Hehe.
\+ is a GNU sed extension, \{1,\} is Posix (two instances).
Nested \( \) are not portabled sed, neither are alternations \|.
Aaarrrgghh *headdesk* no alternations? That's ... just ... it's
not even boolean! Grrnashrollfoamgibber Damn you, ATT! Damn you, Sun!
*shakes fist at crowd of greying bearded sandal-wearing old programmers* See
you in hell, Unix-boys! pulls pin out of a negated character class and
laughs maniacally
It's still Turing complete, so nothing that can't be worked around ...
;-
I'm afraid the direct execution of programs below .libs may not work
everywhere. I'd have to check to be sure though. It's fine with me
if you run this particular test only on systems of interest to you.
I think it's easier to just make it install the test executable.
Also, gah! Can't run a program because it's in a subdirectory?
No, that's not the reason. The reason is the following: we don't always
try to make the uninstalled executables have hardcoded rpaths against
the uninstalled libraries: that would require us to relink at
installation time. On some systems, you can --{en,dis}able-fast-install
to state you preference over relinking at make install time vs.
relinnking at mode=execute uninstalled-program time. In the latter
case, it's the wrapper script/executable outside of the .libs directory
that provides for the machinery.
Your direct execution of .libs/main then by-passes that machinery.
What
kind of hare=brained system is that? Would it help if I gave -rpath $objdir
when linking main as well as for the libs?
Naa, don't do that, that's totally against the intention.
+AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT
$curdir/bin/main$EXEEXT], [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout])
This one should work without $LIBTOOL --mode=execute prepended, no?
I have no idea. I just copied the only other things in the testsuite that I
could identify as execution tests. What does it actually *do*?
Run an installed program. Installed programs ought to run without
$LIBTOOL prepended.
+AT_SETUP([bindir install tests])
+curdir=`pwd`
+for libdir in \
+ $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
+ $curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//. \
+ $curdir/usr/lib/ \
+ $curdir/usr/lib \
+ $curdir/baz \
+ $curdir/baz/lib/ ;
Mini nit: this ; is not necessary. :-)
It's still valid, isn't it?
Yes.
I don't like to make my syntax in a way that
only works because of line breaks.
OK, leave it like it is.
Out of curiosity, which of the systems of interest creates a
libfoo.so.0 file?
Linux.
But you're not interested in testing GNU/Linux with $bindirneeded.
Neither any of the other unices, which might not have a libfoo.so.0,
but instead a libfoo.a (shared library! sic! on AIX) or a libfoo.0.so
or libfoo.so.0.0 or whatnot. So make life easy here, and drop all the
.so thingy tests, you don't want them here. Thanks.
What if that is a symlink rather than a plain file
(test -f only tests for plain files)?
It is. The test still passes. H. better take a closer look at
that. (And use the full so.0.0.0 name in the test).
Yeah, that's due to $bindirneeded.
+# Clear any old stuff out before we install. Because bindir
+# may be in /tmp, we have to take care to create it securely
+# and not to delete and recreate it if we do.
+rm -rf $libdir $curdir/bin $curdir/sbin $curdir/baz $curdir/usr
2/dev/null
I'd drop the 2/dev/null; let's see errors in the log.
It makes a load of ugly noise when it tries to delete
$curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//., but I
guess it's better that than missing something important.
Thanks.
Cheers,
Ralf
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Dave Korn wrote: So, here I hope is the final respin. Built and tested on i686-pc-cygwin and i686-pc-linux-gnu with no regressions and all new tests passing (see below sig separator for details). libtool/ChangeLog: * Makefile.am (TESTSUITE_AT): Add bindir.at. * libltdl/config/general.m4sh (func_normal_abspath): New function. (func_relative_path): Likewise. * libltdl/config/ltmain.m4sh (func_mode_link): Accept new -bindir option and use it, if supplied, to place Windows DLLs. * tests/bindir.at: New file for DLL install tests. * doc/libtool.texi (Link Mode): Update documentation. Unless I've missed anything? I think that processing of '..' in a path is too naive. It will fail to produce correct results on filesystems with links. cheers, DaveK Roumen
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote: I think that processing of '..' in a path is too naive. It will fail to produce correct results on filesystems with links. As I explained to Eric, this function implements 'abspath', not 'realpath', and given that we can't assume any of the directories even exist when we have to do this at link time, before installation, I don't see how we could hope to do any different. I think the whole of GNU configure expects the tree under $prefix/ to be real and there are a lot of other things that will break if you try to use symlinks to make the physical directory structure different from the apparent structure, for example gcc tries to execute ld by starting at the $prefix/lib/gcc/$target/$version directory where cc1 lives and invoking ../../../../bin/ld; if you've got symlinks in there that can't be ascended without ending up somewhere other than you expect, then the compiler isn't going to work. So I don't think this is likely to cause any problem except in really bizarre corner-cases where someone's already trying something dubious, is it? cheers, DaveK
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Ralf Wildenhues wrote: * Dave Korn wrote on Sun, Aug 16, 2009 at 06:26:11PM CEST: +AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT $curdir/bin/main$EXEEXT], [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout]) This one should work without $LIBTOOL --mode=execute prepended, no? I have no idea. I just copied the only other things in the testsuite that I could identify as execution tests. What does it actually *do*? Run an installed program. Installed programs ought to run without $LIBTOOL prepended. Did you mean Run an *un*installed program in the first part of that? I'll assume so. Out of curiosity, which of the systems of interest creates a libfoo.so.0 file? Linux. But you're not interested in testing GNU/Linux with $bindirneeded. Neither any of the other unices, which might not have a libfoo.so.0, but instead a libfoo.a (shared library! sic! on AIX) or a libfoo.0.so or libfoo.so.0.0 or whatnot. So make life easy here, and drop all the .so thingy tests, you don't want them here. Thanks. But I do want to make sure the file went to the right place, or at the very least, that it did *not* go to the -bindir. Hmm. I can't easily use a pattern match either as it might match more than one file and confuse the test -f syntax. Guess I'll have to `ls *foo*0*` them and test -z the output, that should work. What if that is a symlink rather than a plain file (test -f only tests for plain files)? It is. The test still passes. H. better take a closer look at that. (And use the full so.0.0.0 name in the test). Yeah, that's due to $bindirneeded. But that just makes it test -f for the same name in a different directory, so it still ought to fail. It turns out that, at least for bash on my Fedora 10 VM, test -f works for symlinks: [da...@ubique .libs]$ if test -f libfoo.so.0 ; then echo yes ; else echo no ; fi yes [da...@ubique .libs]$ if test -f libfoo.so.0.0.0 ; then echo yes ; else echo no ; fi yes [da...@ubique .libs]$ ls -la libfoo.so.0* lrwxrwxrwx 1 davek davek 15 2009-08-16 20:55 libfoo.so.0 - libfoo.so.0.0.0 -rwxrwxr-x 1 davek davek 5425 2009-08-16 20:55 libfoo.so.0.0.0 [da...@ubique .libs]$ echo $BASH_VERSION 3.2.39(1)-release [da...@ubique .libs]$ Weird. Anyway, I won't rely on it. cheers, DaveK
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Dave Korn wrote: Guess I'll have to `ls *foo*0*` them and test -z the output, that should work. Nope, may have whitespace. Is checking the return status of ls portable? cheers, DaveK
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Dave Korn wrote:
Roumen Petrov wrote:
I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.
As I explained to Eric, this function implements 'abspath', not 'realpath',
and given that we can't assume any of the directories even exist when we have
to do this at link time, before installation, I don't see how we could hope to
do any different.
You may test you function with following example:
(
P=/work/tmp/test/test-links
rm -rf $P
mkdir $P
cd $P
mkdir -p a/1/2
mkdir -p b/2
(cd b; ln -s ../a/1)
cd b/2
D=../1/../
touch $D/test
func_normal_abspath $D
echo $func_normal_abspath_result
/bin/ls -l $func_normal_abspath_result/
/bin/ls -l $D
)
I think the whole of GNU configure expects the tree under $prefix/ to be
real and there are a lot of other things that will break if you try to use
symlinks to make the physical directory structure different from the apparent
structure, for example gcc tries to execute ld by starting at the
$prefix/lib/gcc/$target/$version directory where cc1 lives and invoking
../../../../bin/ld; if you've got symlinks in there that can't be ascended
without ending up somewhere other than you expect, then the compiler isn't
going to work.
Sure.
Currently for gcc 4.4.0 (target i486-mingw32 build ${ARCH}-pc-linux) non
prefixed binaries from PREFIX/TARGET/bin don't work for me. As
example gcc can't find cc1. May be is same issue.
To resolve issue I use following additional links:
# cd $PREFIX
# l ./i486-mingw32/lib/gcc
lrwxrwxrwx 1 ./i486-mingw32/lib/gcc - ../../lib/gcc/
# l ./i486-mingw32/libexec
lrwxrwxrwx 1 ./i486-mingw32/libexec - ../libexec/
So I don't think this is likely to cause any problem except in really
bizarre corner-cases where someone's already trying something dubious, is it?
So to me function like XX_abspath has to work.
cheers,
DaveK
Roumen
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote:
Dave Korn wrote:
Roumen Petrov wrote:
I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.
As I explained to Eric, this function implements 'abspath', not
'realpath',
and given that we can't assume any of the directories even exist when
we have
to do this at link time, before installation, I don't see how we could
hope to
do any different.
You may test you function with following example:
[snip]
)
Yes, it is clear that there are cases, with oddly-constructed
pre-existing trees that contain symlinks, where abspath != realpath.
But, keep your eye on the ball: right now DLLs get installed into the
wrong directory, even in relatively normal setups:
--libdir=/usr/lib/subdir/
(--bindir=/usr/bin)
Current behavior assumes that bindir (e.g., where the DLL actually
gets installed) is /usr/lib/subdir/../bin. This is clearly wrong, and
broken regardless of whether you have an odd symlink-infested /usr. The
existing logic basically only works if both bindir and libdir are the
defaults, AND there are no funky symlinks.
So...
Dave's patch doesn't make things any worse than they already are for
non-default libdir/bindir, even for symlink-infested installation trees.
Broken before, fixed after, unless bad symlink problems -- in which
case it MAY still be broken, and maybe NOT. But if you're mucking about
with symlinks to make the logical installation tree differ from the
physical installation tree, well...IMO you're just asking for trouble.
But it's not fair to Dave to ask him to solve ALL pre-existing problems
with libtool's installation logic. He's trying to solve one problem,
while (hopefully) at the same time not making other pre-existing
problems worse.
I think his patch satisfies those requirements.
Sure.
Currently for gcc 4.4.0 (target i486-mingw32 build ${ARCH}-pc-linux) non
prefixed binaries from PREFIX/TARGET/bin don't work for me. As
example gcc can't find cc1. May be is same issue.
To resolve issue I use following additional links:
# cd $PREFIX
# l ./i486-mingw32/lib/gcc
lrwxrwxrwx 1 ./i486-mingw32/lib/gcc - ../../lib/gcc/
# l ./i486-mingw32/libexec
lrwxrwxrwx 1 ./i486-mingw32/libexec - ../libexec/
So...you're saying that gcc's installation paths are somewhat busted in
that the driver executables can't locate the backend executables, when
cross + non-default-prefix + odd-symlink-structure? OK.
So, why is this relevant to changes that *Dave* needs to make in the
patch for *libtool* with regards to *DLLs*? (Unless, you're simply
agreeing with Dave's statement that yeah, lots of GNU-style
installations can break when you muck with the installation tree in
unsupported ways. But if so, then...what's the objection to Dave's
patch, again?)
So I don't think this is likely to cause any problem except in really
bizarre corner-cases where someone's already trying something dubious,
is it?
So to me function like XX_abspath has to work.
Why? abspath != realpath. That's the point. If you're arguing that
all GNU installation tools should use realpath to canonicalize all paths
before use, well...maybe that discussion should be held, in some other
thread with a broader audience as it affects MUCH more than just
libtool. But (a) your desired behavior is not the case now, in a lot of
places other than libtool, (b) doing it your way will badly break
DESTDIR installations and any installation where the target installation
directory tree is not fully created at build/installation time (c) and
you'll get a lot of pushback from automake/autoconf on that.
Summary: in what way does Dave's patch make libtool behavior worse than
current? Given that I don't believe it does, yet his patch definitely
fixes issues that occur at present in much more common contexts, I'm
trying to clarify whether you believe your comments represent a reason
to block until rework, or accept as-is, Dave's current patch.
--
Chuck
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote:
Dave Korn wrote:
Roumen Petrov wrote:
I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.
this function implements 'abspath', not 'realpath',
^^^
and given that we can't assume any of the directories even exist when
we have to do this at link time, before installation,
^
You may test you function with following example:
No thanks, I don't think I'll bother. I understand perfectly well what the
problem is with symlinks, but what you seem to overlook is that there is no
possible way of knowing whether any path component will be a real directory or
a symlink *before it is even created*.
Sure.
Currently for gcc 4.4.0 (target i486-mingw32 build ${ARCH}-pc-linux) non
prefixed binaries from PREFIX/TARGET/bin don't work for me. As
example gcc can't find cc1. May be is same issue.
Yes, like I told you, the whole of GNU autotools and configure and
everything assumes that you won't be messing around with symlinks in your
$prefix structure like this. What you are doing is unsupported.
To resolve issue I use following additional links:
# cd $PREFIX
# l ./i486-mingw32/lib/gcc
lrwxrwxrwx 1 ./i486-mingw32/lib/gcc - ../../lib/gcc/
# l ./i486-mingw32/libexec
lrwxrwxrwx 1 ./i486-mingw32/libexec - ../libexec/
So I don't think this is likely to cause any problem except in really
bizarre corner-cases where someone's already trying something dubious,
is it?
So to me function like XX_abspath has to work.
Since what you want is impossible in the general case, I'm not going to put
any effort into making your system work. If you want to implement this
entirely new feature, you will have to patch autoconf, automake, gcc, libtool,
and everything else yourself.
cheers,
DaveK
