[PATCH] Fix typo in libtool install mode usage text
* libltdl/config/ltmain.m4sh (func_mode_help): Change -inst-prefix to -inst-prefix-dir. Signed-off-by: Mike Frysinger vap...@gentoo.org --- ChangeLog |6 ++ libltdl/config/ltmain.m4sh |2 +- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 424d296..a5f3a07 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2009-01-25 Mike Frysinger vap...@gentoo.org + + Fix typo in libtool install mode usage text. + * libltdl/config/ltmain.m4sh (func_mode_help): Change -inst-prefix + to -inst-prefix-dir. + 2009-01-24 Charles Wilson libt...@cwilson.fastmail.fm Add -Wall to cwrapper tests. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 82ee723..08045bf 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -1107,7 +1107,7 @@ either the \`install' or \`cp' program. The following components of INSTALL-COMMAND are treated specially: - -inst-prefix PREFIX-DIR Use PREFIX-DIR as a staging area for installation + -inst-prefix-dir PREFIX-DIR Use PREFIX-DIR as a staging area for installation The rest of the components are interpreted as arguments to that command (only BSD-compatible install options are recognized). -- 1.6.1
Re: [PATCH] Fix typo in libtool install mode usage text
Hi Mike,
* Mike Frysinger wrote on Mon, Jan 26, 2009 at 05:29:15AM CET:
* libltdl/config/ltmain.m4sh (func_mode_help): Change -inst-prefix
to -inst-prefix-dir.
Thanks. libtool.texi was wrong, too, so I pushed this.
I did consider renaming the option to match the documentation instead,
and am not sure which was better; typically, the user never needs to use
this option. Have you?
Cheers,
Ralf
Fix typo in libtool install mode documentation.
* libltdl/config/ltmain.m4sh (func_mode_help): Change -inst-prefix
to -inst-prefix-dir.
* doc/libtool.texi (Install mode): Likewise.
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
diff --git a/ChangeLog b/ChangeLog
index 424d296..92fc4c5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2009-01-25 Mike Frysinger vap...@gentoo.org
+
+ Fix typo in libtool install mode documentation.
+ * libltdl/config/ltmain.m4sh (func_mode_help): Change -inst-prefix
+ to -inst-prefix-dir.
+ * doc/libtool.texi (Install mode): Likewise.
+
2009-01-24 Charles Wilson libt...@cwilson.fastmail.fm
Add -Wall to cwrapper tests.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index d304f28..c3a2906 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1573,7 +1573,7 @@ In @dfn{install} mode, libtool interprets most of the
elements of
The following components of @var{mode-args} are treated specially:
@table @option
-...@item -inst-prefix @var{inst-prefix-dir}
+...@item -inst-prefix-dir @var{inst-prefix-dir}
When installing into a temporary staging area, rather than the
final @var{prefix}, this argument is used to reflect the
temporary path, in much the same way @command{automake} uses
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 82ee723..08045bf 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1107,7 +1107,7 @@ either the \`install' or \`cp' program.
The following components of INSTALL-COMMAND are treated specially:
- -inst-prefix PREFIX-DIR Use PREFIX-DIR as a staging area for installation
+ -inst-prefix-dir PREFIX-DIR Use PREFIX-DIR as a staging area for
installation
The rest of the components are interpreted as arguments to that command (only
BSD-compatible install options are recognized).
Re: Add lib prefix to library name in the ltdl preloaded symbol lookup
Peter Rosin wrote:
This is from need-lib-prefix.at: main.exeS.c when the test
is run on the tip of the pr-msvc-support branch.
lt__PROGRAM__LTX_preloaded_symbols[] =
{ { @PROGRAM@, (void *) 0 },
{foo1.lib, (void *) 0},
{libfoo1_LTX_i, (void *) foo1_LTX_i},
{libfoo1_LTX_f, (void *) foo1_LTX_f},
The below patch makes that into
{libfoo1.lib, (void *) 0},
{libfoo1_LTX_i, (void *) foo1_LTX_i},
{libfoo1_LTX_f, (void *) foo1_LTX_f},
which works much better.
The need-lib-prefix.at test still works on Cygwin after this test.
Did you test this in conjunction with the [cygwin|mingw] fix dlpreopen
with --disable-static take 4 changes, or do I need to do that? Also,
what if the library is not libfooN.lib, but is instead cygfoo-N.dll
(or foo-N.dll) -- which is another way of asking the same question, I
guess?
--
Chuck
Re: [PATCH] Fix typo in libtool install mode usage text
* Mike Frysinger wrote on Mon, Jan 26, 2009 at 09:23:42PM CET: On Monday 26 January 2009 14:27:43 Ralf Wildenhues wrote: I did consider renaming the option to match the documentation instead, and am not sure which was better; typically, the user never needs to use this option. Have you? i was working with a package that doesnt use automake but does use libtool and was trying to figure out if i needed to tell libtool about installing temporarily into DESTDIR rather than the real root. if libtool keys off of DESTDIR in the env (and it seemed to), then no, i didnt need to use this option libtool just looks if the install dir is a prefix of the argument that was passed to -rpath at link time, and uses that as inst_prefix_dir. Cheers, Ralf
Re: Add lib prefix to library name in the ltdl preloaded symbol lookup
Den 2009-01-26 21:19 skrev Charles Wilson:
Peter Rosin wrote:
This is from need-lib-prefix.at: main.exeS.c when the test
is run on the tip of the pr-msvc-support branch.
lt__PROGRAM__LTX_preloaded_symbols[] =
{ { @PROGRAM@, (void *) 0 },
{foo1.lib, (void *) 0},
{libfoo1_LTX_i, (void *) foo1_LTX_i},
{libfoo1_LTX_f, (void *) foo1_LTX_f},
The below patch makes that into
{libfoo1.lib, (void *) 0},
{libfoo1_LTX_i, (void *) foo1_LTX_i},
{libfoo1_LTX_f, (void *) foo1_LTX_f},
which works much better.
The need-lib-prefix.at test still works on Cygwin after this test.
Did you test this in conjunction with the [cygwin|mingw] fix dlpreopen
with --disable-static take 4 changes, or do I need to do that? Also,
what if the library is not libfooN.lib, but is instead cygfoo-N.dll
(or foo-N.dll) -- which is another way of asking the same question, I
guess?
Ooops, sorry for broadsiding your pending patch like that, I failed to
notice the clash...
Please ignore my patch for now, and I'll do tests here before I resubmit
(once yours is through the queue).
But if you have some time, what tests to you think are likely
to belly up with yours and my changes combined?
Cheers,
Peter
Re: Add lib prefix to library name in the ltdl preloaded symbol lookup
Den 2009-01-26 21:54 skrev Peter Rosin:
Den 2009-01-26 21:19 skrev Charles Wilson:
Peter Rosin wrote:
This is from need-lib-prefix.at: main.exeS.c when the test
is run on the tip of the pr-msvc-support branch.
lt__PROGRAM__LTX_preloaded_symbols[] =
{ { @PROGRAM@, (void *) 0 },
{foo1.lib, (void *) 0},
{libfoo1_LTX_i, (void *) foo1_LTX_i},
{libfoo1_LTX_f, (void *) foo1_LTX_f},
The below patch makes that into
{libfoo1.lib, (void *) 0},
{libfoo1_LTX_i, (void *) foo1_LTX_i},
{libfoo1_LTX_f, (void *) foo1_LTX_f},
which works much better.
The need-lib-prefix.at test still works on Cygwin after this test.
Did you test this in conjunction with the [cygwin|mingw] fix dlpreopen
with --disable-static take 4 changes, or do I need to do that? Also,
what if the library is not libfooN.lib, but is instead cygfoo-N.dll
(or foo-N.dll) -- which is another way of asking the same question, I
guess?
Ooops, sorry for broadsiding your pending patch like that, I failed to
notice the clash...
Please ignore my patch for now, and I'll do tests here before I resubmit
(once yours is through the queue).
But if you have some time, what tests to you think are likely
to belly up with yours and my changes combined?
Sorry to reply to self, but I think only the need-lib-prefix.at test is
affected by my patch (on cygwin/mingw and many others) since my patch
only changes things when need_lib_prefix!=no which it isn't normally.
Only so in need-lib-prefix.at where the libtool script is edited to fake
that scenario (probably to get testsuite exposure for an uncommon quirk).
need-lib-prefix.at is ok on cygwin and MSYS/MSVC with your and my changes
combined, and I tested that with both ordinary .../configure and
.../configure --disable-static.
But maintainers, please review [cygwin|mingw] fix dlpreopen with
--disable-static take 4 without regard to my patch.
Cheers,
Peter
Re: AWK is required by MS dumpbin symbol pipe.
Hi Peter, * Peter Rosin wrote on Mon, Jan 26, 2009 at 02:16:52PM CET: This patch make sure AWK is set, even for minimal configure script that doesn't bring it in from elsewhere. OK for master. Thanks, Ralf 2009-01-26 Peter Rosin p...@lysator.liu.se AWK is required, make sure it is set. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS: Make sure AWK is set (automake brings it in, but is not always used). Fixes old-m4-iface.at on MSYS/MSVC.
Re: Unify line endings in localization test
* Peter Rosin wrote on Sat, Jan 24, 2009 at 08:47:03PM CET: Den 2009-01-24 14:03, skrev Ralf Wildenhues: * Eric Blake wrote on Sat, Jan 24, 2009 at 02:00:15PM CET: According to Ralf Wildenhues on 1/24/2009 2:37 AM: Ah yes, that sounds like it was the problem here. Surely that makes criss cross merging (which we are effectively doing ATM) between two branches a bit more fun. In the end, we might have to declare that the order of, say, master, is the one we'd like to have. Maybe we can enhance git-merge-changelog to allow for such a prioritisation (sp?). Yes, I'm using git-merge-changelog. I don't see how which branch is 'upstream' might make the merge driver mess up the ordering. When merging a bunch of commits from one branch to another, the ChangeLog entries should appear in the order the corresponding changes were made in the other branch. Sounds pretty simple. But at the same time, I acknowledge that what seems like a SMOP is not always that S... Well, I think it really was because the driver's and your idea of upstream diverged. I found the long comment near the beginning of the main function of git-merge-changelog intructive (also didn't know about GIT_UPSTREAM or GIT_DOWNSTREAM before): http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/git-merge-changelog.c Hope that helps. Cheers, Ralf
Re: AWK is required by MS dumpbin symbol pipe.
Den 2009-01-26 22:15 skrev Ralf Wildenhues: Hi Peter, * Peter Rosin wrote on Mon, Jan 26, 2009 at 02:16:52PM CET: This patch make sure AWK is set, even for minimal configure script that doesn't bring it in from elsewhere. OK for master. Pushed, thanks! Cheers, Peter
Re: versioning test
Hi Bob, * Bob Friesenhahn wrote on Sat, Jan 24, 2009 at 05:18:32PM CET: On Sat, 24 Jan 2009, Ralf Wildenhues wrote: Here is a testsuite addition to get some exposure to versioning. OK to push (and add Mike to THANKS)? It'd be good if somebody proof-read it so there are no silly typos or thinkos. I read it and did not see any silly typos or thinkos, but then again it is not easy reading. It should be interesting to see where these tests report a failure. Well, I did test that setting $version_type to qnx on my GNU/Linux system would cause the failure that Mike reported, so one can expect they are not completely useless, e.g., for porting to a new platform, or for ensuring that future changes to ltmain will not break documented semantics. OTOH, the tests need a gloss over. Mike's testing already exposed one bug in them, in that one cannot assume the major version of a library is $current - $age, it might just be $current (plus or minus one or so). Another bit, my test for this hypothesis: |If two libraries have identical CURRENT and AGE numbers, then the | dynamic linker chooses the library with the greater REVISION number. is too weak for what I thought of. On GNU/Linux, you can install two libraries differing only in revision, and `ldconfig -n $libdir' will take care to let the respective versioned symlink point to the newer revision. Cool, huh? I didn't even know that, but I think that's what the sentence above tried to imply. Problem of course is, this surely doesn't happen for systems that don't encode a revision into the name, and may not either hold for some that do. I'd have to test, and will try to come up with a better patch (and documentation fix) for this hypothesis then. Thanks for the review. Cheers, Ralf
Re: versioning test
Hello Mike,
please keep the mailing list in Cc:, thanks.
* Mike Gorchak wrote on Mon, Jan 26, 2009 at 11:11:30AM CET:
RW Here is a testsuite addition to get some exposure to versioning.
RW OK to push (and add Mike to THANKS)? It'd be good if somebody
RW proof-read it so there are no silly typos or thinkos.
Versioning test (with my patch regarding QNX versioning applied) has been
failed for me in strange way - couldn't find liba.so.0 library error at
the end of test during cleanup procedure (rm -f as far as I can
understand from logs).
See below, it is a bug in the test.
As far as I can see in my previous letter all old tests are passed well.
In this letter in the attachment, verbosed log of stdout/stderr and
testsuite.log as for new tests, some of them are failed on QNX.
Thank you. I see three distinct issues, and I'll quote the respective
logs for other readers:
1) The duplicate_member test:
| libtool: link: ar cru .libs/libc0.a 6/.libs/a.o
| libtool: link: ranlib .libs/libc0.a
| libtool: link: ( cd .libs rm -f libc0.la ln -s ../libc0.la
libc0.la )
| libtool: link: (cd .libs/libconv.lax/libc0.a ar x
/ports/temp/libtool-2.2.6-qnx/tests/testsuite.dir/15/./.libs/libc0.a)
| libtool: link: ar cru .libs/libconv.a 1/.libs/a.o 2/.libs/a.o 3/.libs/a.o
4/.libs/a.o 5/.libs/a.o .libs/libconv.lax/libc0.a/a.o
| libtool: link: ranlib .libs/libconv.a
| libtool: link: rm -fr .libs/libconv.lax
| libtool: link: ( cd .libs rm -f libconv.la ln -s ../libconv.la
libconv.la )
| libtool: compile: qcc -V3.3.5,gcc_ntox86 -O3 -funroll-all-loops
-I/usr/include -c bar.c -fPIC -shared -DPIC -o .libs/bar.o
| libtool: compile: qcc -V3.3.5,gcc_ntox86 -O3 -funroll-all-loops
-I/usr/include -c bar.c -o bar.o /dev/null 21
| libtool: link: (cd .libs/libbar.lax/libconv.a ar x
/ports/temp/libtool-2.2.6-qnx/tests/testsuite.dir/15/./.libs/libconv.a)
| libtool: link: qcc -V3.3.5,gcc_ntox86 -shared .libs/bar.o
.libs/libbar.lax/libconv.a/a.o -L/usr/lib-Wl,-soname -Wl,libbar.so.0 -o
.libs/libbar.so.0
| libtool: link: (cd .libs rm -f libbar.so ln -s libbar.so.0
libbar.so)
| libtool: link: (cd .libs/libbar.lax/lt1-libconv.a ar x
/ports/temp/libtool-2.2.6-qnx/tests/testsuite.dir/15/./.libs/libconv.a)
| libtool: link: ar cru .libs/libbar.a bar.o
.libs/libbar.lax/lt1-libconv.a/a.o
| libtool: link: ranlib .libs/libbar.a
| libtool: link: rm -fr .libs/libbar.lax .libs/libbar.lax
| libtool: link: ( cd .libs rm -f libbar.la ln -s ../libbar.la
libbar.la )
| libtool: compile: qcc -V3.3.5,gcc_ntox86 -O3 -funroll-all-loops
-I/usr/include -c main.c -fPIC -shared -DPIC -o .libs/main.o
| libtool: compile: qcc -V3.3.5,gcc_ntox86 -O3 -funroll-all-loops
-I/usr/include -c main.c -o main.o /dev/null 21
| libtool: link: qcc -V3.3.5,gcc_ntox86 -O3 -funroll-all-loops -I/usr/include
-o .libs/main .libs/main.o -L/usr/lib ./.libs/libbar.so -Wl,-rpath -Wl,/notexi
| ./.libs/libbar.so: undefined reference to `foo2'
| ./.libs/libbar.so: undefined reference to `foo3'
| ./.libs/libbar.so: undefined reference to `foo1'
| ./.libs/libbar.so: undefined reference to `foo4'
| ./.libs/libbar.so: undefined reference to `foo5'
| cc: /usr/qnx630/host/qnx6/x86/usr/bin/i386-pc-nto-qnx6.3.0-ld error 1
| ./duplicate_members.at:73: ./main; lt_status=$?; if test $lt_status -eq 0;
then :;
|elif test X$host != X$build \
| { test -x ./main || test -x ./main$EXEEXT; }
|then (exit 77); else (exit $lt_status); fi
| Not enabling shell tracing (command contains an embedded newline)
| stderr:
| /ports/temp/libtool-2.2.6-qnx/tests/testsuite:
/ports/temp/libtool-2.2.6-qnx/tests/testsuite.dir/at-test-source[95]: ./main:
not found
| stdout:
| ./duplicate_members.at:73: exit code was 127, expected 0
libtool does not take care to rename duplicate object members in
archives on your system. Let's find out whether this is due to a
deficient sort binary or func_basename on QNX: please cd into your
build tree in which you ran the testsuite. Then enter these commands
and post all their output (gzip large output):
cd tests/testsuite.dir/16
./libtool --debug --mode=link --tag=CC qcc -V3.3.5,gcc_ntox86 -O3 \
-funroll-all-loops -o libconv.la \
1/a.lo 2/a.lo 3/a.lo 4/a.lo 5/a.lo libc0.la
The duplicate_conv failure within the low max_cmd_len test is of the
same nature:
| /duplicate_conv.at:51: $LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS
-o libcee.la c.lo a/liba.la b/liba.la
| stderr:
| stdout:
| libtool: link: (cd .libs/libcee.lax/liba.a ar x
/ports/temp/libtool-2.2.6-qnx/tests/testsuite.dir/74/tests/testsuite.dir/16/a/.libs/liba.a)
| libtool: link: (cd .libs/libcee.lax/lt1-liba.a ar x
/ports/temp/libtool-2.2.6-qnx/tests/testsuite.dir/74/tests/testsuite.dir/16/b/.libs/liba.a)
| libtool: link: ar cru .libs/libcee.a .libs/c.o
| libtool: link: : .libs/libcee.a
| libtool: link: ar cru .libs/libcee.a .libs/libcee.lax/liba.a/a.o
| libtool: link: :
Re: versioning test
Hello, Ralf!
RW please keep the mailing list in Cc:, thanks.
Sorry, my fault :)
RW libtool does not take care to rename duplicate object members in
RW archives on your system. Let's find out whether this is due to a
RW deficient sort binary or func_basename on QNX: please cd into your
RW build tree in which you ran the testsuite. Then enter these commands
RW and post all their output (gzip large output):
RW cd tests/testsuite.dir/16
RW ./libtool --debug --mode=link --tag=CC qcc -V3.3.5,gcc_ntox86 -O3 \
RW -funroll-all-loops -o libconv.la \
RW 1/a.lo 2/a.lo 3/a.lo 4/a.lo 5/a.lo libc0.la
There is no tests/testsuite.dir/16 directory. I've 15, 17, 26, 35, 38, 68,
74 only. What do I need to create it ?
RW 2) Failure test:
RW does this work on your system?
RW echo 'int not_main () { return 0; }' a.c
RW qcc -V3.3.5,gcc_ntox86 -O3 -funroll-all-loops -c a.c
RW qcc -V3.3.5,gcc_ntox86 -O3 -funroll-all-loops -o a a.o
RW echo $?
RW ls -l a
Yes, it works. Reporting 0 as exit code and: ls -l a reports:
-rwxrwxr-x 1 rootroot4110Jan 27 08:13a
ldd /ports/temp/libtool-2.2.6-qnx/a
/ports/temp/libtool-2.2.6-qnx/a
libc.so.2 = /usr/lib/ldqnx.so.2 (0xb030)
Is test code also contains 'int not_main () { return 0; }' as C code to
compile and link ?
RW 3) The failure of the new versioning test. This is interesting:
P.S. Why tests which are marked at exit as expected failure did not
appeared in the testsuite.log file with 'ok' status ?
RW Well, they fail. Each of them represents a bug we know about and
RW should fix sometime. :-)
Ah, ok :)
With best regards, Mike Gorchak. E-mail: m...@malva.ua
Re: versioning test
Hello, Ralf!
RW libtool does not take care to rename duplicate object members in
RW archives on your system. Let's find out whether this is due to a
RW deficient sort binary or func_basename on QNX: please cd into
your
RW build tree in which you ran the testsuite. Then enter these
RW commands and post all their output (gzip large output):
RW cd tests/testsuite.dir/16
RW ./libtool --debug --mode=link --tag=CC qcc -V3.3.5,gcc_ntox86 -O3
RW \-funroll-all-loops -o libconv.la \1/a.lo
RW 2/a.lo 3/a.lo 4/a.lo 5/a.lo libc0.la
There is no tests/testsuite.dir/16 directory. I've 15, 17, 26, 35, 38,
68, 74 only. What do I need to create it ?
RW I meant 15. Sorry for the typo.
Log attached.
RW 2) Failure test:
RW does this work on your system?
RW echo 'int not_main () { return 0; }' a.c
RW qcc -V3.3.5,gcc_ntox86 -O3 -funroll-all-loops -c a.c
RW qcc -V3.3.5,gcc_ntox86 -O3 -funroll-all-loops -o a a.o
RW echo $?
RW ls -l a
Yes, it works. Reporting 0 as exit code and: ls -l a reports:
-rwxrwxr-x 1 rootroot4110Jan 27 08:13a
ldd /ports/temp/libtool-2.2.6-qnx/a
/ports/temp/libtool-2.2.6-qnx/a
libc.so.2 = /usr/lib/ldqnx.so.2 (0xb030)
RW Argh. What happens if you try to execute it?
RW ./a; echo $?
Exit code is 0x01.
With best regards, Mike Gorchak. E-mail: m...@malva.ua
stdout.txt.gz
Description: GNU Zip compressed data
