Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Den 2009-08-11 12:30 skrev Dave Korn:
+AT_SETUP([dll basic test])
+
+AT_DATA([foo.c],[[
+int x=0;
+]])
+
+AT_DATA([baz.c],[[
+int y=0;
+]])
+
+AT_DATA([bar.c],[[
+extern int x;
+int bar(void);
+int bar() { return x;}
+]])
+
+AT_DATA([main.c],[[
+extern int x;
+extern int y;
+
+int main() {
+return x+y;
+}
+]])
*snip*
+AT_SETUP([dll install to bindir])
+
+AT_DATA([foo.c],[[
+int x=0;
+]])
+
+AT_DATA([bar.c],[[
+extern int x;
+int bar(void);
+int bar() { return x;}
+]])
+
+AT_DATA([baz.c],[[
+int y=0;
+]])
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 be hidden.
Cheers,
Peter
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
* 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,
i.e.@: no version information is stored and no symbolic links are created.
If the platform requires versioning, this option has no effect.
+...@item -bindir
+When linking a DLL for Windows or another PE platform, this option tells
What does this have to do with PE? All this is about is that there is
no real, independent $shlibpath_var beside PATH.
Erm, what I meant was that: this system provides no way to hard-code
library paths into executables, and also has no $shlibpath_var
independent of the PATH variable. Sorry about that.
I'm OK with mentioning
that Windows is the sole current user of this, but please let's word
this in a way that doesn't require us to change the interface if some
other system requires it, too. Ideally, neither the text.
+for x in \
+ ${curdir}/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin/ \
+ ${curdir}/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin \
+ ${curdir}/usr/lib/gcc/i686-pc-cygwin/4.5.0/ \
+ ${curdir}/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
+ ${curdir}/usr/lib/gcc/i686-pc-cygwin/bin/ \
+ ${curdir}/usr/lib/gcc/i686-pc-cygwin/bin \
+ ${curdir}/usr/lib/gcc/i686-pc-cygwin/ \
+ ${curdir}/usr/lib/gcc/i686-pc-cygwin \
+ ${curdir}/usr/lib/bin/ \
+ ${curdir}/usr/lib/bin \
+ ${curdir}/usr/bin/ \
+ ${curdir}/usr/bin \
+ ${curdir}/bin/ \
+ ${curdir}/bin \
You don't test paths with a '../' component in it. I thus assume they
won't work with your implementation (they work with gnulib-tool's).
These components often occur within GCC (haven't checked whether for
your particular situation, but I'd wonder why they shouldn't).
Cheers,
Ralf
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
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, it should just ignore the option silently.
That's exactly what it does already, as I thought I mentioned upthread.
So it's only the PE-specific bits of the test that should be skipped on
systems where they don't apply.
Thus, bindir.at is a sensible name.
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?
Do you intend for Automake to pass
-bindir to libtool --mode=link invocations automatically (maybe for
foo_LTLIBRARIES with foo not equal to lib or libexec)?
I intend the maintainer to trivially add -bindir $(bindir) anywhere in
their makefiles that they would be adding -no-undefined to cause DLLs to be
built. Sure I mentioned that one already, didn't I?
* Dave Korn wrote on Tue, Aug 11, 2009 at 10:35:28AM CEST:
All rebuilt OK. Checked docs with make dvi info pdf and viewing the
generated file. Testsuite re-run is still in progress, but I already checked
that the new tests all still pass, so unless I post back saying otherwise in
the
next couple of hours, assume the lot completed without regressions.
Tested on what system(s)?
i686-pc-cygwin. Could do a linux run as well if you like.
BTW, even if the part going into GCC is covered by your GCC assignment,
the rest is still sufficiently nontrivial to warrant an assignment.
Gah, of course, forgot about the testcase. Oh well, I didn't delay sending
off for the paperwork based on that theory, so we've not lost any time.
diff --git a/Makefile.am b/Makefile.am
old mode 100644
new mode 100755
Your files suffer from mode changes. They are of course not acceptable,
though I understand they are a w32 artifact. Can git be made to ignore
them for you?
I have no idea what's going on here. The modes of the files haven't changed
a bit according to 'ls', so cygwin git must be acting up. If I was to end up
applying the patch myself I'd probably have to check out libtool on a linux
box and commit it there.
tests/bindir.at, as already noted above; and as this is about
'libtool' (the script) API, please sort it alongside the other API
tests, preferably before or after cwrapper.at. Thanks.
Okeydokey; couldn't tell if there was a grouping and ordering in that list
or not.
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1376,6 +1376,15 @@ Tries to avoid versioning (@pxref{Versioning}) for
libraries and modules,
i.e.@: no version information is stored and no symbolic links are created.
If the platform requires versioning, this option has no effect.
+...@item -bindir
+When linking a DLL for Windows or another PE platform, this option tells
What does this have to do with PE?
PE is the object file format. There is no other object file format that has
DLLs, and no DSOs other than DLLs require installation to $PATH. It would
seem strange to suggest that this would work with ELF DLLs on Linux, for
example, since there are no such things!
All this is about is that there is
no real, independent $shlibpath_var beside PATH. I'm OK with mentioning
that Windows is the sole current user of this, but please let's word
this in a way that doesn't require us to change the interface if some
other system requires it, too. Ideally, neither the text.
I really and honestly cannot imagine any other possible use case for this
functionality. Still, if you want to suggest some more generic wording, just
tell me what you'd like it to say and I'll paste it in.
+# func_relative_path libdir bindir
+# generates a relative path from LIBDIR to BINDIR, intended
+# for supporting installation of windows DLLs into -bindir.
gnulib-tool has a function func_relativize. Can we just reuse that
(and make it fast)? Failing that, did you write this function from
scratch or took it from anywhere else.
I wrote it from scratch, then Chuck showed me how to do the shell script
portability stuff on this list. The tests cover all corner-cases and it works
and has no conceivable copyright or licensing snags. I think those are
reasonable justifications to just use it as-is.
I don't see any reason this function should be written specific to
libdir and bindir. There are other file names that may usefully be
relativized, so the function should be as general as possible, and use
generic names, too.
Sure; I just picked those names as indicative, not normative, examples of
usage. How about I change them to destdir and srcdir?
+# call:
+# func_dirname:
+# func_dirname file append nondir_replacement
Why do you repeat the descriptions of these functions here again?
That's not normally done elsewhere in
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
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,
i.e.@: no version information is stored and no symbolic links are created.
If the platform requires versioning, this option has no effect.
+...@item -bindir
+When linking a DLL for Windows or another PE platform, this option tells
What does this have to do with PE? All this is about is that there is
no real, independent $shlibpath_var beside PATH.
Erm, what I meant was that: this system provides no way to hard-code
library paths into executables, and also has no $shlibpath_var
independent of the PATH variable. Sorry about that.
Ah, see what you mean now; any other system with those properties would need
to have the libraries installed into a bindir where they could be found. Do
you know of any such systems off the top of your head?
You don't test paths with a '../' component in it. I thus assume they
won't work with your implementation (they work with gnulib-tool's).
These components often occur within GCC (haven't checked whether for
your particular situation, but I'd wonder why they shouldn't).
Good point. I'll add some and see what happens and fix any bugs arising
before I post the respin. I'd better check for './' components too.
cheers,
DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
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 be hidden. It is? I didn't know that. I'll function-ify them. cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Hi Dave, * Dave Korn wrote on Thu, Aug 13, 2009 at 04:10:11PM CEST: Ralf Wildenhues wrote: * 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, it should just ignore the option silently. That's exactly what it does already, as I thought I mentioned upthread. Yeah, I was merely arguing for the testsuite file name; sorry for the confusion. So it's only the PE-specific bits of the test that should be skipped on systems where they don't apply. Thus, bindir.at is a sensible name. 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? Why would that additional test be necessary? The general idea (however poorly executed) is that the test suite should need as little adjustment as possible when we add support for new platforms. Likewise, ltmain should not require much adjustment except to accommodate actually new semantics; only libtool.m4 and ltdl.m4 really ought to carry all the system-specifics, and they should be transported into the libtool script through the bunch of variables. Yes, this idea is pretty poorly executed ATM. 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. And even then, I wouldn't really want to check for presence of a particular file in $bindir, but I'd check whether a program executable installed in $bindir, and linked against a library (that should have its DLL installed in $bindir on applicable systems) will start and run correctly. Written this way, however, you don't need to delimit this particular test to any subset of platforms: things will work on any other system, too, by way of libtool linking semantics. Do you intend for Automake to pass -bindir to libtool --mode=link invocations automatically (maybe for foo_LTLIBRARIES with foo not equal to lib or libexec)? I intend the maintainer to trivially add -bindir $(bindir) anywhere in their makefiles that they would be adding -no-undefined to cause DLLs to be built. Sure I mentioned that one already, didn't I? Yes, you mentioned that. What I meant was a followup semantic change in Automake. Assume a Makefile.am with lib_LTLIBRARIES = libfoo.la fooexecdir = $(libdir)/sub/subsub/bla fooexec_LTLIBRARIES = libbar.la then automake will currently, while creating libfoo.la, add '-rpath $(libdir)' to the link command line, and '-rpath $(fooexecdir)' to that for libbar.la. Now, automake could be smart and, when it does not see the -module option being passed, either 1) add '-bindir $(bindir)' to none, 2) or both of these invocations, or 3) just to the one of libbar.la, knowing that the default relative from $(fooexecdir) to $(bindir) is not ../bin. We have (1) now. With (2), arbitrary --bindir and --libdir values passed to configure by the user would be handled as well. The question is whether there can be cases when a developer would *not* want -bindir to be passed automatically. What do you think? Even if there are such cases, we could arrange for automake to output the -bindir before expanding $(LDFLAGS), so that it would be overridable. Of course Automake would only do any of this with a libtool that understands -bindir. * Dave Korn wrote on Tue, Aug 11, 2009 at 10:35:28AM CEST: All rebuilt OK. Checked docs with make dvi info pdf and viewing the generated file. Testsuite re-run is still in progress, but I already checked that the new tests all still pass, so unless I post back saying otherwise in the next couple of hours, assume the lot completed without regressions. Tested on what system(s)? i686-pc-cygwin. Could do a linux run as well if you like. I think it would be good to see test results for MinGW and GNU/Linux, but it's sufficient to run the new tests only, make check-local TESTSUITEFLAGS='-v -d -x -k bindir' or so, depending on how you name your tests. (I can run these tests.) diff --git a/Makefile.am b/Makefile.am old mode 100644 new mode 100755 Your files suffer from mode changes. They are of course not acceptable, though I understand they are a w32 artifact. Can git be made to ignore them for you? I have no idea what's going on here. The modes of the files haven't changed a bit according to 'ls', so cygwin git must be acting up. If I was to end up applying the patch myself I'd probably have to check out libtool on a linux box and commit it there. OK. It's no big deal, just a bit to remember to fix up after I apply your patch. tests/bindir.at, as already noted above; and as this is about 'libtool' (the script) API, please sort it alongside the other API tests, preferably before or after
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
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?
Why would that additional test be necessary?
The general idea (however poorly executed) is that the test suite should
need as little adjustment as possible when we add support for new
platforms. Likewise, ltmain should not require much adjustment except
to accommodate actually new semantics; only libtool.m4 and ltdl.m4
really ought to carry all the system-specifics, and they should be
transported into the libtool script through the bunch of variables.
Yes, this idea is pretty poorly executed ATM.
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. And even then, I wouldn't really want to check for
presence of a particular file in $bindir, but I'd check whether a
program executable installed in $bindir, and linked against a library
(that should have its DLL installed in $bindir on applicable systems)
will start and run correctly. Written this way, however, you don't
need to delimit this particular test to any subset of platforms: things
will work on any other system, too, by way of libtool linking semantics.
Okay, I get what you mean. I agree with the first part (using shlibpath_var
and hardcode_action rather than tests of specific OSs), but I beg to differ
about the second. Checking if the program starts and runs correctly isn't
quite the same thing as checking if the parts were installed precisely where
the application coder instructed libtool to install them. It's an indirect
test, and for instance would false positive if someone on a windows platform
had /lib in their PATH. There might also be platforms where it didn't matter
functionally which of /bin and /lib a library got installed into, but there is
a packaging standard that says what goes where. Now, okay we can always reset
the PATH for the test, but if we're trying to do something that works as-is
for unanticipated future systems, could we ever be sure we'd caught every
environment variable or whatever that might make this indirect test produce a
false result?
For these reasons, I'd still prefer to test that the precise files we expect
get installed to the precise locations we require. Doing it that way (but
with the first part of your suggestion) would still be fully cross-platform
and future-friendly, wouldn't it?
Yes, you mentioned that. What I meant was a followup semantic change
in Automake. Assume a Makefile.am with
[ ... ]
We have (1) now. With (2), arbitrary --bindir and --libdir values
passed to configure by the user would be handled as well. The question
is whether there can be cases when a developer would *not* want -bindir
to be passed automatically.
What do you think? Even if there are such cases, we could arrange for
automake to output the -bindir before expanding $(LDFLAGS), so that it
would be overridable.
The honest answer is I just haven't thought that far ahead yet. I've only
been thinking of this option as a partner to -no-undefined, but you've
convinced me it might have relevance to a broader range of platforms. In that
context, it quite possibly would make sense for Automake to start adding it
automatically. But I haven't thought much about it yet.
I think it would be good to see test results for MinGW and GNU/Linux,
but it's sufficient to run the new tests only,
make check-local TESTSUITEFLAGS='-v -d -x -k bindir'
or so, depending on how you name your tests. (I can run these tests.)
Thanks, I'll take you up on that offer when the respin is complete.
diff --git a/Makefile.am b/Makefile.am
old mode 100644
new mode 100755
Your files suffer from mode changes.
I found a workaround. I think the perm changes were in non-unixy parts of
the ACL and caused by using a windows native editor. Copying correct perms
across from one of the other files in the same directory using 'chmod
--reference=...' shuts git up about the perms.
Certainly. My (arguably weak) point is that the Libtool manual is
pretty generic; there is currently literally no mention of the terms PE
or COFF at all, not even DLL is explained (note though that there is a
pending patch from Chuck that documents some w32-specific issues). It
simply seems a bit of a jump to start off this way. What about
something like
Pass the absolute name of the directory for installing executable
programs (@pxref{Directory Variables, , standards, The GNU Coding
Standards}). @command{libtool} may use this value to install shared
libraries there on systems that do not provide for any library
hardcoding and use the directory of a program and the @env{PATH}
variable as library search
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
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 write something to pre-condition the paths (i.e. remove '.' components and cancel out 'component/..' pairs, remove any doubled-up slashes and trim any trailing one) and make it a separate func, it might come in handy elsewhere. 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. cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
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. -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
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. cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
* Dave Korn wrote on Thu, Aug 13, 2009 at 09:19:49PM CEST:
Ralf Wildenhues wrote:
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?
Why would that additional test be necessary?
The general idea (however poorly executed) is that the test suite should
need as little adjustment as possible when we add support for new
platforms. Likewise, ltmain should not require much adjustment except
to accommodate actually new semantics; only libtool.m4 and ltdl.m4
really ought to carry all the system-specifics, and they should be
transported into the libtool script through the bunch of variables.
Yes, this idea is pretty poorly executed ATM.
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. And even then, I wouldn't really want to check for
presence of a particular file in $bindir, but I'd check whether a
program executable installed in $bindir, and linked against a library
(that should have its DLL installed in $bindir on applicable systems)
will start and run correctly. Written this way, however, you don't
need to delimit this particular test to any subset of platforms: things
will work on any other system, too, by way of libtool linking semantics.
Okay, I get what you mean. I agree with the first part (using shlibpath_var
and hardcode_action rather than tests of specific OSs), but I beg to differ
about the second. Checking if the program starts and runs correctly isn't
quite the same thing as checking if the parts were installed precisely where
the application coder instructed libtool to install them.
True.
It's an indirect
test, and for instance would false positive if someone on a windows platform
had /lib in their PATH. There might also be platforms where it didn't matter
functionally which of /bin and /lib a library got installed into, but there is
a packaging standard that says what goes where. Now, okay we can always reset
the PATH for the test, but if we're trying to do something that works as-is
for unanticipated future systems, could we ever be sure we'd caught every
environment variable or whatever that might make this indirect test produce a
false result?
Probably not.
For these reasons, I'd still prefer to test that the precise files we expect
get installed to the precise locations we require. Doing it that way (but
with the first part of your suggestion) would still be fully cross-platform
and future-friendly, wouldn't it?
Seems ok. Thanks for persevering.
Yes, you mentioned that. What I meant was a followup semantic change
in Automake. Assume a Makefile.am with
[ ... ]
We have (1) now. With (2), arbitrary --bindir and --libdir values
passed to configure by the user would be handled as well. The question
is whether there can be cases when a developer would *not* want -bindir
to be passed automatically.
What do you think? Even if there are such cases, we could arrange for
automake to output the -bindir before expanding $(LDFLAGS), so that it
would be overridable.
The honest answer is I just haven't thought that far ahead yet. I've only
been thinking of this option as a partner to -no-undefined, but you've
convinced me it might have relevance to a broader range of platforms. In that
context, it quite possibly would make sense for Automake to start adding it
automatically. But I haven't thought much about it yet.
OK. Anyway it's fine to deal with this later on.
Pass the absolute name of the directory for installing executable
programs (@pxref{Directory Variables, , standards, The GNU Coding
Standards}). @command{libtool} may use this value to install shared
libraries there on systems that do not provide for any library
hardcoding and use the directory of a program and the @env{PATH}
variable as library search path. This is typically used for DLLs on
Windows or other systems using the PE (Portable Executable) format.
On other systems, @option{-bindir} is ignored. The default value used
is @fi...@var{libdir}/../bin} for libraries installed to
@fi...@var{libdir}}. You should not use @option{-bindir} for modules.
Anyway, this is really just a suggestion and I appreciate your criticism
of it.
That seems fine for my purposes, I'll paste it in pretty much as-is, but the
default parameter isn't necessarily libdir, it's just where-ever you've
specified as the output path for the .la file + ../bin, isn't it?
Yeah; I tried to use @var{libdir} to indicate that (@var denotes a
metasyntactic variable, and renders differently) but that's probably too
subtle to understand, even with the for libraries installed to ...?
@var{libdir} is however the naming of the -rpath argument we use in
@node Link mode.
I took a quick look
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
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 calls a function from the library. Absolutely fine by me; I'll code it that way. cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
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_shlibpath_var, which is indeed unsupported? cheers, DaveK
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
* Dave Korn wrote on Fri, Aug 14, 2009 at 04:30:27AM CEST: 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_shlibpath_var, which is indeed unsupported? Oh brother, yes, I forgot about those bogus hardcode_libdir_flag_spec settings. They fool _LT_LINKER_HARDCODE_LIBPATH. I don't remember whether they were needed in order to not break some semantics in ltmain (they probably were). Anyway, $hardcode_action = immediate is definitely wrong, but fixing that now is also way out of scope of this patch. So I guess we need to stick to host matching in the code, and work out a separate fix for the setting of $hardcode_libdir_flag_spec. Luckily at least my proposed text for the manual is written broadly enough not to need changes due to this ... Thanks, Ralf
