On 04/05/2010 18:56, Ralf Wildenhues wrote:
I'll apply the patch below soon unless I hear complaints.
Complain is too strong a word for what I'm about to do... nitpick, quibble
or kibbitz might be better :) Disclaimer aside, ...
-The following explanation may help to understand the above
On 06/04/2010 22:39, Paolo Bonzini wrote:
On 04/06/2010 04:01 AM, Charles Wilson wrote:
As for whether it would get dropped if you did, I'd imagine
that's quite
plausible; you might want to add a volatile qualifier.
'static volatile const char * MAGIC = ...'
^^
On 04/04/2010 18:53, Charles Wilson wrote:
One thing I worry about -- but can't test on my platform, since cygwin's
compiler is not up to the latest-and-greatest yet so doesn't yet support
LTO -- is whether this bit, in the cwrapper, will break:
const char * MAGIC_EXE = $magic_exe;
It's
On 19/03/2010 06:18, Ralf Wildenhues wrote:
[ ... snip ... ] The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}), which may either be installed
On 17/03/2010 17:14, Eric Blake wrote:
On 03/16/2010 04:24 AM, Dave Korn wrote:
On 16/03/2010 06:17, Ralf Wildenhues wrote:
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
Should capitalise DOS and GNU.
@sc{} does the capitalization for you. This is correct texinfo usage
On 16/03/2010 06:17, Ralf Wildenhues wrote:
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
Should capitalise DOS and GNU.
The Microsoft Vista version of Windows provides increased default
Should refer to Vista and all later versions.
and updating of system-wide software. The
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
Dave Korn wrote:
libtool/ChangeLog:
The paperwork arrived today and is in the post on its way back to GNU HQ.
cheers,
DaveK
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
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
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
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
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
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
+1,380 @@
+# bindir.at - Test the -bindir option
+#
+# Copyright (C) 2009 Free Software Foundation, Inc.
+# Written by Dave Korn, 2009
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General
Ralf Wildenhues wrote:
in addition to what Eric already documented:
* Dave Korn wrote on Fri, Aug 14, 2009 at 01:34:18PM CEST:
Still finishing it off and getting it tested, but while that's going,
here's
a preview of the path canonicalisation function as I've got it so far; let me
know
that the system provides
+# no way to hard-code library paths into executables, and also
+# has no $shlibpath_var independent of the PATH variable, in
+# Ralf's words. But it turns out this is not possible, as:-
+#
+# * Dave Korn wrote on Fri, Aug 14, 2009 at 04:30:27AM CEST:
+# Ralf Wildenhues wrote
Ralf Wildenhues wrote:
So I guess we need to stick to host matching in the code,
Shame, but at least it makes my life slightly easier ;-)
Still finishing it off and getting it tested, but while that's going, here's
a preview of the path canonicalisation function as I've got it so far; let
Eric Blake wrote:
Cancelling out .. is wrong for 'symlink/..', when symlink does not
necessarily point to a working directory exactly one level down. (True,
cygwin does not implement POSIX semantics here, and cancels out foo/..
behind your back rather than properly resolving foo, but this
Eric Blake wrote:
I think it's as simple as:
And beyond that, it's just lots of practice. I agree that it often feels
like you have to memorize loads of information to write portable shell,
but at least these public reviews catch a lot of the pitfalls.
Your cheat sheet will come in very
Ralf Wildenhues wrote:
Hello Dave,
* Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
Well, the bindir option exists only to support PE DLLs,
Bzzt. First error. If libtool provides -bindir, then it should accept
it on every system, [ ... ] Of course on non-PE
systems
Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Thu, Aug 13, 2009 at 08:23:22AM CEST:
* Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1376,6 +1376,15 @@ Tries to avoid versioning (@pxref{Versioning}) for
libraries and modules
Peter Rosin wrote:
Missed this before, sorry. But since it is a well known fact that
exporting variables from libraries are bad and should be avoioded,
can we please stop adding more of that practice to the test suite?
There is enough of it already and in case it fails, other failures
might
Ralf Wildenhues wrote:
Yeah, I was merely arguing for the testsuite file name; sorry for the
confusion.
NP. Renamed to bindir.at.
I can rename it and adjust the tests so they run on all platforms, but make
sure the library /doesn't/ get installed to bindir on non-PE platforms. Ok?
Dave Korn wrote:
+# func_relative_path libdir bindir
gnulib-tool has a function func_relativize. Can we just reuse that
(and make it fast)?
Sure. However, if you want something that works with ../, then the
gnulib-tool code is worth looking at. Just a suggestion, you know.
I'll
Tim Rice wrote:
On Thu, 13 Aug 2009, Dave Korn wrote:
Re that, BTW: can I use shell array variables portably? I'm guessing not,
but it would simplify the design slightly if there was a way.
No, array variables are not portable.
g Sheer optimisim on my part. Thanks for the reply
Ralf Wildenhues wrote:
Seems ok. Thanks for persevering.
NP :)
OK. Well, can we compromise on _also_ having an executability test?
There are always so many things that can go wrong for execution, that it
is nonetheless useful to try that out, and for that, to have an
executable that
Ralf Wildenhues wrote:
But in this particular case, I would argue that either you look at the
libtool variables shlibpath_var and hardcode_action for PATH and
unsupported.
On Cygwin, $hardcode_action = immediate in the generated libtool script.
Did you perhaps mean
Dave Korn wrote:
Now we twiddle our thumbs and wait for the paperwork, I guess!
Hmm. Or potentially not. I just submitted the patch (backported to GCC's
forked libtool) to the gcc-patches list(*). As far as I understand it, that
means I have now assigned my copyright in the patch
Peter Rosin wrote:
I think the new file tests/win32.at has a too generic name. And what if
some non-win32 platform needs this? I think the test should be named
tests/bindir.at (or inst-bindir.at) since that is what is tested.
How about pe-dll.at?
You also enable the code in ltmain for
Peter Rosin wrote:
Den 2009-08-11 08:50 skrev Dave Korn:
Peter Rosin wrote:
I think the new file tests/win32.at has a too generic name. And what if
some non-win32 platform needs this? I think the test should be named
tests/bindir.at (or inst-bindir.at) since that is what is tested.
How
Charles Wilson wrote:
So, here's the revised function (w/o the varname uglification):
*) func_dirname $tlibdir
tlibdir=${func_dirname_result}
if test x$tlibdir = x ; then
# Have to descend all the way to the root!
.
+#
+# Copyright (C) 2009 Free Software Foundation, Inc.
+# Written by Dave Korn, 2009
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation
+++ b/tests/pe-dll-inst-bindir.at
@@ -0,0 +1,171 @@
+# pe-dll-inst-bindir.at - Test the -bindir option for installing
+# DLLs on PE format architectures.
+#
+# Copyright (C) 2009 Free Software Foundation, Inc.
+# Written by Dave Korn, 2009
+#
+# This file is part
by Dave Korn, 2009
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any
Charles Wilson wrote:
[ snip ]
Thanks for all the shell portability advice, it's pretty specialised stuff
that I don't know all about; I'll incorporate your changes into the respin when
I add the docs.
I'm not sure -rpath is the right way to test, here. I know you're
trying to avoid doing
On 16 March 2007 15:35, Charles Wilson wrote:
Well, it's failing all the time for me, but I'm not sure it's a
segfault. What does Hangup mean, when reported by the shell after
executing the app: Good question, I don't know.
It means SIGHUP.
I've (almost) tracked down the error: it is
37 matches
Mail list logo
