RE: MSYS+MSVC for libtool branch-2-0, take 2
Ralf Wildenhues wrote: > Hi Peter, > > I'm very sorry it took me so long to write this email. > Nice to see you are making progress. :) Doing my best, it's not always so easy to decypher what's going on in guts of libtool... Besides, I'm taking revenge by sending a mail that I've been writing on for about three weeks, so it's probably long and winding and twisted in various ways :-) > * Peter Ekberg wrote on Fri, Jun 17, 2005 at 03:15:33PM CEST: > > Ralf Wildenhues wrote: > > > * Peter Ekberg wrote on Fri, Jun 10, 2005 at 10:57:33PM CEST: > > > > Ralf Wildenhues wrote: > > > > > > > > > > `link -LIB' can be a problem if the cygwin `link' (to create > > > > > hard links) > > > > > comes before the win32 paths. `LIB' works here. > > > > > > > > I have a fix for that in the attached patch, where you can > > > > override by setting MSLINK to the appropriate executable. > > > > > > Hmm. Can't we just move all this stuff to the section in > libtool.m4 > > > where $AR is set? It already allows user override (by setting AR > > > appropriately during configure). We could test whether `ar' > > > works, and > > > if not, whether either one of `link -lib' or `lib' work. > > > (This is where we then should also test whether `ar' > > > understands the `S' > > > option, and adjust archive_cmds/postinstall_cmds accordingly, > > > but that's > > > totally unrelated to this patch.) > > > > Of course, reuse the AR variable. *smacks forehead* > > :) > > > Looking closer reveals a couple of problems though... > > $AR is used in three ways if I read it correctly: > > 1. "$AR $AR_FLAGS archive files..." to create archives. > > 2. "$AR x archive" to extract archives. > > 3. "$AR t archive" to list archive content. > > > > I see no way to set AR and AR_FLAGS so that 1. is expanded > > to "lib -OUT:archive files..." as is needed here (-OUT: > > has to be prepended to the archive name without space). > > Hmm. See below. > > > "$AR x archive" has to be hidden in some construct, as there is > > the problem that there is no way to extract all members from > > a MSVC .lib in one go, you have to loop over the archived > > files and extract them one by one. > > We have more than one variable which allows a set of commands. > extract_old_archive_cmds comes to mind as a new name; and in fact, I > have suggested this before in another mail in this thread. > Seeded with '$AR x $oldlib'. Would you like me to show this > in a patch? Ah, I must have missed that. I'll look into changing the old archive extraction part of the patch if you set up the framework for me. So a patch will indeed be helpful, I will probably have a hard time getting it right and will probably wait for (more) hours while bootstrap is running in the background... :-/ > (Don't worry too much about global variable names in shell functions. > This is orthogonal, and I have an idea to hide the resulting > ugliness in ltmain.m4sh.) This I don't understand, so I'm not worrying, ok? :-) > Alternatively, if you don't like the extract_old_archive_cmds > idea, I'd > still prefer something like > $AR $AR_FLAGS$AR_SEP$oldlib .. > over your solution. Have AR_SEP=' ' by default. > Rationale: Less variables to keep track of. Hmmm, Automake (?) seems to set up a rule to use $AR, but that rule uses "$AR $ARFLAGS foo..." w/o underscore in AR_FLAGS (and of course no $AR_SEP). I noticed this when I added AR_FLAGS and AR_SEP with AC_SUBST in an attempt to pass one of the failed tests. (I added AR_SEP to AC_SUBST thinking that Automake would catch up and make use of it in the future...) > > 3 is easy to solve, just introduce $AR_LFLAGS and set it to > > "t" by default and to "-NOLOGO -LIST" for MSVC. > > > > I have made an attempt to solve these issues in > > msys_msvc-4.patch. > > By looking at `lib -link' I believe issue 1. is actually the most > problematic, since `lib' encodes the path into the archive by default. > I have not found a switch to turn this off (which does not imply there > is none). But that means we have to symlink/copy objects before > archiving them. (Could be done in the same loop as the renaming, but > will be expensive anyway.) > > Otherwise, all use of convenience archives breaks (and running the > Libtool test suite really shows that). If I do $ lib -OUT:foo.lib a/b/c.obj $ lib -EXTRACT:a/b/c.obj foo.lib I get a fresh copy of c.obj in cwd If I do $ ar cru bar.lib a/b/d.obj $ ar x bar.lib I get a fresh copy of d.obj in cwd Where's the difference? > > (It turns out that both ar and lib works as the archiver > > since MSVC does not actually see the generated archives. > > ar is selected by default, so you have to specify AR=lib > > or AR="link -lib" to get the Microsoft tool.) > > The "encodes paths" is one reason to prefer `ar' over `lib' any time. See above, and some tests that pass with lib seem to fail when ar is used. Haven't looked closely though. > > > > > After working around these, the next failure is when
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
Hi Nicolas, others, This is a gentle reminder that this issue with Libtool HEAD/branch-2-0 on Tru64 sh is still unsolved. It'd be nice to get a solution into the next 2.0 release candidate, should such a solution exist. * Nicolas Joly wrote on Tue, Jun 07, 2005 at 07:59:58PM CEST: > On Tue, Jun 07, 2005 at 03:31:22PM +0200, Ralf Wildenhues wrote: > > * Nicolas Joly wrote on Tue, Jun 07, 2005 at 01:27:25PM CEST: > > > On Tue, Jun 07, 2005 at 12:35:00PM +0200, Ralf Wildenhues wrote: > > > > * Nicolas Joly wrote on Tue, Jun 07, 2005 at 12:10:47PM CEST: > > > > > > > > > > In the mean time, i tested the solution where `print -r' and `ksh' > > > > > tests are swapped (attached patch). It seems to go a little further > > > > > (no more `print' error messages), but seems to fail in another ksh > > > > > problem/bug : > > > > [ which ends in a segmentation fault. ] > > OK, let's cut this testing a little short. It seems that Tru64 fails to > > provide any decent kind of shell for its users. > > > > I consider just putting a note about Tru64 into README (branch-1-5) > > resp. doc/notes.texi (HEAD). Proposal would be one of the following > > (whichever works and passes the test suite): > > > > | Note that Tru64 V5.1B ksh has some bugs which make it hardly useable for > > | libtoolized packages. Please set > > | BIN_SH=xpg4; export BIN_SH > > | in your environment for configuring and building. > > This one does not work ... It will solve the `print' problem, but will > lead to the shell crash a little later. > > with `BIN_SH=xpg4' set, `/usr/bin/posix/sh' is executed instead of the > classic `/bin/sh'; and, unfortunately, this is a hard link to `ksh'. > > [EMAIL PROTECTED] [~]> ls -ldi /usr/bin/posix/sh /usr/bin/ksh > 482 -rwxr-xr-x 2 bin bin 307248 Oct 16 2002 /usr/bin/ksh > 482 -rwxr-xr-x 2 bin bin 307248 Oct 16 2002 /usr/bin/posix/sh > > > | Note that Tru64 V5.1B ksh has some bugs which make it hardly useable for > > | libtoolized packages. Please set > > | lt_ECHO='printf %s\\n'; export lt_ECHO > > | in your environment for configuring and building. > > > > (s/lt_ECHO/ECHO/g for branch-1-5). Regards, Ralf
Re: MSYS+MSVC for libtool branch-2-0, take 2
Hi Peter,
To prevent another week long latency, I'll do a couple of replies,
starting with the easy issues.
* Peter Ekberg wrote on Tue, Jul 05, 2005 at 11:01:37PM CEST:
> Ralf Wildenhues wrote:
> >
> > I'm very sorry it took me so long to write this email.
> Besides, I'm taking revenge by sending a mail that I've been
> writing on for about three weeks, so it's probably long and
> winding and twisted in various ways :-)
I knew you'd do that. :)
> > * Peter Ekberg wrote on Fri, Jun 17, 2005 at 03:15:33PM CEST:
> > > Ralf Wildenhues wrote:
> > > > * Peter Ekberg wrote on Fri, Jun 10, 2005 at 10:57:33PM CEST:
> > > > > Ralf Wildenhues wrote:
> > > "$AR x archive" has to be hidden in some construct, as there is
> > > the problem that there is no way to extract all members from
> > > a MSVC .lib in one go, you have to loop over the archived
> > > files and extract them one by one.
> >
> > We have more than one variable which allows a set of commands.
> > extract_old_archive_cmds comes to mind as a new name; and in fact, I
> > have suggested this before in another mail in this thread.
> > Seeded with '$AR x $oldlib'. Would you like me to show this
> > in a patch?
>
> Ah, I must have missed that. I'll look into changing the old archive
> extraction part of the patch if you set up the framework for me.
> So a patch will indeed be helpful, I will probably have a hard time
> getting it right and will probably wait for (more) hours while
> bootstrap is running in the background... :-/
To speed up bootstrap somewhat while you are testing:
reconfdirs=. ./bootstrap
skips all the test directories.
> > (Don't worry too much about global variable names in shell functions.
> > This is orthogonal, and I have an idea to hide the resulting
> > ugliness in ltmain.m4sh.)
>
> This I don't understand, so I'm not worrying, ok? :-)
OK.
> > Alternatively, if you don't like the extract_old_archive_cmds
> > idea, I'd
> > still prefer something like
> > $AR $AR_FLAGS$AR_SEP$oldlib ..
> > over your solution. Have AR_SEP=' ' by default.
> > Rationale: Less variables to keep track of.
>
> Hmmm, Automake (?) seems to set up a rule to use $AR, but
> that rule uses "$AR $ARFLAGS foo..." w/o underscore in
> AR_FLAGS (and of course no $AR_SEP).
>
> I noticed this when I added AR_FLAGS and AR_SEP with AC_SUBST
> in an attempt to pass one of the failed tests. (I added AR_SEP
> to AC_SUBST thinking that Automake would catch up and make use
> of it in the future...)
Exactly. And it'd be backward-compatible with what users expect, too.
Hmm. Except I don't know how to set a Make variable to SPACE. Maybe
Automake could use $AR $ARFLAGS$${AR_SEP-' '} or so? Oh, chucks, we
should ask Automake for their preferred way before we set ours in
stone. Will write there. The only thing I could come up so far is
this heavyly ugly rule:
AR_SEP="$(AR_SEP)"; if test -z "$$AR_SEP"; then AR_SEP=' '; fi; \
$(AR) $(ARFLAGS)$${AR_SEP}$(OLDLIB) ...
AC_SUBSTing AR_SEP from Libtool's side is probably wrong, if it's used
in Automake. Automake need not use Libtool..
> > By looking at `lib -link' I believe issue 1. is actually the most
> > problematic, since `lib' encodes the path into the archive by default.
> > I have not found a switch to turn this off (which does not imply there
> > is none). But that means we have to symlink/copy objects before
> > archiving them. (Could be done in the same loop as the renaming, but
> > will be expensive anyway.)
> >
> > Otherwise, all use of convenience archives breaks (and running the
> > Libtool test suite really shows that).
>
> If I do
> $ lib -OUT:foo.lib a/b/c.obj
> $ lib -EXTRACT:a/b/c.obj foo.lib
> I get a fresh copy of c.obj in cwd
>
> If I do
> $ ar cru bar.lib a/b/d.obj
> $ ar x bar.lib
> I get a fresh copy of d.obj in cwd
>
> Where's the difference?
Well, first problem is that POSIX specifies that no paths be encoded
into archives at all. I don't like to violate this.
(Last but not least being that I would like that installed .lib files
be handled correctly by, e.g., cygwin ar. Maybe that is already the
case.)
I need to test this, though, I vaguely remember members being extracted
into subdirs.
> > > (It turns out that both ar and lib works as the archiver
> > > since MSVC does not actually see the generated archives.
> > > ar is selected by default, so you have to specify AR=lib
> > > or AR="link -lib" to get the Microsoft tool.)
> >
> > The "encodes paths" is one reason to prefer `ar' over `lib' any time.
>
> See above, and some tests that pass with lib seem to fail when
> ar is used. Haven't looked closely though.
OK.
> > > > > > After working around these, the next failure is when
> > > > linking libltdl:
> > > > > >
> > > > > > | libltdl_la-ltdl.obj : error LNK2019: unresolved external
> > > > > > symbol _lt_libltdl_LTX_preloaded_symbols referenced in
> > > > > > function _lt_dlinit.
> > > > > > | .libs/ltdl-6.dll : fatal error LNK1120: 1
> > un
Re: libtool-1.5.18 -- installed files owned by non-root user
Hi Peter,
* Peter Breitenlohner wrote on Fri, Jul 01, 2005 at 05:35:06PM CEST:
> On Fri, 1 Jul 2005, Ralf Wildenhues wrote:
> >>Incidentally, that kind of "dancing around" is in no way unique to
> >>libtool.
> I just checked that both emacs-21.4 and xemacs-21.4.17 do something like
> (cd ${src} && tar cf -) | (cd ${dst} && umask 022 & tar xf -)
> which preserves the timestamps and unfortunately ownership as well. If I
> remember correctly there are a few other packages doing either the same
> thing or "cp -p" (or similar).
:-/
> With GNU tar one could of course use either
> tar cf - --owner=0 --group=0
> or
> tar xf --no-same-owner
> but that will fail for other tar implementations.
Yep.
> >>[ `id -u` == 0 ] && chown -R root: $prefix/share/$pkg
(BTW, `==' is not portable test syntax, but `=' is equivalent.)
> >Why not
> > chown -R `id -u`:`id -g` $prefix/share/$pkg
> >here, unconditionally? ..
>
> Well, I either install as me (owning everything to be installed) or as root;
> thus the simple procedure above is good enough for me. Moreover whenever I
> create files as non-root, these files are owned automatically by me (at
> least on our linux systems).
Yep, and I believe that assumption is pretty safe nowadays.
However, `id' is not listed as allowed tool in standards..
> >... Are there systems where chown does not
> >understand the uid:gid syntax?
>
> Certainly no posix compliant ones, but then if there were no others much of
> Autoconf&Co would be superfluous.
Oh well. Let's try to play safe here. Would something like
if test "`id -u`" != 0; then :; else \
chown -R root $(DESTDIR)$(ltdldatadir) && \
chgrp -R root $(DESTDIR)$(ltdldatadir) || exit 1; \
fi
be ok? (Rationale: if `id' does not work, we try to chown/chgrp anyway.
Also, SUSv3 speaks of old systems where chown of uid only would fail if
the target user does not belong to the group owner. OTOH, I'm not sure
the user:group syntax is all that portable. I believe the former issue
is less of a problem today. Oh well.
The goal is still to put the time-preserving functionality into
`install-sh', but even if a patch gets accepted into Automake now, we
need to wait with the corresponding libtool change, so might as well put
this hack in now.
Regards,
Ralf
