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
uot;\
# $outputname - a libtool library file
diff --git a/tests/win32.at b/tests/win32.at
new file mode 100755
index 000..1d36add
--- /dev/null
+++ b/tests/win32.at
@@ -0,0 +1,170 @@
+# win32.at - tests specific to Cygwin and MinGW
+#
+# Copyright (C) 2009 Free Software Foundation, Inc.
+#
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 do
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
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!
>func_relative_path_result
$ECHO > $output "\
# $outputname - a libtool library file
diff --git a/tests/pe-dll-inst-bindir.at b/tests/pe-dll-inst-bindir.at
new file mode 100755
index 000..bd42d68
--- /dev/null
+++ b/tests/pe-dll-inst-bindir.at
@@ -0,0 +1,171 @@
+# pe-dll-inst-bindir.at - Test the -bindi
dir"
+ tdlname="${func_relative_path_result}$dlname"
+ else
+ # Otherwise fall back on heuristic.
+ tdlname=../bin/$dlname
+ fi
+ ;;
esac
$ECHO > $output "\
# $outputname - a libtool library file
diff --git a/tests/pe-dll-inst-bindir.at b/tests/pe-
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 patc
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, [ ..
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 (@p
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
> mi
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
>>
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.
>
Sheer optim
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 tha
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 $hardcode_shlib
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 ve
Ralf Wildenhues wrote:
> , and the info Autoconf "Portable Shell"
Yes, thanks, I've been thoroughly through that since someone metioned it
upthread and it does in fact document all these rules, under the individual
categories like "assignments", "case statements", rather than in one big
section
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 canonicalisatio
if test "x$bindir" != x ;
+ then
+ func_relative_path "$install_libdir" "$bindir"
+ tdlname=$func_relative_path_result$dlname
+ else
+ # Otherwise fall back on heuristic.
+ tdlname=../bin/$dlname
+ fi
+ ;;
esac
$ECHO > $outpu
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"
>
> \+
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/m
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.
>>
>>
name=../bin/$dlname ;;
+ *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll)
+ # If a -bindir argument was supplied, place the dll there.
+ if test "x$bindir" != x ;
+ then
+ func_relative_path "$install_libdir" "$bi
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 f
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 a
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
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 capitalizati
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 in
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";
>
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/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 abov
38 matches
Mail list logo
