* Dave Korn wrote on Sun, Aug 16, 2009 at 06:26:11PM CEST:
> Ralf Wildenhues wrote:
> > sorry for making you go through another round.
>
> :-/ That'll teach me to say "unless there's anything else....?"
Hehe.
> > \+ is a GNU sed extension, \{1,\} is Posix (two instances).
> > Nested \( \) are not portabled sed, neither are alternations \|.
>
> Aaaaaaaaaaarrrrrrrgghh *headdesk* no alternations? That's ... just ... it's
> not even boolean! Grrrrrrnashrollfoamgibber Damn you, AT&T! Damn you, Sun!
> *shakes fist at crowd of greying bearded sandal-wearing old programmers* See
> you in hell, Unix-boys! <pulls pin out of a negated character class and
> laughs maniacally>
It's still Turing complete, so nothing that can't be worked around ...
;->
> > I'm afraid the direct execution of programs below .libs may not work
> > everywhere. I'd have to check to be sure though. It's fine with me
> > if you run this particular test only on systems of interest to you.
>
> I think it's easier to just make it install the test executable.
>
> Also, "gah"! "Can't run a program because it's in a subdirectory"?
No, that's not the reason. The reason is the following: we don't always
try to make the uninstalled executables have hardcoded rpaths against
the uninstalled libraries: that would require us to relink at
installation time. On some systems, you can --{en,dis}able-fast-install
to state you preference over relinking at "make install" time vs.
relinnking at "mode=execute uninstalled-program" time. In the latter
case, it's the wrapper script/executable outside of the .libs directory
that provides for the machinery.
Your direct execution of .libs/main then by-passes that machinery.
> What
> kind of hare=brained system is that? Would it help if I gave "-rpath $objdir"
> when linking main as well as for the libs?
Naa, don't do that, that's totally against the intention.
> >> +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 without "$LIBTOOL --mode=execute" prepended, no?
>
> I have no idea. I just copied the only other things in the testsuite that I
> could identify as execution tests. What does it actually *do*?
Run an installed program. Installed programs ought to run without
$LIBTOOL prepended.
> >> +AT_SETUP([bindir install tests])
> >
> >> +curdir=`pwd`
> >> +for libdir in \
> >> + $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
> >> + $curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//. \
> >> + $curdir/usr/lib/ \
> >> + $curdir/usr/lib \
> >> + $curdir/baz \
> >> + $curdir/baz/lib/ ;
> >
> > Mini nit: this ";" is not necessary. :-)
>
> It's still valid, isn't it?
Yes.
> I don't like to make my syntax in a way that
> only works because of line breaks.
OK, leave it like it is.
> > Out of curiosity, which of the systems of interest creates a
> > libfoo.so.0 file?
>
> Linux.
But you're not interested in testing GNU/Linux with $bindirneeded.
Neither any of the other unices, which might not have a libfoo.so.0,
but instead a libfoo.a (shared library! sic! on AIX) or a libfoo.0.so
or libfoo.so.0.0 or whatnot. So make life easy here, and drop all the
.so thingy tests, you don't want them here. Thanks.
> > What if that is a symlink rather than a plain file
> > ("test -f" only tests for plain files)?
>
> It is. The test still passes. Hmmmm..... better take a closer look at
> that. (And use the full so.0.0.0 name in the test).
Yeah, that's due to $bindirneeded.
> >> + # Clear any old stuff out before we install. Because bindir
> >> + # may be in /tmp, we have to take care to create it securely
> >> + # and not to delete and recreate it if we do.
> >> + rm -rf $libdir $curdir/bin $curdir/sbin $curdir/baz $curdir/usr
> >> 2>/dev/null
> >
> > I'd drop the 2>/dev/null; let's see errors in the log.
>
> It makes a load of ugly noise when it tries to delete
> "$curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//.", but I
> guess it's better that than missing something important.
Thanks.
Cheers,
Ralf
